Hi Alex,

> now I experimented a little with the glyphs. I would suggest that we
> use an 'idx' instead of an 'assoc' list, as there might be quite a
> lot of entries.

yes, seems like a good time for me to learn the new function:-)

> But now there are two things I don't understand:

Adobe has some more detailed explanation on their website which might
explain these things but I haven't had chance to study it yet.

> 1. You concatenated all names for glyphs with identical character code
>    into a single entry:
>       space;0020
>       spacehackarabic;0020
>    I'm doing the same above (the 'push'). But does that really make
>    sense? This would print all the names of a glyph when its character
>    code is processed.

I briefly guessed that one char could map to many glyphs and that
would compose the final picture.  But that was just a quick guess
which is probably wrong.

> 2. There are entries in "glyphlist.txt" that have more than one numeric
>    value following the semicolon, like
>    lamedholamdagesh;05DC 05B9 05BC
>    What do these numbers mean? How is the resulting unicode to be
>    calculated? You wrote
>>                   H (hex (pack (tail (- I) L))) )
>    but this surely won't work in such a multi-value case, right?

I did not notice this, this is a bug.  Not sure what that multi-value
case means.

> I tried it with the "app/" demo application. The german umlauts show
> up correctly (even without using "bin/lat1").

Good.  Even the Euro sign works (which could be removed from the
postscript header?).

> But if I try the Russian locale, it seems that all characters within
> a string are printed one over the other, all on the same spot. What
> might be the reason?

Strange, I don't see a reason for handling some characters differently
(not advancing the current point).  Does not have it something to do
with ghostscript/font instalation and/or missing font metric files?


UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe

Reply via email to