ePub and Fonts

While developing AZARDI, we had to look at a lot of ePub books, and what was currently being made. It also meant working pretty hard with the specifications. There is nothing like a bit of intensive software testing for an organic reader to see what is going on around the place.

One of the big features we wanted to implement was fonts. There are a number of reasons fonts should be able to be embedded in an ePub Reader:

1. Language support. Usually it's OK if you are connected to an OS (like AZARDI), the fonts will be there if the language declarations are correct. But it's sometimes better to make sure by including that Hindi, Arabic, Thai or Chinese font in the package.
2. Spot language support. Too often we get the three lines of Japanese in the middle of the English book, or some Latin Extended B set of characters, plus the inevitable Greek and Cyrillic. It's best to make a reduced version of the font covering just the required characters.
3. Special and Custom symbols. There are many symbols that are most correctly and/or more economically handled with fonts.
4. Decorative effects. OK, so the real reason is we just wanna make eBooks look as good as their print equivalents, but the above points are still valid.

The IDPF specification states in the OPS that fonts must be in the manifest, other than that there is nothing about how fonts should be handled. It does say that an appropriate media type (mime type?) should be given, but unfortunately there are no mime types for fonts that we could find. Embedded fonts makes sense, they are part of the package, and it is economical for the application to check for fonts in the manifest. So AZARDI looks for OTF and TTF in the package and loads them up ready for presentation action. 

Unfortunately the Adobe ePub Best Practices ePub doesn't put the fonts in the manifest. Nor do the few other books we have seen that are created with InDesign. Oops. They use a pure CSS-3 font path statement.OK it works in ADE, but it probably shouldn't. 

It makes sense that if the application has the font available, the CSS only needs standard font statements to display the appropriate font without loading up with local path statements.

So now we had a problem. Our objective is a "strict" ePub reader. If we are looking in the manifest for fonts, and they are not there, and we don't go looking through the package, Adobe app generated books are not going to look as wonderful on AZARDI. Do we go with the 800lb gorilla and cover the font src descriptor in CSS statement. The specification says the scr descriptor must be supported and we do. However we took the high path, we don't support font loading if the fonts are not in the manifest. We would love to be corrected if we are wrong with this approach. This is possibly one of those grayish areas where we hack around with interpretation, we miss the purpose of something as vital as the manifest. This is reinforced in the OPF required file statement.

Having said that, we are not exactly perfect. Due to limitations in the current version of Qt, the development application, we currently only support TTF - no OTF yet. But our intentions are honorable and this will be changed as soon as possible.

There are a number of other issues we found with respect to ADE and ODPF compliance which we will report on shortly (other than the obvious justified text thing). Some of them matter if your ePubs are going to be valuable into the future and not become an Adobe proprietary version of an ePub.

Comments

[sudha]

good

[Richard Pipe]

An update on font handling. We now handle TTF and OTF fonts.