2011/4/4 Wolfgang Schuster

Am 03.04.2011 um 13:00 schrieb Cecil Westerhof:

...

I have –simplified– the following: \starttext

\defineframed [action] [width=5cm, height=3cm, offset=none, frameoffset=.5\linewidth]

\action{}

\stoptext

What I would like to do is to let the user input some text and display it in this frame. (In reality there will be more frames.) When the text is to big to be displayed in the frame, it should be rejected.

This is so that the document can be modified with the text from the user.

http://www.pragma-ade.com/show-man-22.htm

Thanks I will look at it. It is a document from 1998 and it is said it will be udated. Nothing has changed? -- Cecil Westerhof

Am 05.04.2011 03:19, schrieb Cecil Westerhof:

2011/4/4 Wolfgang Schuster mailto:schuster.wolfgang@googlemail.com>

http://www.pragma-ade.com/show-man-22.htm

I tried the first example from fill-in fields: \starttext

A few years back, \TEX\ could only produce \fillinfield [dvi]{\DVI} output, but nowadays, thanks to \fillinfield {Han The Thanh}, we can also directly produce \fillinfield [pdf] {\PDF}! Nice eh? Actually, while the first field module was prototyped in \ACROBAT, the current implementation was debugged in \fillinfield [pdfTeX] {\PDFTEX}. Field support in \fillinfield [ConTeXt] {\CONTEXT} is rather advanced and complete and all kind of fields are supported. One can hook in appearances, and validation \fillinfield [JavaScripts] {\JAVASCRIPT}’s. Fields can be cloned and copied, where the latter saves some space. By using \fillinfield {objects} when suited, this module saves space anyway.

\stoptext

But I get: mtx-context | run 1: luatex --fmt="/home/cecil/ConTeXt/tex/texmf-cache/luatex-cache/context/5fe67e0bfe781ce0dde776fb1556f32e/formats/cont-en" --lua="/home/cecil/ConTeXt/tex/texmf-cache/luatex-cache/context/5fe67e0bfe781ce0dde776fb1556f32e/formats/cont-en.lui" --backend="pdf" "./test" This is LuaTeX, Version beta-0.65.0-2010121316 \write18 enabled. (test.tex

ConTeXt ver: 2011.03.27 14:48 MKIV fmt: 2011.3.27 int: english/english

system > cont-new.mkiv loaded (/home/cecil/ConTeXt/tex/texmf-context/tex/context/base/cont-new.mkiv system > beware: some patches loaded from cont-new.mkiv ) system > test.top loaded (test.top) fonts > latin modern fonts are not preloaded languages > language en is active {/home/cecil/ConTeXt/tex/texmf-context/fonts/map/pdftex/context/mkiv-base.map} fonts > preloading latin modern fonts (second stage) (/home/cecil/ConTeXt/tex/texmf-context/tex/context/base/type-siz.mkiv) (/home/cecil/ConTeXt/tex/texmf-context/tex/context/base/type-otf.mkiv){/home/cecil/ConTeXt/tex/texmf/fonts/map/dvips/lm/lm-math.map}{/home/cecil/ConTeXt/tex/texmf/fonts/map/dvips/lm/lm-rm.map} fonts > virtual math > unable to resolve name mapsfromchar fonts > fallback modern rm 12pt is loaded system > begin file test at line 1 ! Undefined control sequence.

system > tex > error on line 4 in file test.tex: Undefined control sequence ...

\def\DVI{DVI} \def\PDF{PDF} \def\ACROBAT{Acrobat} \def\JAVASCRIPT{Javascript}

1 \starttext 2 3 A few years back, \TEX\ could only produce 4 >> \fillinfield [dvi]{\DVI} output, 5 but nowadays, thanks to \fillinfield {Han The Thanh}, we can also directly produce \fillinfield [pdf] {\PDF}! 6 Nice eh? Actually, while the first field module was prototyped 7 in \ACROBAT, the current implementation was debugged in 8 \fillinfield [pdfTeX] {\PDFTEX}. Field support in \fillinfield 9 [ConTeXt] {\CONTEXT} is rather advanced and complete and all 10 kind of fields are supported. One can hook in appearances, and 11 validation \fillinfield [JavaScripts] {\JAVASCRIPT}’s. Fields 12 can be cloned and copied, where the latter saves some space. By 13 using \fillinfield {objects} when suited, this module saves 14 space anyway.

l.4 \fillinfield [dvi]{\DVI} output,

What is happening here?

I guess Hans has removed some obsolete definitions :-) Best wishes, Peter

