* More font problems --- encoding errors @ 2001-12-26 15:44 Giuseppe Bilotta 2001-12-27 13:27 ` Hans Hagen 0 siblings, 1 reply; 5+ messages in thread From: Giuseppe Bilotta @ 2001-12-26 15:44 UTC (permalink / raw) Hello, still testing the use of non-CMR fonts in ConTeXt ... if you recall I was using \setupencoding[default=8r] \usetypescript[berry][8r] \setupbodyfont[pos] \useregime[il1] And everything appeared to work correctly (apart from the [sans] instead of [mono] error in courier). Now I discovered that \useregime was doing nothing --or rather, it didn't really *enable* the regime. So I switched to \enableregime. And voilá, I found a bug. Try the following text: \def\text{«Questa è una prova per l'uso delle lettere accentate, e devo proprio dire che pare funzionare. Perciò i problemi che tu sembri avere non sono presenti nel mio sistema. Perché? Cosa c'è di diverso nelle nostre installazioni? Di più non posso dire.»} \text without \enableregime; it works correctly (accented letters have accents, guillemots are taken from the font). Now try it WITH enableregime: in my installation this removes the accents from the letters (accents not found) and the guillemots are fake (taken from the math font). My limited debug showed that: (1) encoding 8r (from enco-tbo.tex) does NOT define leftguillemot and rightguillemot (they are there at positions 171 and 187) (2) if I add an \enableencoding[8r][main] *after* setting up the bodyfont, I get the accented letters (but because of (1) I don't get real guillemots); yet the encoding gets reset when changing font (e.g. when switching to \tt or \ss). Is this WAD (Working As Designed) or a bug? Shouldn't the encoding be tied to the font? 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? 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 \startencoding[default] \definecharacter leftguillemot {\dontleavehmode\hbox{\raise.25ex\hbox{$\scriptscriptstyle\ll$}}} \definecharacter rightguillemot {\hbox{\raise.25ex\hbox{$\scriptscriptstyle\gg$}}} \stopencoding \startencoding[8r] \definecharacter leftguillemot 171 \definecharacter rightguillemot 183 \stopencoding in my cont-loc.tex file. -- Giuseppe "Oblomov" Bilotta ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: More font problems --- encoding errors 2001-12-26 15:44 More font problems --- encoding errors Giuseppe Bilotta @ 2001-12-27 13:27 ` Hans Hagen 2001-12-28 9:48 ` Re[2]: " Giuseppe Bilotta 2001-12-28 21:35 ` Giuseppe Bilotta 0 siblings, 2 replies; 5+ messages in thread From: Hans Hagen @ 2001-12-27 13:27 UTC (permalink / raw) Cc: ntg-context 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 ------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re[2]: More font problems --- encoding errors 2001-12-27 13:27 ` Hans Hagen @ 2001-12-28 9:48 ` Giuseppe Bilotta 2001-12-28 21:35 ` Giuseppe Bilotta 1 sibling, 0 replies; 5+ messages in thread From: Giuseppe Bilotta @ 2001-12-28 9:48 UTC (permalink / raw) Cc: ntg-context Thursday, December 27, 2001 Hans Hagen wrote: >>Is this WAD (Working As Designed) or a bug? Shouldn't the encoding >>be tied to the font? HH> right, normally one does never set the encoding, the font switch does (and HH> therefore the typescript files should mention =8r somewhere; i probably HH> have to add a couple of 8r's here and there; btw, is 8r really used?). Yes it is, that's how these problem surfaced :-) >>\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? HH> indeed, and if it goes wrong, then there is a bug; do you use the latest HH> beta? I have 2001.07.10 HH> ... in my local typeface files -) I know that you have cont-loc.tex, but HH> since that one is pretty experimental and only for very special use; use HH> cont-new instead; since cont-loc is not (and will never be) part of the HH> distribution, stuff in there may conflict (actually, there is some already HH> replace font stuff in there (esp some changed in the way font attrs like HH> encoding are resolved); did you try these things without cont-loc.tex HH> available?) Uh, I'm not using the cont-loc you gave me (for that precise reason), but a new, empty one :-) Since those things are encoding-specific and not typescript specific, I thought they had to go to cont-new or cont-loc, rather. Anyway ... Now I'll check out the small caps thing. -- Giuseppe "Oblomov" Bilotta ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re[2]: More font problems --- encoding errors 2001-12-27 13:27 ` Hans Hagen 2001-12-28 9:48 ` Re[2]: " Giuseppe Bilotta @ 2001-12-28 21:35 ` Giuseppe Bilotta 2001-12-29 11:32 ` Hans Hagen 1 sibling, 1 reply; 5+ messages in thread From: Giuseppe Bilotta @ 2001-12-28 21:35 UTC (permalink / raw) Cc: ntg-context Thursday, December 27, 2001 Hans Hagen wrote: >>(1) encoding 8r (from enco-tbo.tex) does NOT define leftguillemot >>and rightguillemot (they are there at positions 171 and 187) HH> actually, that part was never really finished, the same for dashes -) I think the font- and char- encoding should be a top priority. Now, if ConTeXt was on CVS and I had access to it, I could really give a hand in this very mechanical part. HH> indeed, and if it goes wrong, then there is a bug; do you use the latest HH> beta? Looking better, it's version 2001.12.10 (Now which is the month and which is the day?) -- Giuseppe "Oblomov" Bilotta ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re[2]: More font problems --- encoding errors 2001-12-28 21:35 ` Giuseppe Bilotta @ 2001-12-29 11:32 ` Hans Hagen 0 siblings, 0 replies; 5+ messages in thread From: Hans Hagen @ 2001-12-29 11:32 UTC (permalink / raw) Cc: ntg-context At 10:35 PM 12/28/2001 +0100, Giuseppe Bilotta wrote: >Thursday, December 27, 2001 Hans Hagen wrote: > > >>(1) encoding 8r (from enco-tbo.tex) does NOT define leftguillemot > >>and rightguillemot (they are there at positions 171 and 187) > >HH> actually, that part was never really finished, the same for dashes -) > >I think the font- and char- encoding should be a top priority. > >Now, if ConTeXt was on CVS and I had access to it, I could really >give a hand in this very mechanical part. sure, but since then i would have to keep yet another tree since we're rather dependent on knowing the internals, esp since we have experimental (new) stuff running here, which i have to keep in sync. With systems like tex there is a danger in cvs. Where in a program a bug fix results in better performance or correct behavior, in a more fuzzy system personal preferences can lead to conflicts (imagine that one changes default values in the layout); Esp font / character / language related things should be discusses beforehand. I'm currently not working on encodings, so ... one reason why i didn't yet add things like guillemots and emdashes to the encoding is that it is far from clear what should be a character and what a symbol. Take the euro: for a long time it was a symbol, but now fonts seem to get it, which makes it a character. If we consider << and >> as well as --- punctuation, it is probably ok to treat them as character which means that they will be part of encoding vectors. So, if you can complete the list of punctuation things for the vectors we can move them into the vectors. Euro's, Dollars, Pounds, Yens and whatever are probably best off being symbols. >HH> indeed, and if it goes wrong, then there is a bug; do you use the latest >HH> beta? > >Looking better, it's version 2001.12.10 (Now which is the month >and which is the day?) well, since i could not upload in oct, and got thinsg running again in december ... 12 must be the month -) 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 ------------------------------------------------------------------------- From owner-ntg-context@let.uu.nl Thu Jun 20 19:30:37 2002 Message-Id: <5.1.0.14.1.20010620015243.031eafa8@server-1> To: gloonie@telocity.com From: Hans Hagen <pragma@wxs.nl> Cc: ntg-context@ntg.nl In-Reply-To: <200206171725.18058.gloonie@telocity.com> References: <200206162221.26518.angerweit@gmx.net> <200206162221.26518.angerweit@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ntg-context@let.uu.nl Date: Wed, 20 Jun 2001 01:54:29 +0200 Subject: Re: Turkish language ini file Status: O At 05:25 PM 6/17/2002 -0400, Glenn R. Williams wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Hi All, > >Does anyone know have a Turkish language file (cont-tr.ini)? I notice >references for Turkish, but the distribution does not contain pertinent >files. watch out: cont-<language code> is reserved for an interface! what you probably want is turkish language support: texexec --make --language=tr,en (given that you have patterns) and then use the english interface with: \mainlanguage[tr] 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 ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf ------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2001-12-29 11:32 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-12-26 15:44 More font problems --- encoding errors Giuseppe Bilotta 2001-12-27 13:27 ` Hans Hagen 2001-12-28 9:48 ` Re[2]: " Giuseppe Bilotta 2001-12-28 21:35 ` Giuseppe Bilotta 2001-12-29 11:32 ` Hans Hagen
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).