Subject: Re: problem generating postscript
From: Vlad Harchev (hvv@hippo.ru)
Date: Sun Feb 04 2001 - 12:56:10 CST
On Sun, 4 Feb 2001, Tomas Frydrych wrote:
>
> 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.
I am and will be glad that I was helpful. Feel free to ask for help any time
you need it.
> 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.
I think glyph names (as included in .pfm or .afm) could be or are acquired by
xap_UnixPSParseAFM.c too. So if we have afm for the font with glyph names
matching the ones in pfm or ttf (are names stored in ttfs somehow?), we know
what glyph names to use exactly (provided glyph names are standard adobe's or
of the form /uniXXXX). So no problem here IMO.
As for non-standard glyph names by MS, I think we can fix these fonts to use
adobe glyph names or as you propose provide 'fontfilename.u2g' or similar. So
I also don't see any problem here.
> Tomas
>
>
Best regards,
-Vlad
This archive was generated by hypermail 2b25 : Sun Feb 04 2001 - 13:28:33 CST