Currently Being ModeratedJun 27, 2013 2:52 AM (in response to procrastinator)
Are you sure the text contains U+017F and is not relying on a typographical variant of normal s? Is there some way to download the view your .epub?
Currently Being ModeratedJun 27, 2013 6:03 AM (in response to Tom Gewecke)
Yes, the HTML source contains this character both as an entity reference and the unicode glyph.
there is a public photostream with three images in it. The first one shows HTML source, the second one is how it is rendered in Safari on Mac OS, and the third is how it looks on an iPhone 5 with iOS 6. The screenshot is from Safari, but in iBooks on iOS on this particular iPhone, it looks exactly the same.
Currently Being ModeratedJun 27, 2013 8:06 AM (in response to procrastinator)
How exactly are you transferring your .epub file to your iOS device?
Does your .epub file look ok on your non-iOS device using something like Calibre or Adobe Digital Editions?
Currently Being ModeratedJun 27, 2013 1:08 PM (in response to Tom Gewecke)
I transferred the file via Calibre to iTunes and it was synced to iPhone from there. And yes, it looks OK in Calibre. Adobe Digital Editions gets the ſ right, but doesn't support the combined umlauts (a,u,o combined with a small superscript "e").
Anyway, I doubt that it is an issue with the file transfer between devices, since the example screenshots I published on Fotostream are both created by accessing the same index.html on a local HTTP server from the unzipped ePub with Safari, and the font is embedded using standard CSS techniques. The font is a TrueType font, as opposed to OpenType, which seems to be mandated by HTML standards, but it is still surprising that Safari on Mac OS is OK and on iOS it simply shows a standard "s".
Currently Being ModeratedJun 27, 2013 1:25 PM (in response to procrastinator)
it is still surprising that Safari on Mac OS is OK and on iOS it simply shows a standard "s".
More than surprising! I don't know of any process by which a hardcoded U+017f could be displayed as a standard "s". I think it would require some kind of "normalization" to replace characters by their Unicode compatiblity decomposition on the way to the ibooks app.
iBooks Author automatically embeds fonts, and I have no problem generating a test book that displays this character correctly in iBooks using fonts not present in iOS.
Have you experimented using any different fonts specified in your css to see if the same thing happens?
Currently Being ModeratedJun 27, 2013 1:56 PM (in response to Tom Gewecke)
Yes, in the meantime I found out that it could actually be an issue with the font itself. The typographic system or something in that font seems to have an automatic detection of when - according to german writing rules - in historical texts the "long-s" is supposed to be used, and automatically translates normal "s" to "long-s", so setting the glyph explicitly to U+017F seems to confuse this logic somehow. I don't know whether this is something that could be programmed into a font, but this is so far the only explanation I could find. In the same way it seems to insert ligatures where they belong according to blackletter typesetting rules, but it sometimes seems to get it wrong, because ligatures should never span syllable boundaries, which however they sometimes do with that font. It is called "LFOAtlantisFraktur".
Currently Being ModeratedJun 27, 2013 2:29 PM (in response to procrastinator)
Yes, in the meantime I found out that it could actually be an issue with the font itself.
Interesting! I see they have few different types you can choose from
In my simple test I used a font called UnifrakturMaguntia
Currently Being ModeratedJun 27, 2013 2:48 PM (in response to Tom Gewecke)
Thanky you, now I tried with a different font from the same free font site, specifically designed for web use: LFUWeiynckNetz.woff. Now everything works as expected!