Google Play Books and Nested Lists - Some Weird Display Issue

[rsuchwani]

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.

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.

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.

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.

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

Spoiler:

Infinity Reader for Android - Original ePub - with system fonts

Spoiler:

Lithium Reader for Android - Original ePub - with system fonts

Spoiler:

And iBooks

Spoiler:

[JSWolf]

Originally Posted by rsuchwani

The font size does change when the text size is adjusted according to the preference of the readers. What you've seen at the start of the CSS is the 'absolute reference font size'.

And the CSS is the very practical one. Granted that there are many things that usually don't get used often, but given the complexity of the book, it is an absolute requirement.

That CSS is not practical. It's a disaster. You did not follow the mos important rule of make eBooks. That rule is to keep it simple. That means as simple coding as possible and no extra unused classes in the CSS and/or HTML. Your CSS is a mess and you really should fix it.

As for the text size, in ADE 2.0.1, I cannot change the size of the text. That means there are probably other programs out there that cannot do the same. I don't know if later versions of RMSDK/ADE will allow the text size to be changed.

As for your special symbols, you really should embed a font just to make sure those symbols display correctly. You never ever reference specific fonts without them being embedded.

[rsuchwani]

Originally Posted by JSWolf

That CSS is not practical. It's a disaster. You did not follow the mos important rule of make eBooks. That rule is to keep it simple. That means as simple coding as possible and no extra unused classes in the CSS and/or HTML. Your CSS is a mess and you really should fix it.

CSS needs to be simple when the eBook is simple (fiction, targeted for a single platform, one to two styles, etc) and doesn't require special handling, but when the content (like the one I have for this non-fiction book) needs to have many specific styles and display formats, targeted for multiple platforms, then the CSS needs to be this 'messy'. The assumption that you are making here is based only on the few pages of text in the sample ePub, whereas in reality the complete is a little bit over 400 individual pages with varying styles, colors, display options.

But, I'm not going to argue over a valid point, because yes, you do make a valid point. There are classes that aren't used and in the final version of the ePub, they'll be removed.

Originally Posted by JSWolf

As for the text size, in ADE 2.0.1, I cannot change the size of the text. That means there are probably other programs out there that cannot do the same. I don't know if later versions of RMSDK/ADE will allow the text size to be changed.

Yes, it was intentional. It was some sort of example to the author to explain the difference between zooming and increasing/decreasing the font size across multiple reading systems. But even using the 'fixed reference font size' many reading systems still allow to increase/decrease the font size.

Originally Posted by JSWolf

As for your special symbols, you really should embed a font just to make sure those symbols display correctly. You never ever reference specific fonts without them being embedded.

I didn't want to depend on the use of the fonts for the symbols, that's why I used the 'HTML entity codes/symbols or Unicode characters' which are supported almost on all reading systems. Only one or two symbols aren't supported across all.

Besides that, I don't think that there's any font file that has all these Unicode characters as a font. If you know such font, I'll be glad to have it.

Reminder note, all the contents, text, symbols, everything, displaying correctly, GPB displays 'empty list markers' on each following page/screen of the content of the nested lists. If you have advice/suggestions specific to this issue then I'll gladly hear it.

Thanks for taking out time to respond to my queries.

[MicroDrie]

I've read all your posts again for your questions and comments:

Originally Posted by rsuchwani

Notice the 'orphan hanging' arrow at the beginning of the page and the list item? It's like that with every 'nested list' in the book.

Graphical display behavior when the rest of a list on the next page is displayed at the correct indent position

Originally Posted by rsuchwani

Thing is, the Play Books display some 'orphan' or 'empty' list markers across pages. All these markers are of 'nested lists'.

You define with a content class with content before, while the page break uses the default graphical list character.

Originally Posted by rsuchwani

