"Jeff Zhang" <[EMAIL PROTECTED]> wrote:
> After correct the name, it can produce ps file without error message.
> However, it almost can't be converted into pdf by ps2pdf or to view it by
> gv, for it runs very long time to convert and I have to kill ps2pdf.
Yes, I know that for whatever reason, if you use ps2pdf
to distill Heirloom dpost output containing a very large
TrueType font (auto-generated Type 42, more exactly), it
seems to run forever. I do not know exactly what the
problem is; since pure gs as invoked by gv can read the
file, although slowly, it does not seem to be an encoding
error.
If you use FontForge to print such a font, ps2pdf will
generate output at the end, after consuming several
minutes CPU time, so an enhancement should be possible.
I just do not know what to change.
> The
> problem can't be solved even I use fontforge to generate afm file for the
> ttf file.
No, if you generate an AFM file and continue to use
the TTF for glyph data, the actual output of dpost does
not change. However, you can generate a CFF-based OTF
font and use it for both metrics and glyph data. There
seem to be no problems with ps2pdf then; distilling it
takes a long, but reasonable amount of time.
Adobe Distiller, by the way, will abort with an error
in all cases described, so spending money is not an
alternative here.
What I did not test, but what could work: 1. Use some
other tool, like FontForge, to create a Type 42 font,
and include that instead of the one generated by dpost;
2. do not embed glyph data in the PostScript output at
all but load the TTF in Ghostscript. Ultimately, the
last option might be most reasonable since it seems
the only way which could speed up the font loading
process. A non-subsetted Type42 font will always be
about twice the size of the TrueType font, and will
consume much time to process for that reason alone.
Or is there somebody reading who knows how to create
better Type 42 fonts for very large TrueType input?
Gunnar
