ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: "Robert F. Beeger" <5beeger@informatik.uni-hamburg.de>
Subject: Re: beta version with new encoding support uploaded
Date: Tue, 13 Mar 2001 15:13:12 +0100	[thread overview]
Message-ID: <5.0.2.1.2.20010313150522.00a71cc0@rzdspc1.informatik.uni-hamburg.de> (raw)
In-Reply-To: <3.0.6.32.20010312170103.0153c100@server-1>

Hi!

That sounds interesting and I think I would like to test it.
Does someone know how to install two versions of ConTeXt on one TeX-system 
so that I could say
texexec --pdf example
for a run in the stable version and
texexecb --pdf example
for a run in the beta version.

Is there a way to achieve this or must I have two TeX-systems each running 
one of the ConTeXt versions.
Does someone have Perl-scripts or anything in the way to install a beta 
version that it can coexist with the stable version.

Or how do you ConTeXt-gurus do it? Are you ever using the newest beta version?

Greets
    Robert

At 17:01 12.03.2001 +0100, you wrote:
>I hope that those who depend on accentted and non latin characters will
>read this and test / complete it. -)
>
>
>% Hi all,
>%
>% I have uploaded a new beta release with the extended
>% encoding macros. You will notice that there are enco-* and
>% regi-* files (so mktexlsr is needed).
>%
>% An encoding (enco-*.tex) is related to a font name, and is
>% rather unrelated to the input. Normally a user should not
>% use the related commands. The encoding is normally defined
>% with \definefontsynonym and will be turned on either with a
>% font switch or a font defined with \definefont. So,
>% \enableencoding is not really needed, except in special
>% cases!
>%
>% A regime (regi-*.tex) is related to the input and should be
>% enabled at the top of a file and the regime defs should be
>% loaded. When a default regime is enabled, all chars map
>% onto themselves. Otherwise, a regime maps characters onto
>% the internal representation. Upper/lowercase mapping will
>% (in most cases) handle both direct characters and remapped
>% ones.
>%
>% input         internal      font
>%
>% <char n> -> <char n>   -> <char n>   the same token
>%                        -> <char m>   the mapped case token
>% <char n> -> namedtoken -> <char x>   a remapped token
>%                        -> <char y>   a remapped case token
>%
>% When using characters >127 it is best to use a regime, even
>% when a direct mapping is possible. By doing so, output
>% mapping (as needed in specific pdf or unicode situations)
>% becomes possible. So, when using ec as input encoding and
>% font encoding, \enableregime[ec].
>%
>% The new mechanism is still not perfect and/or partially
>% tested. Getting things 100% okay is also up to you:
>%
>%
>% In the encoding files the named character lists should be
>% completed. The same should be done for the regime files.
>%
>% [In future versions uppercasing in headers and alike will
>% work, that is: it works here but is not yet part of the
>% core code.]
>%
>% [a next step will be sorting based on named glyphs]
>%
>% [these mechanisms are also more suited for future usage as
>% in omega etc]
>%
>% The encodings can be checked rather well with the commands
>%
>% \showaccents and \showcharacters
>%
>% like in:
>
>\starttext
>
>\setupcolors [state=start]
>
>\setupbodyfont [cmr] \showaccents \showcharacters
>\setupbodyfont [lbr] \showaccents \showcharacters
>\setupbodyfont [csr] \showaccents \showcharacters
>
>\stoptext
>
>% First I want to complete these lists for which i need your
>% help. Next we will add names special symbols, although
>% these may end up in the symbol modules.
>
>% You should be aware of the fact that from now on encodings
>% happen as automatically as possible and input encodings are
>% handled by regime modules. I tried to be upward compatible,
>% but the new way is: \useregime[windows] (loaded by default
>% but that may change) \enableregime[windows]. Of course we
>% can fight over the names.
>%
>% html and xml entities are under construction
>
>Hans
>
>-------------------------------------------------------------------------
>                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
>                       Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
>  tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
>-------------------------------------------------------------------------


  reply	other threads:[~2001-03-13 14:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-12 16:01 Hans Hagen
2001-03-13 14:13 ` Robert F. Beeger [this message]
2001-03-13 14:40   ` Berend de Boer
     [not found] ` <5.0.2.1.2.20010313150522.00a71cc0@rzdspc1.informatik.uni-h amburg.de>
2001-03-13 15:39   ` Hans Hagen
2001-03-13 14:40 siep.kroonenberg

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=5.0.2.1.2.20010313150522.00a71cc0@rzdspc1.informatik.uni-hamburg.de \
    --to=5beeger@informatik.uni-hamburg.de \
    /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).