Quote:
Originally Posted by MicroDrie
When I look at the CSS file in the EPUB, I notice also a few other things.
First, the EPUB does not contain any fonts that a CSS rule can reference.
Second, a lot of different font types are mentioned, but there is no reference where they can be downloaded by the EPUB in the CSS file.
|
It's because the CSS referenced any 'system fonts of the Reading System, whether new or old, that's why I didn't embed any specific fonts in the ePub.
If you try to change the fonts that are available in the reading system, you won't notice any significant change in the appearance of the content, except these list markers.
Quote:
Originally Posted by MicroDrie
Third, the CSS before content definition contains a graphic character without referencing a specific font.
|
Those graphical characters are all taken from the HTML entity charts, except maybe one or two are not HTML entities.
Quote:
Originally Posted by MicroDrie
The question is which font is now active when the EPUB reader starts rendering a page? The answer to this is: Where the emperor is not there, he loses his rights. The EPUB reader then checks whether an alternative font has been mentioned that the EPUB reader is familiar with. The more exotic the font is, the greater the chance that an EPUB reader will not have that font on board. Then the EPUB reader should fall back error-free to a font that is present.
|
The many fonts that you've seen at the end of the CSS are just to remedy all these possible scenarios. Granted that reader may open the ePub in a very old reader with outdated SDK but the ePub will still look acceptable.
Quote:
Originally Posted by MicroDrie
Then there's the next problem, what if the fallback font doesn't have the graphic character? He can then display a graphic block as an error character indicator, but how does the rendering proceed? It is very difficult to create a one-fit-all error handling routine. That graphical character does occupy one position on the screen, but in the code it can be several positions. There is a good chance that the result will look very different from the expected layout because rendering is out of sync with the CSS code.
|
Rendering is not an issue here, I've tested every way possible to display the ePub. But of course, there's always will be a slight difference in the performance and rendering of the characters.
Quote:
Originally Posted by MicroDrie
I think different roles in an emergency each require graphical markup for that specific role. I've added and modified the awesome font to be able to use it in an EPUB. In page 1U3 I could replace all formatting code with a character of font-awesome. But font-awesome doesn't have a dot in a square used on it. Before we get to that, I'm very curious if page 1U3 still misrepresents the contents of "Unfälle: Giftstich" in the attached EPUB to see if we're on the right track to solve the issue.
|
At the very earliest stage of formatting this book, I've used the font-awesome as the way to integrate these graphical markers, but they failed miserably. In the end, only these graphical markers that are currently in the ePub works.
I'm attaching few screenshots of the font awesome result, as well as other reading apps' results. The issue in discussion is only specific to GPB, other reading systems don't create this issue.
Font Awesome in GPB
Infinity Reader for Android - Original ePub - with system fonts
Lithium Reader for Android - Original ePub - with system fonts
And iBooks