MobileRead Forums - View Single Post

richardigp · 03-14-2009, 11:58 AM

Xenophon,

We have embedded fonts working on the 505 and use it to test commercial ePubs with embedded fonts nearly every day. The spec says use OTF preferrably, but it is up to the device what it handles. Devices do not have to handle fonts, or any fonts in particular. The mandatory points for embedded fonts if supported are: Font is in the manifest, must use the CSS2 descriptors, font must not map outside Unicode characters, must honor embedding properties.

The idea of the ePub package, if it is going to use embedded fonts, is that the fonts are in the ePub package itself. It is optional that a reader device can then choose to have the ability to use them or not.

Check it out here
You can see an example in the Hound of the Baskervilles downloadable from here. Its on the title page and part separator page after the introduction. Crack it open and have a look. This will work in AZARDI, ADE and the 505. Just a simple decorative effect to set the tone of the book. (the font credit is on the copyright page).

Nervously critical...
I am unsure about the technique of putting the fonts in the ///data/ directory and referring from the ePub stylesheet statement. It's not wrong insofar as there is no prohibition to referencing a font outside the ePub package, but obviously this is then not an embedded font. This effectively hardcodes the font to a device and has the potential of not working in the future, or across new and emerging devices.

It should be as simple as this...
The following example is from a commercial ePub book and has two fonts and the fonts are in a directory in the opf directory fonts/ (it didn't have to be called fonts, but that is moderately sensible). Note that the path is relative from where the stylesheet is in the base book directory along with the pages, etc. We don't really need to worry about anything else:

@font-face {
font-family: "Futura";
font-style: normal;
font-weight: normal;
src:url(fonts/TT0202M_.TTF);
}
@font-face {
font-family: "PizzaDude Pointers";
font-style: normal;
font-weight: normal;
src:url(fonts/PIZZADUDEPOINTERS.ttf);
}
The other font rule that ADE ignores (therefore maybe the 505), unless it has changed, is that fonts must be registered in the OPF manifest. That should look something like:

<item id="font21" href="fonts/PIZZADUDEPOINTERS.ttf" media-type="application/x-font-truetype" />

One manifest statement for each font. Fonts are pretty special in any OS. They have to be running to be used. In a desktop system a reader can pick up fonts through the OS if available. ADE uses Adobe Flash and it starts up the fonts from the CSS statement, which is OK for it, but is only half the answer.

Problems in Reader implementation...
Our AZARDI reference reader is programmed in PyQT and WebKit. It will not find fonts and start them from the CSS statement without programmatic involvement. AZARDI looks in the manifest; If fonts are there, they are started for the reading session. We could program it to look for fonts in the CSS, but that is off-specification and we have the "nasty strict" reference ePub Reader.

In its present version Qt only supports TTF, so that is what we use. It doesn't currently support OTF, but if fallback fonts were used, the bases would be covered - all fallback fonts have to be in the manifest. (ADE/505 support OTF fine because they are clever font people).

Internally, when a book is loaded a Reader supporting fonts should do something like read the manifest specifically looking for fonts it understands. If it finds them it starts them up for the book Reading session, and they are automatically available for the CSS, just like Operating System fonts. When the book is closed so are the internal fonts.

This way reading devices don't have to interprete CSS to know if a font is available, or if they have to start-up a font; reading devices dont have to be loaded up with fonts; and ePubs with embedded fonts are portable across devices that support embedded fonts.

And the rules are....!
So in summary there are just two simple rules for embedding fonts:

1. The font must be in the manifest and the package
2. The CSS reference must point to the font location in the package.

The rest is up to the Reading device or application.

ePub is in early days of development, and with this font issue ADE has not helped by loading fonts from the CSS without being in the manifest. This will get worse as more titles try to utilize in-line and out-of-line XML Islands.

Beware the fonts...
And a final word of caution, there are fonts and fonts. Most fonts from a reputable foundary will work fine; older fonts and free fonts (like we use in our demo products) need to be tested. Suspect the font if some work and one doesn't. To know a font is being handled correctly by a device make sure it is NOT installed on the operating system of your work station.

Maybe that was a bit technical, hope it helps.

03-14-2009, 11:58 AM	#28
richardigp Enthusiast Posts: 27 Karma: 18 Join Date: Dec 2008 Location: Currently living in Pune India Device: Sony	Xenophon, We have embedded fonts working on the 505 and use it to test commercial ePubs with embedded fonts nearly every day. The spec says use OTF preferrably, but it is up to the device what it handles. Devices do not have to handle fonts, or any fonts in particular. The mandatory points for embedded fonts if supported are: Font is in the manifest, must use the CSS2 descriptors, font must not map outside Unicode characters, must honor embedding properties. The idea of the ePub package, if it is going to use embedded fonts, is that the fonts are in the ePub package itself. It is optional that a reader device can then choose to have the ability to use them or not. Check it out here You can see an example in the Hound of the Baskervilles downloadable from here. Its on the title page and part separator page after the introduction. Crack it open and have a look. This will work in AZARDI, ADE and the 505. Just a simple decorative effect to set the tone of the book. (the font credit is on the copyright page). Nervously critical... I am unsure about the technique of putting the fonts in the ///data/ directory and referring from the ePub stylesheet statement. It's not wrong insofar as there is no prohibition to referencing a font outside the ePub package, but obviously this is then not an embedded font. This effectively hardcodes the font to a device and has the potential of not working in the future, or across new and emerging devices. It should be as simple as this... The following example is from a commercial ePub book and has two fonts and the fonts are in a directory in the opf directory fonts/ (it didn't have to be called fonts, but that is moderately sensible). Note that the path is relative from where the stylesheet is in the base book directory along with the pages, etc. We don't really need to worry about anything else: @font-face { font-family: "Futura"; font-style: normal; font-weight: normal; src:url(fonts/TT0202M_.TTF); } @font-face { font-family: "PizzaDude Pointers"; font-style: normal; font-weight: normal; src:url(fonts/PIZZADUDEPOINTERS.ttf); } The other font rule that ADE ignores (therefore maybe the 505), unless it has changed, is that fonts must be registered in the OPF manifest. That should look something like: <item id="font21" href="fonts/PIZZADUDEPOINTERS.ttf" media-type="application/x-font-truetype" /> One manifest statement for each font. Fonts are pretty special in any OS. They have to be running to be used. In a desktop system a reader can pick up fonts through the OS if available. ADE uses Adobe Flash and it starts up the fonts from the CSS statement, which is OK for it, but is only half the answer. Problems in Reader implementation... Our AZARDI reference reader is programmed in PyQT and WebKit. It will not find fonts and start them from the CSS statement without programmatic involvement. AZARDI looks in the manifest; If fonts are there, they are started for the reading session. We could program it to look for fonts in the CSS, but that is off-specification and we have the "nasty strict" reference ePub Reader. In its present version Qt only supports TTF, so that is what we use. It doesn't currently support OTF, but if fallback fonts were used, the bases would be covered - all fallback fonts have to be in the manifest. (ADE/505 support OTF fine because they are clever font people). Internally, when a book is loaded a Reader supporting fonts should do something like read the manifest specifically looking for fonts it understands. If it finds them it starts them up for the book Reading session, and they are automatically available for the CSS, just like Operating System fonts. When the book is closed so are the internal fonts. This way reading devices don't have to interprete CSS to know if a font is available, or if they have to start-up a font; reading devices dont have to be loaded up with fonts; and ePubs with embedded fonts are portable across devices that support embedded fonts. And the rules are....! So in summary there are just two simple rules for embedding fonts: 1. The font must be in the manifest and the package 2. The CSS reference must point to the font location in the package. The rest is up to the Reading device or application. ePub is in early days of development, and with this font issue ADE has not helped by loading fonts from the CSS without being in the manifest. This will get worse as more titles try to utilize in-line and out-of-line XML Islands. Beware the fonts... And a final word of caution, there are fonts and fonts. Most fonts from a reputable foundary will work fine; older fonts and free fonts (like we use in our demo products) need to be tested. Suspect the font if some work and one doesn't. To know a font is being handled correctly by a device make sure it is NOT installed on the operating system of your work station. Maybe that was a bit technical, hope it helps.