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