xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: Implementing OpenType font support, how hard?
Date Wed, 02 Aug 2006 15:31:10 GMT
Salut Bertrand,

good to see you on this list again.

On 02.08.2006 16:33:59 Bertrand Delacretaz wrote:
> 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).

So far, that's correct.

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

No, I've been able to restore kerning support. If there's still some
commented code I should probably remove it now. Can you give me a

> 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.

I wonder if supporting Type 1 outlines would be worth the effort. So far,
I've never seen an OpenType font with Type 1 outlines. Have you?

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

Subsetting is not that complicated I think.

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

The problem is that FOP does not currently support generating a
ToUnicode table. Victor Mote has the fixed in FOray and we have a patch
in Bugzilla that uses that code to do the same for FOP. Since nobody has
dealt with the legal part of grabbing someone else's code in this case,
the patch hasn't been applied, yet.

The patch:

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

Ok, that should be obsolete.

One point about 2) is that Vincent Hennebert and Victor Mote are working
on FOrayFont to create a better font library which we'd like to use when
it's finished. So this may mean that some of this work would better be
done in/for ForayFont. Finishing 2) would then also mean finishing
FOrayFont to the degree that it can be used in FOP. I guess that will
need further deliberation.

> 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

One goal of FOrayFont is to make the separate metrics file obsolete. The
font files will be interpreted directly. This should also simplify the
whole system, especially for the user.

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

Here I think you can profit from my work on kerning to handle special

> 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.

That's one possibility. Another one might be the DejaVu fonts which we
have found after a LOT of searching for a font with an ASF-compatible
license. However, I haven't received any official feedback on license
compatibility, yet. OTOH, I'm not sure if those fonts will enable you to
show off all the features you want to implement.


> 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
> ;-)

:-) Sure.

> 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.

In general, I'm happy if we get some reinforcements on the font front.
2) shouldn't be a very big task. But I assume the whole FOrayFont thing
might make this a little more complicated.

AFAIK, OpenType allows different variants of a font in one font file
(ex. normal and bold). We've had requests to support those font files.
Have you found out during your investigations what would be involved in
supporting this and would this be in scope for your work? So far, I've
been unable to find out how this is handled.

> 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

Jeremias Maerki

View raw message