-- Cecil Westerhof

___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________

Am 05.04.2011 12:31, schrieb Cecil Westerhof:

2011/4/5 Peter Rolf mailto:indiego@gmx.net>

> \starttext > > A few years back, \TEX\ could only produce > \fillinfield [dvi]{\DVI} output, > but nowadays, thanks to \fillinfield {Han The Thanh}, we can also > directly produce \fillinfield [pdf] {\PDF}! > Nice eh? Actually, while the first field module was prototyped > in \ACROBAT, the current implementation was debugged in > \fillinfield [pdfTeX] {\PDFTEX}. Field support in \fillinfield > [ConTeXt] {\CONTEXT} is rather advanced and complete and all > kind of fields are supported. One can hook in appearances, and > validation \fillinfield [JavaScripts] {\JAVASCRIPT}’s. Fields > can be cloned and copied, where the latter saves some space. By > using \fillinfield {objects} when suited, this module saves > space anyway. > > \stoptext > > But I get: > mtx-context | run 1: luatex > --fmt="/home/cecil/ConTeXt/tex/texmf-cache/luatex-cache/context/5fe67e0bfe781ce0dde776fb1556f32e/formats/cont-en" > --lua="/home/cecil/ConTeXt/tex/texmf-cache/luatex-cache/context/5fe67e0bfe781ce0dde776fb1556f32e/formats/cont-en.lui" > --backend="pdf" "./test" > This is LuaTeX, Version beta-0.65.0-2010121316 > \write18 enabled. > (test.tex > > ConTeXt ver: 2011.03.27 14:48 MKIV fmt: 2011.3.27 int: english/english > > system > cont-new.mkiv loaded > (/home/cecil/ConTeXt/tex/texmf-context/tex/context/base/cont-new.mkiv > system > beware: some patches loaded from cont-new.mkiv > ) > system > test.top loaded > (test.top) > fonts > latin modern fonts are not preloaded > languages > language en is active > {/home/cecil/ConTeXt/tex/texmf-context/fonts/map/pdftex/context/mkiv-base.map} > fonts > preloading latin modern fonts (second stage) > (/home/cecil/ConTeXt/tex/texmf-context/tex/context/base/type-siz.mkiv) > (/home/cecil/ConTeXt/tex/texmf-context/tex/context/base/type-otf.mkiv){/home/cecil/ConTeXt/tex/texmf/fonts/map/dvips/lm/lm-math.map}{/home/cecil/ConTeXt/tex/texmf/fonts/map/dvips/lm/lm-rm.map} > fonts > virtual math > unable to resolve name mapsfromchar > fonts > fallback modern rm 12pt is loaded > system > begin file test at line 1 > ! Undefined control sequence. > > system > tex > error on line 4 in file test.tex: Undefined > control sequence ... >

> I tried the first example from fill-in fields: \def\DVI{DVI} \def\PDF{PDF} \def\ACROBAT{Acrobat} \def\JAVASCRIPT{Javascript}

> 1 \starttext > 2 > 3 A few years back, \TEX\ could only produce > 4 >> \fillinfield [dvi]{\DVI} output, > 5 but nowadays, thanks to \fillinfield {Han The Thanh}, we can also > directly produce \fillinfield [pdf] {\PDF}! > 6 Nice eh? Actually, while the first field module was prototyped > 7 in \ACROBAT, the current implementation was debugged in > 8 \fillinfield [pdfTeX] {\PDFTEX}. Field support in \fillinfield > 9 [ConTeXt] {\CONTEXT} is rather advanced and complete and all > 10 kind of fields are supported. One can hook in appearances, and > 11 validation \fillinfield [JavaScripts] {\JAVASCRIPT}’s. Fields > 12 can be cloned and copied, where the latter saves some space. By > 13 using \fillinfield {objects} when suited, this module saves > 14 space anyway. > > l.4 \fillinfield > [dvi]{\DVI} output, > > What is happening here? > I guess Hans has removed some obsolete definitions :-)

