[Xmlgraphics-fop Wiki] Update of "TrueTypeInPostScript" by JeremiasMaerki

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Xmlgraphics-fop Wiki" for change notification.

The "TrueTypeInPostScript" page has been changed by JeremiasMaerki.
The comment on this change is: Some thoughts and pointers for implementing TrueType support with PS output.
http://wiki.apache.org/xmlgraphics-fop/TrueTypeInPostScript

--------------------------------------------------

New page:
= Implementing TrueType support for PostScript output =

== Introduction ==

I (JeremiasMaerki) was asked to compile some pointers and hints concerning the addition of TrueType/OpenType support for PostScript output. At the moment (Mai 2010), we only support Type 1 fonts in PostScript output.

== Requirements ==

 * The PostScript renderer/painter shall learn to support Asian fonts including Chinese, Japanese and Thai fonts. (This does not necessarily mean the inclusion of non-LR-TB writing modes!)

== Gathered hints and thoughts ==

Implementing TrueType support for Asian fonts ultimately requires the introduction of CID-keyed fonts much like we have in PDF output. Some of the supplemental technical notes associated with
the PostScript reference are going to be important here, so it's a good idea to follow the references in the PS reference.

TrueType support was introduced during the transition from PS level 2 to
3. Some late level 2 interpreters (version >= 2010) have support for Type 42 (TrueType)
fonts. Of the level 3 interpreters, all do. We should probably limit support for TrueType to level 3 PostScript so we can reduce support issues.

There are several approaches to handling TrueType fonts, like in PDF.
One is to create multiple single-byte encodings like we do for Type 1
fonts (encoding-mode="single-byte" in FOP's configuration). The other
is CID-keyed fonts which are a bit more complex (default mode with PDF
output when using TTF fonts). In both cases it should be possible to
work with TTF subsets.

It seems to be possible to incrementally define a TTF
font in PS (keyword: GlyphDirectory). However, that could interfere with
DSC-compatibility (i.e. when people want to extract single pages from a
larger PS file. The Windows PS drivers I checked all performed
incremental font definition and used indexes into the GlyphDirectory for
glyph selection. I think that's not what we'll want. We should probably go for full
font embedding and then use the GID from the TTF file to access the
glyphs.

Like we do with PDF output, we should only implement TTF subsetting if we
take the CID-keyed font route. Due to the learning curve, it is suggested to
implement full embedding and multiple single-byte encodings
(encoding-mode="single-byte") first and subsetting later (if necessary at all).
Keep in mind that full font embedding may offer the possibility to
pre-install a font on the printer and just reference it in PostScript.
However, I've never worked with TrueType fonts on PostScript so I can't
tell how it works and if GhostScript supports this, too.

At any rate, don't miss the informative figure 5.10 on page 367 in PSLR
3rd edition and compare that with figure 5.5 on page 329 (the one for
Type 1 fonts). It shows how PostScript resolved input data to actual glyphs.

I'm not sure about the implications, but page 369 says that most "show"
variants cannot be used with CID fonts. That means that the way text is
generated may have to be changed significantly when a CID-keyed font is
used.

On the FOP side, most of the font loading code can probably be
reused. PS needs more or less the same information as PDF. Hex encoders
are available, too. With single-byte mode, you'll get a SingleByteFont.
With Unicode mode, you'll get a MultiByteFont. In case writing CMap
resources is necessary, take a look at the code in the PDF library. The
CMap file format is directly used by PDF so factoring out the specifics
may be possible. Other important classes on the FOP side are:

 * org.apache.fop.render.ps.PSFontUtils
 * org.apache.fop.render.ps.FontResourceCache

When implementing this don't forget that there are three places where
TrueType-specific code may have to be implemented:

 * PSRenderer
 * PSPainter
 * PSTextPainter (for SVG text)

In case OpenType fonts with CFF glyphs shall be used, it may actually make sense to add CFF
support to our TrueType/OpenType loading code and try to use the CFF glyphs in
PostScript since PS supports CFF fonts (Type 2 fonts). However, I don't
know if there are any insurmountable differences between PS CFF support
and CFF support of OpenType. But probably not.

An important task is probably checking the Adobe Glyph list if all the
necessary Chinese glyphs have Adobe names. If not, it may get difficult
to support Chinese with multiple single-byte encodings. But even if that
is so (and it probably is), it may actually be worthwhile to do single-byte before the CID
approach to flatten the learning curve a bit.

Finally, always keep DSC-compliance in mind. It should be possible to
create a large PS spool file with FOP and the printer operator should be
able to extract certain pages using a DSC tool (i.e. his spooler) for
reprints without actually having to run the full PS program and
suppressing the unwanted pages. To test this, the DSC parser in XML
Graphics Commons can be used. XGC has a demo program
(DSCProcessingExample1.java) that can extract pages.

== Useful links ==

 * http://www.adobe.com/devnet/postscript/
 * http://www.answers.com/topic/postscript-fonts-1

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-commits-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-commits-help@xmlgraphics.apache.org