But my question is not regarding the alignment or how to display them, my issue is specific to GP's display habit here. It's weird that all the list markers (from level 1 to whichever level's list on the next page) are displaying (without the list content). See the original issue screenshots.

It looks like this action:

Originally Posted by rsuchwani

The font size does change when the text size is adjusted according to the preference of the readers.

The remaining text conflicts with a fixed page layout, resulting in text being lost.

Furthermore, my GitDen EPUB reader is not very happy with this EPUB file.

I think a phased approach is needed in which one always solves a problem first and then solves the next problem in the next step.

[JSWolf]

Originally Posted by rsuchwani

CSS needs to be simple when the eBook is simple (fiction, targeted for a single platform, one to two styles, etc) and doesn't require special handling, but when the content (like the one I have for this non-fiction book) needs to have many specific styles and display formats, targeted for multiple platforms, then the CSS needs to be this 'messy'. The assumption that you are making here is based only on the few pages of text in the sample ePub, whereas in reality the complete is a little bit over 400 individual pages with varying styles, colors, display options.

But, I'm not going to argue over a valid point, because yes, you do make a valid point. There are classes that aren't used and in the final version of the ePub, they'll be removed.

Keeping it as simple as possible is always best. Never reference specific fonts that aren't embedded. Also, you should test this on as many eInk Readers as you can given that they use different reading software. Also to know if the colors need to go or not.

Yes, it was intentional. It was some sort of example to the author to explain the difference between zooming and increasing/decreasing the font size across multiple reading systems. But even using the 'fixed reference font size' many reading systems still allow to increase/decrease the font size.

The font size restriction needs to go and you need to test with different font sizes from too small to too large.

I didn't want to depend on the use of the fonts for the symbols, that's why I used the 'HTML entity codes/symbols or Unicode characters' which are supported almost on all reading systems. Only one or two symbols aren't supported across all.

Besides that, I don't think that there's any font file that has all these Unicode characters as a font. If you know such font, I'll be glad to have it.[/quote]

So you'd rather rely on an unknown font and hope that your symbols will show up. That's very poor planning. Just embed a font. You can subset it and leave just the symbols.

Just embed all the fonts you need that have these symbols and subset them. That will reduce the size greatly and give you the symbols you need. Also given that you say there may not be a font with all the symbols, then chances are no reading system's default font will do and that will botch your book's appearance.

[rsuchwani]

Originally Posted by MicroDrie

Graphical display behavior when the rest of a list on the next page is displayed at the correct indent position

Yes, indention is precise and doesn't look to be broken in GPB even when there're orphan list markers above.

Originally Posted by MicroDrie

You define with a content class with content before, while the page break uses the default graphical list character.

It seems that the reader's default action isn't over-ridden. What's your suggestion then?

Originally Posted by MicroDrie

The remaining text conflicts with a fixed page layout, resulting in text being lost.

I think that this is the normal behavior while increasing the font size, isn't it? And the small screen size devices tend to have this issue, aren't they? And if you are referring to an entirely different thing, then please forgive me, you lost me here.

Originally Posted by MicroDrie

Furthermore, my GitDen EPUB reader is not very happy with this EPUB file.

I previewed the ePub in this reader just now, and yes, there are display issues especially where the lists are. List markers' indention is off.

Originally Posted by MicroDrie

I think a phased approach is needed in which one always solves a problem first and then solves the next problem in the next step.

What are your suggestions?

[rsuchwani]

Originally Posted by JSWolf

Keeping it as simple as possible is always best. Never reference specific fonts that aren't embedded. Also, you should test this on as many eInk Readers as you can given that they use different reading software. Also to know if the colors need to go or not.

You are right, as I mentioned that the final ePub will have a much simpler CSS and the entire code. There aren't many colors in the ePub, just a few significant ones.

Originally Posted by JSWolf

The font size restriction needs to go and you need to test with different font sizes from too small to too large.

Done.

Originally Posted by JSWolf

So you'd rather rely on an unknown font and hope that your symbols will show up. That's very poor planning. Just embed a font. You can subset it and leave just the symbols.

Just embed all the fonts you need that have these symbols and subset them. That will reduce the size greatly and give you the symbols you need. Also given that you say there may not be a font with all the symbols, then chances are no reading system's default font will do and that will botch your book's appearance.

On point, will do that.

I'll try to follow the above given suggestion and see that it resolves the current issues or not.

[DNSB]

Originally Posted by rsuchwani

I didn't want to depend on the use of the fonts for the symbols, that's why I used the 'HTML entity codes/symbols or Unicode characters' which are supported almost on all reading systems. Only one or two symbols aren't supported across all.

Besides that, I don't think that there's any font file that has all these Unicode characters as a font. If you know such font, I'll be glad to have it.

Depending on your reading device, if no available font has the glyph for that symbol, it will not be displayable and you will see the something such as a narrow rectangle, a rectangle with a ? or a box with the hex representation of the character.

You might try Code2000 as a font though it's pretty fugly IMHO.

[rsuchwani]

Originally Posted by JSWolf

Just embed all the fonts you need that have these symbols and subset them. That will reduce the size greatly and give you the symbols you need. Also given that you say there may not be a font with all the symbols, then chances are no reading system's default font will do and that will botch your book's appearance.

So I've found that the font 'Arial' has the maximum number of symbols (or geometrical shapes) that's needed in the book, I've subset and embed the font in the ePub, but that didn't resolve the issue. I've also clear the CSS and removed all the unused selectors in this sample ePub.

Screenshots

Spoiler:

EPUB

[rsuchwani]

Originally Posted by DNSB

Depending on your reading device, if no available font has the glyph for that symbol, it will not be displayable and you will see the something such as a narrow rectangle, a rectangle with a ? or a box with the hex representation of the character.

You might try Code2000 as a font though it's pretty fugly IMHO.

David,

The Glyphs displays fine because I've used the Unicode characters as the list markers, very few 'fonts' don't display them. Even I remedied it by subsetting the font (that has almost all the used glyphs) and embedding it in the ePub, but that didn't resolve my issue. Please observe the attached Test ePub V03 above.

Thanks.

[Hitch]

Originally Posted by rsuchwani

So I've found that the font 'Arial' has the maximum number of symbols (or geometrical shapes) that's needed in the book, I've subset and embed the font in the ePub, but that didn't resolve the issue. I've also clear the CSS and removed all the unused selectors in this sample ePub.

Screenshots

Spoiler:

EPUB

Not to be thick as a brick, but what happens when the customer changes the font face?

Hitch

[MicroDrie]

Originally Posted by rsuchwani

So I've found that the font 'Arial' has the maximum number of symbols (or geometrical shapes) that's needed in the book, I've subset and embed the font in the ePub, but that didn't resolve the issue. I've also clear the CSS and removed all the unused selectors in this sample ePub.

Screenshots

Spoiler:

EPUB

I see you have an Ibook. Apple uses a fixed page layout, while Android uses a re-flowable layout. A fixed page layout and the freedom to make the font larger or smaller conflict with this. This is not to say that this contradiction is never solvable, but you will really have to make this choice first.

I have little experience with Apple equipment. If your choice really is a fixed page layout and zoomable font size, the question is, is there an example where that has been applied in an EPUB?

And if there is, then the question arises as to what you can do about the list display? Does it fit or not fit the chosen solution?

A zoomable font obviously seems very user-friendly. But (wrong question of mine of course) isn't that actually a solution for the wrong choice of the default font size?

I see you have an Ibook. Apple uses a fixed page layout, while Android uses a rearrangeable layout. A fixed page layout and the freedom to make the font larger or smaller has a major impact on the display. Because a larger font gives a smaller number of characters on the fixed page layout. That is not to say that this contradiction can never be resolved, but you will really have to make this choice first. The EPUB reader you are using conveniently just throws away the mismatched text.

I have little experience with Apple equipment. If you really go for a fixed page layout and zoomable font size, the question is, is there an example where that has been applied in an EPUB?

And if so, then the question arises what can you do about the list view? Does it fit or not match the chosen solution?

Of course, a zoomable font seems very user-friendly. But (wrong question on my part of course) isn't that actually a solution to the wrong choice of the default font size? At a time when everyone carries a smart phone in their pocket, I personally don't understand why people prefer lowercase letters on a fixed page layout suitable for a PC.

Look, if your target group for the book is a doctor at the desk, I understand that, but an assistant with a smart phone in the field and a font that is too small, I don't think that's smart. My smart choice would be a fix readable font on the smart phone. That saves a lot of hassle with zooming (and rendering) in the field.

It is fair to say that in that case the text is spread over more pages. Personally, I don't understand the fixation on making a digital copy of a fixed book layout. A book is nice to read all the way through, but to first read your entire fire insurance policy and then find the number of the fire brigade is not very effective.

Because why don't you use, for example, an accordion? This allows you to skip non-specific information and thus reach relevant information faster. A specific rescuer role can then quickly select its specific role information without the need for hemming. That's what I call smart use of a smartphone. Ok, exactly the same information, but a completely different approach route.

By thinking carefully about each specific goal and delineating the necessary resources (= information) for this specific purpose, I wouldn't be surprised if a care provider gets to his or her specific information in fewer steps.

[Doitsu]

Originally Posted by MicroDrie

I see you have an Ibook. Apple uses a fixed page layout, while Android uses a re-flowable layout [...]
I have little experience with Apple equipment.

You're mistaken. Apple Books (iBooks) supports both reflowable books and fixed-layout books.
Moreover, the OP stated that he encountered problems with Google Play Books.

[rsuchwani]

Originally Posted by Hitch

Not to be thick as a brick, but what happens when the customer changes the font face?

Hitch

Font increasing/decreasing and font face change works as they should. All the glyphs appear (just a little bit different). But the issue remains.

See the below attachment

Spoiler:

https://drive.google.com/file/d/18AL...yNy819ifk/view

[rsuchwani]

Originally Posted by MicroDrie

I see you have an Ibook. Apple uses a fixed page layout, while Android uses a re-flowable layout. A fixed page layout and the freedom to make the font larger or smaller conflict with this. This is not to say that this contradiction is never solvable, but you will really have to make this choice first.

How did you come up with this reasoning? And when did I ever say that my book is FXL and only for iBooks? The ePub (samples attached in my previous posts) is in reflowable format and can be read on any number of devices/reading systems.

Originally Posted by MicroDrie

I have little experience with Apple equipment. If your choice really is a fixed page layout and zoomable font size, the question is, is there an example where that has been applied in an EPUB?

And if there is, then the question arises as to what you can do about the list display? Does it fit or not fit the chosen solution?

A zoomable font obviously seems very user-friendly. But (wrong question of mine of course) isn't that actually a solution for the wrong choice of the default font size?

I see you have an Ibook. Apple uses a fixed page layout, while Android uses a rearrangeable layout. A fixed page layout and the freedom to make the font larger or smaller has a major impact on the display. Because a larger font gives a smaller number of characters on the fixed page layout. That is not to say that this contradiction can never be resolved, but you will really have to make this choice first. The EPUB reader you are using conveniently just throws away the mismatched text.

I have little experience with Apple equipment. If you really go for a fixed page layout and zoomable font size, the question is, is there an example where that has been applied in an EPUB?

And if so, then the question arises what can you do about the list view? Does it fit or not match the chosen solution?

Of course, a zoomable font seems very user-friendly. But (wrong question on my part of course) isn't that actually a solution to the wrong choice of the default font size? At a time when everyone carries a smart phone in their pocket, I personally don't understand why people prefer lowercase letters on a fixed page layout suitable for a PC.

Look, if your target group for the book is a doctor at the desk, I understand that, but an assistant with a smart phone in the field and a font that is too small, I don't think that's smart. My smart choice would be a fix readable font on the smart phone. That saves a lot of hassle with zooming (and rendering) in the field.

It is fair to say that in that case the text is spread over more pages. Personally, I don't understand the fixation on making a digital copy of a fixed book layout. A book is nice to read all the way through, but to first read your entire fire insurance policy and then find the number of the fire brigade is not very effective.

Because why don't you use, for example, an accordion? This allows you to skip non-specific information and thus reach relevant information faster. A specific rescuer role can then quickly select its specific role information without the need for hemming. That's what I call smart use of a smartphone. Ok, exactly the same information, but a completely different approach route.

By thinking carefully about each specific goal and delineating the necessary resources (= information) for this specific purpose, I wouldn't be surprised if a care provider gets to his or her specific information in fewer steps.

Apologies, but I didn't go through your rest of the comments/advice/suggestions well because it's out of the topic.

Thanks for taking your time out and responding to my thread.