How to show Greek and Hebrew fonts when exporting an ePub?

I've got some documents that are mostly in English, but have a handful of Greek and Hebrew words. Is there a way to have these show up in the ePub export? I'm viewing them in iBooks on my iPad, and I need to be able to readjust the font size.

If you simply use the system level services, you will get character codes in ISO10646/Unicode. These character codes have the property of world script defined (GREEK CAPITAL LETTER ALPHA as opposed to LATIN CAPITAL LETTER A) and they have the property of direction also.

Dr Joseph Becker who wrote the Unicode Proposal in 1988 published an article in 1987 that argued for defining writing direction as a character property. His argument is that direction is defined at the character level, then automatically entering d-o-g in the Latin script which is written left to right will guarantee that it does not get drawn as g-o-d depending on where one did, or did not, remember to insert a control code for change of writing direction in mixed left to right and right to left copy.

Document markup models define logical organisation, SGML-implementations including HTML and ePub follow that direction. In order to define layout organisation, and embed font identifiers and glyph identifiers, one has to have a PDL Page Description Language. There is PDF, but it is advisable to pick PDF only if one is working with what is technically termed 'tagged PDF' and Adobe XMP Extensible Markup Platform for PDF 1.4 and higher.

/hh

Experiment.

Pages should have no problem with Greek.

Hebrew is a R to L script which is not handled perfectly in OSX but should paste in properly from a web source or application like Mellel. Editing R to L scripts in Pages is made difficult by misplaced cursors.

Peter

But you didn't answer my question, or if you did, I misunderstood it. Is it possible to create an ePub that will have Greek and Hebrew words displayed correctly within the a paragraph of English?

Your question was answered: Several writing systems in several world scripts can by definition be interspersed because writing direction is defined at the character level in ISO10646/Unicode.

ePub deals with the domain of information and logical organisation, PDF deals with the domain of imaging and layout organisation. PDF encodes font IDs and glyph IDs in a layout organisation, but not character information and logical organisation - thus the appearance is applied by the author. ePub encodes character information and logical organisation, but not font IDs and glyph IDs in a layout organisation - thus the appearance is applied by the audience.

/hh

Are you sure that the short set of fonts available on the iPad may display Greek and Hebrew characters ?

Yvan KOENIG (VALLAURIS, France) jeudi 3 février 2011 21:57:51

Henrik

I've said this before. You are like my wife.

Ask her the time, she tells you the weather.

Peter

The standard font with the large Unicode set is Lucida Grande, check what the default font in the ePub application is.

Peter

Would be useful to read :

http://support.apple.com/kb/HT4065?viewlocale=en_US

which give the list of fonts available on the iPad :

Fonts available on the iPad include:

American Typewriter
AppleGothic
Arial
Baskerville
Bodoni 72
Bradley Hand
Chalkduster
Cochin
Copperplate
Courier
Courier New
Didot
Futura
Geeza Pro
Georgia
Gill Sans
Heiti J
Helvetica
Hoefler Text
Marker Felt
Optima
Palatino
Papyrus
Party LET
Snell Roundhand
Thonburi
Times New Roman
Trebuchet MS
Verdana
Zapf Dingbats
Zapfino

Read also :

http://support.apple.com/kb/ht4168

You will get a lot of useful infos.

Yvan KOENIG (VALLAURIS, France) jeudi 3 février 2011 22:22:26

Thanks for that list Yvan,

Guess that rules out Lucida Grande.

I wonder if the fonts are the same as used in OSX and/or have clipped character sets.

That would explain the problem with non-Latin scripts.

I don't have an iPad so can not test the issue.

Peter

I've said this before.

The original post was based on the idea that ePub would work like PDF works. It doesn't. Font embedding is entirely appropriate to PDF which is about appearance. PDF has a fixed page format and fixed positions for graphic objects. Once you have a geometry, you can also add skewing, masking, stacking and so forth to objects in that geometry. This idea works well for distribution as printed paper, but it doesn't work well for distribution to digital graphic devices with really, really different formats. Here it works better to give a general description of the logical organisation, precisely describe the character information, and let the destination devices apply appearances. They may not apply precisely the same appearance, but the substance of what is being communicated will survive - the character information and the general logical organisation of the document.

Not a lot of people with a print background bother with tagged PDF 1.4+ or think twice about matching rendering order to reading order in PDF.

/hh

Hi, there is a Pages forum in the iPad forum too. People there might be have the answer.
_ http://discussions.apple.com/category.jspa?categoryID=267_

I'm looking for some specific things to try, to get the results that I am after.

If you would like to embed a specific font at a specific size, then you should probably be looking to some form of page description language, in this case PDF.

If you are trying to work with a specific font for Hebrew that is not a system font, there is a certain likelihood that the font is broken.

In this case, the font will try to change the input of character information instead of changing the output of imageable glyphs.

To determine if that is the problem, insert the cursor in a Hebrew word, open the Character Palette, open the Advanced menu at lower left, and select Show Character Selected in Application. If the character that is identified here is not the character you expected, then you have found a problem font.

Troubleshooting blind is what it is - tough 🙂.

/hh

should probably be looking to some form of page description language, in this case PDF.

The catch is that with complex scripts, PDF cannot embed what is technically termed the glyph run, that is, the source character string, the settings for feature selectors in the smart font (TrueType, OpenType), and the smart font itself.

What PDF can embed is one of two versions of the font model in PostScript language level 2, either splitting the smart font into subsets of 256 glyphs and embedding these as separate fonts or tiling the smart font across 256 subsets and embedding the single tiled font.

Splitting the smart font into subsets and embedding the subsets as separate fonts is printable on PostScript devices back to PostScript level 2 version 10. This is what Apple does. Tiling the font data and embedding depends on PostScript level 2 version 15 and is properly a PostScript level 3 feature (CID font specification). In both cases, the source character string is lost and recovery of the character information falls back on font-independent glyph identifers. Because Arabic and Indic depend on reshaping and reordering in glyph space, neither splitting into separate fonts or tiling into a single font will work for recovering the character information. It is necessary to embed the whole caboodle, characters, glyphs, and the mapping between them. Thomas Gewecke posted a link part of this discussion a while ago.

I'm sorry, this is technical prepress, but the point is that graphic information processing is in fact technical prepress. It's just that technical prepress has percolated down into system level services which are used by everyday endusers.

/hh