Code bloat. What is it? - Page 3

JSWolf · 02-07-2024, 02:29 PM

Quote:

Originally Posted by paperwhite13

That’s exactly what some IDs are for -- to correlate physical book numbering with the ebook. Building a pagelist is a basic requirement for accessibility.

How are pagelists a basic requirement for accessibility?

JSWolf · 02-07-2024, 03:06 PM

Quote:

Originally Posted by KevinH

@nabsltd,

That approach would miss or break ids used by the epub2 toc.ncx which use <content src="blah#fragment">, and of course break the opf guide urls if they used fragments, and any ncx pagelists or adobe pagmap.xml use of fragments.

Not to mention epub3 external cfi urls that use fragments, external bookmarks that use fragments, javascript uses to dentify nodes in the dom, etc.

When I remove IDs, I make sure that they are either not used or at the top of the HTML and only used in the ToC. Then I can remove them from the HTML and the ToC (if they are in the ToC).

DNSB · 02-07-2024, 03:11 PM

Quote:

Originally Posted by JSWolf

How are pagelists a basic requirement for accessibility?

One acquaintance of mine has a child who is legally blind and attending university. For them, pagelists allows them to locate a page referred to by a professor from the printed text without needing assistance. The type of thing where the profs say 'read pages 249-283 and do the quiz on pages 284-285' before the next class.

For more information see: Accessible Publishing Knowledge Base: Page Navigation as to why pagelists are considered part of accessibility.

JSWolf · 02-07-2024, 03:12 PM

Quote:

Originally Posted by DNSB

Are those the same Sony readers that crapped out if the file size was over 250KB?

I did a quick test with a epub that has multiple subchapters within it's mass of chapters using a Kobo Sage. To the naked eyeball, going from the ToC to chapter 103 did not take any more time than going from the ToC to a subchapter in chapter 103. The chapter 103 link is to the xhtml file, the subchapters links are to an id. Using my iPhone to record the process, both took the same number of frames at 30fps from when the link went dark to when the text was displayed (averaged over 5 tests of chapter and subchapter) so any differences in timing were less than 30ms.

Doing this test did reinforce my wish that you could collapse the ToC.

Back then, the Sony had a slower processor and had less RAM then the current Kobo Readers. The thing is, it's not causing any issue removing these IDs. It's done out of habit because I was doing it when it did make a noticeable difference.

JSWolf · 02-07-2024, 03:18 PM

Quote:

Originally Posted by DNSB

Jon, you really should quit trying to force your preferences on other people.

Edit: As for complaining about the stylesheet in Random in Death, like most stylesheets in ebooks published by major publishers, that stylesheet is used for many different books so unused stylesheet entries are to be expected. Much like in the Vellum stylesheets that you love grumbling about.

If I leave out text-align: justify, the default is to lift align. I've not tried using the alignment in Aa for full justification, but when using left, we know centered text is no longer centered. I don't know about right aligned text. But if I put the alignment in body, it works and the alignment in Aa also works (as well as it works). I don't want to have to set full alignment for every eBook in Aa. Most eBooks use justify in multiple CSS entries.

All I was saying is that putting the alignment in <body> works.

JSWolf · 02-07-2024, 03:22 PM

Quote:

Originally Posted by DNSB

One acquaintance of mine has a child who is legally blind and attending university. For them, pagelists allows them to locate a page referred to by a professor from the printed text without needing assistance. The type of thing where the profs say 'read pages 249-283 and do the quiz on pages 284-285' before the next class.

For more information see: Accessible Publishing Knowledge Base: Page Navigation as to why pagelists are considered part of accessibility.

What happens if the eBook does not have a pagelist?

For the new EU rules on accessibility, would a pagelist have to be made for every eBook no matter the type of eBook (be it fiction, non-fiction, textbook)?

DNSB · 02-07-2024, 03:24 PM

Quote:

Originally Posted by JSWolf

Back then, the Sony had a slower processor and had less RAM then the current Kobo Readers. The thing is, it's not causing any issue removing these IDs. It's done out of habit because I was doing it when it did make a noticeable difference.

I suspect that many people don't care whether you remove IDs, pagelists, etc. to save a few bytes. It is your insistence that this is the ONE TRUE WAY that most people don't care for.

For most people, trying to save every possible byte is no longer needed. It's not like when I was programming building controls with an 8-bit processor with 4K of RAM and 8K of ROM and I used every byte saving trick to cram everything into that 8KB ROM. Though in many ways, programming microprocessors back then was a lot more fun. Flashback to Byte magazine and "Computers, the world's greatest toys".

Turtle91 · 02-07-2024, 03:51 PM

Quote:

Originally Posted by JSWolf

If I leave out text-align: justify, the default is to lift align. I've not tried using the alignment in Aa for full justification, but when using left, we know centered text is no longer centered….

I’m not sure where you got that idea from??

