ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Peter Rolf <indiego@gmx.net>
To: ntg-context@ntg.nl
Subject: Re: Using forms and saving values
Date: Tue, 05 Apr 2011 12:50:34 +0200	[thread overview]
Message-ID: <4D9AF3FA.4060604@gmx.net> (raw)
In-Reply-To: <BANLkTim-1BzpPdCYjtRQg282JJf5jnYMOg@mail.gmail.com>

Am 05.04.2011 12:31, schrieb Cecil Westerhof:
> 2011/4/5 Peter Rolf <indiego@gmx.net <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
> ___________________________________________________________________________________

___________________________________________________________________________________
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
___________________________________________________________________________________

  reply	other threads:[~2011-04-05 10:50 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-03 11:00 Cecil Westerhof
2011-04-04 18:29 ` Wolfgang Schuster
2011-04-04 21:01   ` Cecil Westerhof
2011-04-05  1:19   ` Cecil Westerhof
2011-04-05  7:45     ` Peter Rolf
2011-04-05 10:31       ` Cecil Westerhof
2011-04-05 10:50         ` Peter Rolf [this message]
2011-04-05 12:06           ` Cecil Westerhof
2011-04-05 12:41             ` Peter Rolf
     [not found]               ` <4D9B14C3.8040707@wxs.nl>
2011-04-05 13:38                 ` Peter Rolf
2011-04-05 13:42                   ` Cecil Westerhof
2011-04-05 13:54                     ` Peter Rolf
2011-04-05 15:26                       ` Wolfgang Schuster
2011-04-05 13:39               ` Cecil Westerhof
2011-04-05 13:45                 ` Wolfgang Schuster
2011-04-05 16:49                   ` Peter Münster
2011-04-05 16:56                     ` Wolfgang Schuster
2011-04-05 18:23                       ` Aditya Mahajan
2011-04-05 18:32                         ` Wolfgang Schuster
2011-04-05 17:52                     ` Martin Schröder
2011-04-05 13:48     ` Peter Münster
2011-04-05 13:53       ` Cecil Westerhof
2011-04-05 14:03         ` Aditya Mahajan
2011-04-05 14:31           ` Cecil Westerhof

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D9AF3FA.4060604@gmx.net \
    --to=indiego@gmx.net \
    --cc=ntg-context@ntg.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).