From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.tex.context/6413 Path: main.gmane.org!not-for-mail From: Hans Hagen Newsgroups: gmane.comp.tex.context Subject: Re: More font problems --- encoding errors Date: Thu, 27 Dec 2001 14:27:34 +0100 Sender: owner-ntg-context@let.uu.nl Message-ID: <5.1.0.14.1.20011227141026.03c798e8@server-1> References: <18511792590.20011226164438@bigfoot.com> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Trace: main.gmane.org 1035396944 10403 80.91.224.250 (23 Oct 2002 18:15:44 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 23 Oct 2002 18:15:44 +0000 (UTC) Cc: ntg-context@ntg.nl Original-To: Giuseppe Bilotta In-Reply-To: <18511792590.20011226164438@bigfoot.com> Xref: main.gmane.org gmane.comp.tex.context:6413 X-Report-Spam: http://spam.gmane.org/gmane.comp.tex.context:6413 At 04:44 PM 12/26/2001 +0100, Giuseppe Bilotta wrote: i will come back to this once i can print your mail and read it more precise -) >(1) encoding 8r (from enco-tbo.tex) does NOT define leftguillemot >and rightguillemot (they are there at positions 171 and 187) actually, that part was never really finished, the same for dashes -) >Is this WAD (Working As Designed) or a bug? Shouldn't the encoding >be tied to the font? right, normally one does never set the encoding, the font switch does (and therefore the typescript files should mention =8r somewhere; i probably have to add a couple of 8r's here and there; btw, is 8r really used?). >Ok, I think I found the problem: in the berry font definitions, if >I add [encoding=8r] to each of the definefontsynonym line I get >the correct result. I assume this has to be done for the ec >variant as well. So the question is: shouldn't the synonyms get the >same properties as the other when not overriden? I mean: consider >for example: > >\definefontsynonym >[Times-Roman] [\typefaceencoding-utmr8a] [encoding=\typefaceencoding] >(called with typefaceencoding=8r) >\definefontsynonym [8r-utmr8a] [ptmr8r] > >Shouldn't in the end the ptmr8r be called with the encoding 8r >defined in the previous synonym? indeed, and if it goes wrong, then there is a bug; do you use the latest beta? >Now, regarding problem (1): how do I force ConTeXt to get the >guillemots from the font? In a rather more general context (;->) I >figure the error resides in defining a mappable character (the >guillemots) in raw mode. Instead, \leftguillemot and >\rightguillemot should follow encoding mappings; this should also >be true, for example for subguillemots, and more in general for >other characters as well. > >As a temporary patch I have > >\let\leftguillemot\undefined >\let\rightguillemot\undefined better \def\leftfake.....{....} >\startencoding[default] > >\definecharacter leftguillemot >{\dontleavehmode\hbox{\raise.25ex\hbox{$\scriptscriptstyle\ll$}}} {\leftfake...} >\definecharacter rightguillemot >{\hbox{\raise.25ex\hbox{$\scriptscriptstyle\gg$}}} >\stopencoding > >\startencoding[8r] > >\definecharacter leftguillemot 171 >\definecharacter rightguillemot 183 > >\stopencoding ok, i patched this ... >in my cont-loc.tex file. ... in my local typeface files -) I know that you have cont-loc.tex, but since that one is pretty experimental and only for very special use; use cont-new instead; since cont-loc is not (and will never be) part of the distribution, stuff in there may conflict (actually, there is some already replace font stuff in there (esp some changed in the way font attrs like encoding are resolved); did you try these things without cont-loc.tex available?) 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 -------------------------------------------------------------------------