My thanks to Vlad for finding out how to input 16-bit chars into the
PS output, however, I have run into yet another, closely related,
problem.
The characters that are > 255 have to be output by name, and the
genaration of this name from our UCS-2 value turns out to be a
problem, because the name must be exactly as it is in the font in
question. Now, Adobe defines a standard set of names for about
1200 characters, but in addition a character can be named as
/uniXXXX where XXXX is the UCS value, or the font vendor can make
up proprietary names. Thus M$ uses its own names for many
glyphs in the poscript table in its TTF fonts, and so probably do
other vendors as well.
This has two implications; first off all, we might not be able to
corectly translate the Adobe glyph name into our UCS character.
This we can work around by insisting that the afm files for use with
AW use only the standard Adobe glyph names or the /uniXXXX
type names. For the ttf fonts I am currently modifying the ttf2afm
utility from the pdfTeX package to generate afm files using the later
convetion.
The second problem is worse: generation of the glyph name from
the UCS char for the PS output. I first thought that I will get around
this also by using the /uniXXXX names, thinking that the name
would be translated into the UCS value and the PS interpreter
would then look for the glyph using this value (e.g., if the font
contains a character called 'alef' with UCS value 0x05d0, I would
output into the PS file /uni05d0). This unfortunately does not work,
for at least ghostscript does only simple lookup by the glyph name,
and since the glyph is actually called 'alef' it will not find uni05d0.
The only solution that I can think of, is to have an additional file for
each font that would contain the UCS-2 to glyph name conversion
table for that font, 'fontfilename.u2g' or something. If no such file is
found for the font, then we will assume that the font uses the
standard Adobe glyph set and any glyhps not covered by it are in
the /uniXXXX format. I can modify the ttf2afm programme to
generate this file at the same time it generates the afm metrics file.
Now, if anyone can think of a better way to handle this problem, I
would appreciate some input.
Tomas