I do NOT set anything in the body except basic margins/padding. I set text-align:left on the base <p> because I prefer left-aligned text. I have no problem with any of the text that I designate as center-aligned, or fully justified, displaying properly.

JSWolf · 02-07-2024, 04:00 PM

If you convert from KF8 to ePub using KindleUnpack, you will need to edit the ePub as there are some errors. I don't know if these errors would cause a problem or not as I always fix them.

JSWolf · 02-07-2024, 04:25 PM

Quote:

Originally Posted by Turtle91

I’m not sure where you got that idea from??

I do NOT set anything in the body except basic margins/padding. I set text-align:left on the base <p> because I prefer left-aligned text. I have no problem with any of the text that I designate as center-aligned, or fully justified, displaying properly.

You missed the point. If you use the left justify from the Aa menu on a Kobo, it causes center to no longer be center. Given that it works, I'm hoping it works on other programs that have an alignment override.

DNSB · 02-07-2024, 04:33 PM

Quote:

Originally Posted by JSWolf

What happens if the eBook does not have a pagelist?

Oddly, all their textbooks in epub format have pagelists. If not, they would have to request help from a classmate or ?.

Quote:

Originally Posted by JSWolf

For the new EU rules on accessibility, would a pagelist have to be made for every eBook no matter the type of eBook (be it fiction, non-fiction, textbook)?

I'm already noticed that most ebooks from major publishers have pagelists and the only change I make is to make sure the pagelist is hidden. Since a pagelist requires a physical edition which must be identified by it's ISBN in the .opf file, you will not find pagelists in ebook only versions.

Since you already referenced Random in Death, can we assume that you noticed that it had a pagelist section in the navigation document and in the .ncx document?

Turtle91 · 02-07-2024, 07:45 PM

Quote:

Originally Posted by JSWolf

You missed the point. If you use the left justify from the Aa menu on a Kobo, it causes center to no longer be center. Given that it works, I'm hoping it works on other programs that have an alignment override.

Ahhh, ok...It's a bug in Kobo that you use the work-around of putting text-align in the body to fix.

Has this been brought up with Kobo so they can work on a fix??

Turtle91 · 02-07-2024, 08:22 PM

Here is an example of what I would call code bloat:

Code:

<p style="margin:0.00% 0.00%; text-indent:1.2em; line-height:110%; widows:0; orphans:0;
          font-size:1.0rem"> <span style=" font-size:1.0rem">We weren’t.</span> </p>
<p style="margin:0.00% 0.00%; text-indent:1.2em; line-height:110%; widows:0; orphans:0;
          font-size:1.0rem"> <span style=" font-size:1.0rem">We’d planned the general
          strategy weeks ago, and confirmed it days before.</span> </p>

Excerpted from On the Shoulders of Titans by Andrew Rowe, Published in 2018. I added line-breaks so you could easily see it here.

Inline styling makes me shudder anyway, but the fact that the same styling is put on EVERY FREAKING LINE... that is totally unnecessary...and bloats the code. The same goes for putting a span, with inline styling, around every paragraph simply to tell it to use the standard font size.... which it already told it in the first set of styling!

Here is what I would reduce it to:

Code:

CSS:
p {margin:0.00% 0.00%; text-indent:1.2em; line-height:110%; widows:0; orphans:0;
   font-size:1.0rem}

HTML:
<p>We weren’t.</p>
<p>We’d planned the general strategy weeks ago, and confirmed it days before.</p>

Yes Jon, we know you don't like that styling and would change it. The point here is that it doesn't change the author's/publisher's styling at all...it just reduces code bloat.

Which is easier to read? If you needed to edit the way all your paragraphs looked you would need to change every single paragraph the way it currently stands. Reducing the code bloat and using css, as in the second example, I only need to make the change in one place and it updates the whole book.

I don't really expect the code bloat to change the file size all that much...certainly not as much as fixing the images/fonts...although I have reduced massive books by a couple of megabytes. I would rather not put ANY renderer, no matter how capable, through the constant headache of crunching through all that bloat just to determine what and how it should be displayed... my phone seems to stay cooler and the battery lasts longer. (That's my story and I'm sticking to it!

)

Cleaning up the unused css styles is automagically done for me when I use the Sigil plugin cssRemoveUnusedSelectors, so I don't spend too much time and energy cleaning up that "bloat".

RbnJrg · 02-08-2024, 12:16 AM

Ok

Quote:

Originally Posted by KevinH

Just for the record, if I am developing an epub for someone (ie. have complete control of the design and layout that has not been made publicly available yet) then I do follow the KISS principle advocated by JSWolf, and do not in general add complexities that may not be well supported by any number of older epub e-readers out there. Of course Accessibility must still be thought about and supported as fully as possible.

I just do not modify other people epub designs and layout without very good reason.

