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? Cheers, Tomas -- UNSUBSCRIBE: mailto:[email protected]?subject=unsubscribe
