More font problems --- encoding errors

More font problems --- encoding errors

[Giuseppe Bilotta]

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

Re: More font problems --- encoding errors

[Hans Hagen]

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

Re[2]: More font problems --- encoding errors

[Giuseppe Bilotta]

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

Re[2]: More font problems --- encoding errors

[Giuseppe Bilotta]

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

Re[2]: More font problems --- encoding errors

[Hans Hagen]

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