With all respect, I disagree. The KISS rule is deprecated, maximun if we have the complete control of the layout and design. The modern epub must be a perfect epub3 ebook, with all the epub3 features, plus a perfect epub2 inside (epub2 ereaders can open epub3 ebooks and you know that more than anyone Kevin). Of that way, if the ereader (the device) supports the epub3 protocols, then the human reader will have the best reading experience; on the other hand, if the device is an old one, then the epub2 code will take place. The KISS rule is an old rule (of course, we have to work more but results are optimal).

And there is a big notice; the epub2 protocol is next to be deprecated. Why? Because KOBO have added practically full epub3 supports to its reades (in my tests, the only thing seems not to be implemented yet are popup footnotes/endnotes and there are issues with MathML). Anyone can test that with the Kobo readers for Android and iOS. I don't know if all eink models of Kobo have been uptades with the last version of the rendering engine but what I saw in android and ios is amazing! To read, for example, "Alice in Wonderland" (illustrated version) with epub3 code, compared with an epub2 version, is like to compare a Ferrari with a bike.

paperwhite13 · 02-08-2024, 01:35 AM

Quote:

Originally Posted by JSWolf

What happens if the eBook does not have a pagelist?

For the new EU rules on accessibility, would a pagelist have to be made for every eBook no matter the type of eBook (be it fiction, non-fiction, textbook)?

Nothing happens, that ebook is safe and sound on your ereader. Because now probably only your modified ebooks have broken pagelists, it's already best practice. What will happen in the future is probably that more ebooks will adopt the more "bloated" <span aria-label=" Page 145. " epub:type="pagebreak" id="pg_145" role="doc-pagebreak"/> technique, like Random in Death correctly uses, instead of the non-recommended <a id="page145"/> technique (which I also used).

02-07-2024, 08:22 PM	#43
Turtle91 A Hairy Wizard Posts: 3,095 Karma: 18727053 Join Date: Dec 2012 Location: Charleston, SC today Device: iPhone 11/X/6/iPad 1,2,Air & Air Pro/Surface Pro/Kindle PW & Fire	Here is an example of what I would call code bloat: Code: <p style="margin:0.00% 0.00%; text-indent:1.2em; line-height:110%; widows:0; orphans:0; font-size:1.0rem"> <span style=" font-size:1.0rem">We weren’t.</span> </p> <p style="margin:0.00% 0.00%; text-indent:1.2em; line-height:110%; widows:0; orphans:0; font-size:1.0rem"> <span style=" font-size:1.0rem">We’d planned the general strategy weeks ago, and confirmed it days before.</span> </p> Excerpted from On the Shoulders of Titans by Andrew Rowe, Published in 2018. I added line-breaks so you could easily see it here. Inline styling makes me shudder anyway, but the fact that the same styling is put on EVERY FREAKING LINE... that is totally unnecessary...and bloats the code. The same goes for putting a span, with inline styling, around every paragraph simply to tell it to use the standard font size.... which it already told it in the first set of styling! Here is what I would reduce it to: Code: CSS: p {margin:0.00% 0.00%; text-indent:1.2em; line-height:110%; widows:0; orphans:0; font-size:1.0rem} HTML: <p>We weren’t.</p> <p>We’d planned the general strategy weeks ago, and confirmed it days before.</p> Yes Jon, we know you don't like that styling and would change it. The point here is that it doesn't change the author's/publisher's styling at all...it just reduces code bloat. Which is easier to read? If you needed to edit the way all your paragraphs looked you would need to change every single paragraph the way it currently stands. Reducing the code bloat and using css, as in the second example, I only need to make the change in one place and it updates the whole book. I don't really expect the code bloat to change the file size all that much...certainly not as much as fixing the images/fonts...although I have reduced massive books by a couple of megabytes. I would rather not put ANY renderer, no matter how capable, through the constant headache of crunching through all that bloat just to determine what and how it should be displayed... my phone seems to stay cooler and the battery lasts longer. (That's my story and I'm sticking to it! ) Cleaning up the unused css styles is automagically done for me when I use the Sigil plugin cssRemoveUnusedSelectors, so I don't spend too much time and energy cleaning up that "bloat".

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Nook S2 vs regular S2--bloat vs bucks??	friedrice	Which one should I buy?	5	05-05-2016 11:54 AM
After I Edit Code, Save, and Convert, all my Code Edits are Gone	lukewrussell	Calibre	1	03-14-2014 08:05 PM
Some code help	Gray Eminence	Sigil	3	12-31-2010 09:18 AM
code help	AWOL	Sigil	7	11-19-2010 11:50 AM
Let's create a source code repository for DR 800 related code?	jraf	iRex	3	03-11-2010 12:26 PM

02-07-2024, 04:00 PM	#39
JSWolf Resident Curmudgeon Posts: 74,015 Karma: 129333114 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	If you convert from KF8 to ePub using KindleUnpack, you will need to edit the ePub as there are some errors. I don't know if these errors would cause a problem or not as I always fix them.

Advert

Advert