Does not make a difference. I have the same problem.

strange. the error here is caused by the undefined '\DVI' macro (outdated context from 26.01.2011). loading the right module (preferred) or using a separate definition should solve this. is your fault caused by an undefined '\fillinfield' then? you can test it by replacing the '\DVI' macro with the text 'DVI'.

-- Cecil Westerhof

___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________

Am 05.04.2011 14:06, schrieb Cecil Westerhof:

2011/4/5 Peter Rolf mailto:indiego@gmx.net>

strange. the error here is caused by the undefined '\DVI' macro (outdated context from 26.01.2011). loading the right module (preferred) or using a separate definition should solve this.

is your fault caused by an undefined '\fillinfield' then? you can test it by replacing the '\DVI' macro with the text 'DVI'.

Does still not work: 9 >> \fillinfield [dvi]{DVI} output,

Or do you mean that \fillinfield is not defined. Which module should I use for this then?

yes, '\fillinfield' is not defined somehow. but the needed module 'scrn-fld.mkiv' should be loaded automatically in 'context.mkiv'. can you locate the file with mtxrun.exe --locate scrn-fld.mkiv

-- Cecil Westerhof

___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________

Am 05.04.2011 um 15:39 schrieb Cecil Westerhof:

/home/cecil/ConTeXt/tex/texmf-context/tex/context/base/scrn-fld.mkvi

Maybe the last one is wrong? .mkvi instead of .mkiv.

No, “mkvi” is a valid file extension for MkIV. The difference between a mkiv and a mkvi file is that you can use named parameters, e.g. \def\command#1#2{#1 : #2} can be written in a mkvi file as \def\command#first#second{#first : #second} Wolfgang

Am 05.04.2011 um 18:49 schrieb Peter Münster:

Wolfgang Schuster writes:

...

No, “mkvi” is a valid file extension for MkIV. The difference between a mkiv and a mkvi file is that you can use named parameters, e.g.

Hello,

Why mkvi and not mkv ?

I guess because mkvi has four letters like mkii and mkiv but mkv ha only three. Wolfgang

Am 05.04.2011 um 20:23 schrieb Aditya Mahajan:

BTW, does anyone has a minimal example on how to use mkvi syntax. I tried a few examples, but the best that I could do was using one of the mtx-* scripts to convert mkvi to tex (And that conversion does not work for \starttextdefinition ... \stoptexdefinition).

http://www.ntg.nl/pipermail/ntg-context/2010/054629.html <example> % macros=mkvi \def\one#one#two{#one : #two} \def\two{\dosingleempty\dofoo} \def\dofoo[#optional]#mandatory% {\iffirstargument #optional\else Hello \fi #mandatory} \starttext \one{A}{B} \foo{\ConTeXt!} \foo[Hi]{\ConTeXt!} \stoptext </example> Wolfgang

Cecil Westerhof writes:

I tried the first example from fill-in fields: \starttext

\usemodule[fields, abr-pseudocaps] \setupinteraction[state=start] \starttext -- Peter

On Tue, 5 Apr 2011, Cecil Westerhof wrote:

2011/4/5 Peter Münster

...

Cecil Westerhof writes:

...

I tried the first example from fill-in fields: \starttext

\usemodule[fields, abr-pseudocaps] \setupinteraction[state=start]

\starttext

That works. Now try to understand it.

http://www.pragma-ade.com/show-man-22.htm should be changed then.

You should also include this info on the wiki. Aditya