the usage of 'idx' in my implementation had a serious flaw: Because the
unicod values in "glyphlist.txt" are partially sorted, we get a highly
: (depth *PsGlyph)
I rewrote it now using 'balance' (and made *Glyph to a local transient
> I also removed the "Ps" prefix of *PsGlyph as this unicode/glyph
> mapping is not specific to postscript.
(use (L C)
(while (setq L (line))
(unless (or (= "#" (car L)) (member " " L))
L (split L ";")
C (char (hex (pack (cadr L)))) )
(set (link C) (pack (car L))) ) ) ) ) ) ) )
With that, the depth is optimal now:
: (depth (val (loc "*Glyph" glyph)))
Then, to avoid the conflict with multiple values, I simply ignored all
lines with multiple values, by checking with (member " " L). Does this
sound reasonable? In this way the first entry in "lib/glyphlist.txt"
will "win". At least this is the simplest solution ;-)
> I would actually prefer keeping the complete mapping as in the
> original code I sent. That would allow searching through the fonts
> for the right glyph.
I see. For now I would like to stick with the simple version to see how
it works out. I have to be very careful, as "lib/ps.l" is used heavily
in several business applications.
> I prefer 'glyph' returning NIL instead of ".notdef".
OK, me too. Is it not necessary?
> I see that you define own encoding and add euro sign there.
Is this also not necessary? I took this from the PostScrip book. I never
understood if and why this font-definition stuff is really needed. How
else could we do it?
> all the other examples with utf strings worked only because
> ghostscript managed to find suitable font with the requested glyph.
> That did not unfortunately work for Cyrillic characters. Did it ever
> work for you with something else than ISOLatin1Encoding?
No. As you know, I explicitly converted it all to IsoLatin1 anyway,
(out (list "@bin/lat1" ...
I removed this out now, and the Euro is probably also not needed any
> it is used in '_ps'. I think the stringwidth computation won't work
> as expected if there are some glyphs in the string. What do you
Yes, this is the main problem.
Practically, it is not critical for me now, because the alignments are
used in my applications only for numeric values, and these won't change.
But it is very unsatisfactory.
I released now the current changes to the testing version.