xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bertrand Delacretaz" <bdelacre...@apache.org>
Subject Implementing OpenType font support, how hard?
Date Wed, 02 Aug 2006 14:33:59 GMT
Hi FOP team,

(sorry about the long message, but there's quite a lot of stuff to explain)

I *might* have a need and budget to improve the support of OpenType
fonts in FOP in the next few weeks.

We had a quick talk about this with Jeremias at ApacheCon EU, and now
I need to estimate how hard/long this could be.

I'll list the various steps that I imagine are needed. Please bear
with me if there's some sillyness below, I don't know much about how
FOP handles fonts so I might be totally off on some assumptions.

My target output is only PDF at this point, I haven't looked at the
issues for other formats.

If you're not familiar with what OpenType brings to fonts (in addition
to extended character sets, and usually high quality fonts), the
BelloPro tester [2] is quite convincing IMHO.

Feedback and alternative ideas are welcome!


1) My understanding of the current situation.
FOP allows user-specified fonts to be used and embedded in the generated PDF.

Provided utilities ("font file readers") convert PostScript Type 1 and
TrueType fonts to XML files storing font metrics and kerning
information.

The TrueType utility should be able to handle OpenType fonts which
contain TrueType outlines (in my tests it worked with some fonts, but
PDF embedding was not correct for the MacOSX Preview app, although
Adobe Reader was fine). OpenType fonts with Type 1 outlines are not
usable in FOP currently.

At the layout stage, FOP uses "static" font metrics to find the size
of a character: FOP asks the Font object "what are the metrics of this
character". This works one character at a time, which would prevent a
smart Font from performing ligature substitutions, for example (where
e.g. "ffi" is mapped to a single glyph).

When generating PDF, FOP embeds the font, subsetting it if it's a
TrueType font (e.g. storing only glyphs that are actually used in the
document).

Kerning does not work in the FOP trunk currently, the corresponding
code is commented out.


2) Steps for simple support of OpenType fonts

2a) Write an OpenTypeFontFileReader, factoring out and reusing code of
the TrueType and Type 1 readers to support OpenType fonts having
either Type 1 or TrueType outlines.

2b) Complete the font embedding code so that it works for both
OpenType outline variants (maybe ignoring subsetting if it makes it
easier)

2c) Verify that the character encodings are correct when embedding the
font, might need improvements? [1] seems to imply that this is
problematic currently.

2d) Re-enable kerning, as OpenType fonts are usually of high quality
and "deserve" to be used with automatic kerning.


3) Additional steps for OpenType GSUB table support
The goal is to enable the "smart font" features of OpenType, automatic
ligatures as mentioned above, language-dependent glyph substitutions
(different shapes if a letter is at the beginning of a word for
example), automatic decorative swashes at the beginning or end of
words, etc.

3a) Decode the GSUB table of the OpenType font (and other tables that
might be required to use it) and store its data in the FOP XML font
metrics file

3b) Modify the chars-to-metrics mapping to handle things like
automatic ligatures, where several chars map to a single glyph

3c) Implement GSUB table handling, glyph substitutions (or reuse an
existing library for this, but the only one that I've found is
freetype, haven't found one in Java).

3d) Create test documents to demonstrate this, asking a font provider
for a donation of some OpenType fonts to use in FOP tests.

Even this wouldn't be complete, as OpenType allows specific features
to be enabled for specific character runs, like "use alternate glyph
set 2 for this character only". But it would be a good start already
;-)

At this point I'm mostly interested in your opinion on points 1) and
2) above, if these enhancements seem realistic I might be able to work
on them in my current project. Point 3) obviously needs more work and
might not fit my budget at this point.

Thanks for any feedback on this!
-Bertrand

[1] http://xmlgraphics.apache.org/fop/0.20.5/fonts.html#embedding
[2] http://www.underware.nl/site2/index.php3?id1=bello&id2=testbello

Mime
View raw message