From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.tex.context/4326 Path: main.gmane.org!not-for-mail From: Hans Hagen Newsgroups: gmane.comp.tex.context Subject: beta version with new encoding support uploaded Date: Mon, 12 Mar 2001 17:01:03 +0100 Sender: owner-ntg-context@let.uu.nl Message-ID: <3.0.6.32.20010312170103.0153c100@server-1> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: main.gmane.org 1035395005 24855 80.91.224.250 (23 Oct 2002 17:43:25 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 23 Oct 2002 17:43:25 +0000 (UTC) Original-To: ntg-context@ntg.nl Xref: main.gmane.org gmane.comp.tex.context:4326 X-Report-Spam: http://spam.gmane.org/gmane.comp.tex.context:4326 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 % % -> -> the same token % -> the mapped case token % -> namedtoken -> a remapped token % -> 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 -------------------------------------------------------------------------