Indesign to fixed layout epub very slow

JohannesM · 01-30-2018, 05:57 AM

Hello

I have a problem with a fixed layout epub that I've tried to solve for a long time to no avail, thought maybe asking for help here would be a good idea.

I'm converting a ~600-page maths textbook to fxl epub. I have the design in Indesign, interactions work and all displays very nicely. However there's a problem when opening the epub in any tablet reader (I have an older iPad 2 and a Lenovo pad for testing). Each page takes a few seconds to load on tablets.
The epub itself is very large - around 40MB, since all the formulas and math symbols are represented as png pictures and it's quite heavy on them.

I have two main suspects - both stemming from Indesign:

For positioning exactly as seen on Indesign editor, it gives each word and image an id with which to position the element - that makes the css file about 3MB large, 93k rows. I thought I might fix that by breaking up the css so each file would get a unique css file which would have only classes and id-s used in that file. Wrote the script for that and repacked the epub with separated css files but it didn't work - the loading times were still slow.
Another suspect is that for precise positioning Indesign enlarges the resolution - it gives everything 20x larger dimensions and then uses css transform to scale it 0.05 times back again. This might be another case where the reader has to think and calculate too much before displaying the page. Maybe there's a checkbox somewhere to tell it to not scale it all? I could try writing a script that would recalculate everything to normal size but maybe that's not even an issue, since Indesign makes it automatically - I don't think it's possible that it enforces a solution which would be unreadable.

Example page: https://pastebin.com/vGqVatD5
I'm using Indesign CC2017 and Sigil. Using Indesign is mandatory for this project, since it holds the design and re-doing the 600 page maths textbook and realigning all formulas etc. in some other program is just not worth the time. Sigil was for cleanup, it actually reduced the file size

Can anyone point me to some direction - I might not have thought about everything yet which might make the reading experience slow.

JSWolf · 01-30-2018, 05:23 PM

Here is one suggestion. Forget using PNG for your math formulas. You can try SVG. The link below is a site that lets you create math formulas and save them as SVG.

https://www.codecogs.com/latex/eqneditor.php

JohannesM · 01-31-2018, 12:27 AM

Thank you for the suggestion. The thing is, that the PNGs get created automatically by exporting from Indesign - I already have all of the formulas and special cases as *.eps files. It's a conversion of already existing printed textbook, which was originally designed in Indesign - there are around 8000 of them, so it doesn't seem too reasonable to replace them with svg-s manually.

Is there a significant performance boost by using svg instead of png? If I have to do it, I'd really rather know that it would help.

I guess another thing that could be done would be to re-do everything in Sigil, just design it in Indesign, now that I have all formatting design questions solved. But again, I'd really rather do it only if I know that I cannot use Indesign's exported epub somehow, this issue seems kind of silly.

JSWolf · 01-31-2018, 09:42 AM

There can be a significant increase in clarity with SVG. I have no idea if SVG will be faster or not. But, SVG scales much better to any resolution screen.

Turtle91 · 01-31-2018, 08:13 PM

Quote:

Originally Posted by JSWolf

There can be a significant increase in clarity with SVG. I have no idea if SVG will be faster or not. But, SVG scales much better to any resolution screen.

I thought the scalability aspect also applied to MathML...is that not true??

JSWolf · 02-01-2018, 06:44 AM

Quote:

Originally Posted by Turtle91

I thought the scalability aspect also applied to MathML...is that not true??

Yes, it is true. But what I am not sure of is can every ePub 3 renderer that can handle fixed layout handle MathML.

HarryT · 02-01-2018, 07:41 AM

Quote:

Originally Posted by JSWolf

Yes, it is true. But what I am not sure of is can every ePub 3 renderer that can handle fixed layout handle MathML.

Given that the OP is not using MathML, Jon, and presumably has no intention of re-writing his book to use it (a significant task, given that he states that there are 8000 equations in the book), it's rather a moot point which renderers do or don't support it. It's not an answer to the OP's problem.

KevinH · 02-01-2018, 10:33 AM

If your "chapter" xhtml files are large and hold many many images, consider splitting them into separate files for each section. Assuming numeric section numbering, having and using a separate file xhtml file for each major section within a chapter, should greatly speed loading on all devices.

HarryT · 02-01-2018, 10:38 AM

Quote:

Originally Posted by KevinH

If your "chapter" xhtml files are large and hold many many images, consider splitting them into separate files for each section. Assuming numeric section numbering, having and using a separate file xhtml file for each major section within a chapter, should greatly speed loading on all devices.

The basic problem is, I think, the 93,000-line CSS file. Loading and parsing that is going to slow down any book, no matter how many separate files it's split into. The OP needs to come up with a method of drastically reducing the size of the CSS, by which I mean "getting rid of 99% of it".

KevinH · 02-01-2018, 10:41 AM

I missed that! Wow 93,000 line CSS file would definitely kill loading times. Perhaps he could make a copy of the file for each xhtml file and then link it to just one xhtml file and then strip out any and all CSS rules that are not used in that particular xhtml file?

What on earth would need that many rules?

JSWolf · 02-01-2018, 10:50 AM

Remember, InDesign makes a rather sloppy CSS. I've seen this in many ID created ePub. And I would think with something this complex, it owuld make even more of a mess.

JohannesM · 02-01-2018, 01:36 PM

Thank you for your ideas so far.

I tried and researched a little bit more - splitting up the css surprisingly did not help. It seems it's the combination of both every element (and word) being absolutely positioned, scaling and css issues - I redid manually a few first pages in Sigil to take control over the source code and that one loads nicely and fast. Which is a real shame for Indesign.

I also looked into MathML, for performance and size issues would like to get rid of as much images and redundant css as possible - I guess there is no fast way of doing it. The fastest way to get nearly anything acceptable seems to be lots of regex and still get MathML going - most of the symbols are actually not that complicated, having {a over b} and later replacing them all with mathml syntax will indeed mean lot's of work but also finally a solution.

As for splitting up the "chapters" - if it's fixed layout, each page is a separate xhtml anyway, no?

KevinH · 02-01-2018, 02:40 PM

Yes, a page per file. That said, why does InDesign not simply position an entire text line or text box instead of positioning every single word?

JSWolf · 02-01-2018, 03:26 PM

With fixed layout, what happens if someone wants the text to be fairly large?

HarryT · 02-01-2018, 03:44 PM

Fixed layout means exactly that. It’s like a PDF: fixed content on a page. You can zoom in on it, but it doesn’t reflow.

01-30-2018, 05:57 AM	#1
JohannesM Junior Member Posts: 7 Karma: 100 Join Date: Jan 2018 Device: none	Indesign to fixed layout epub very slow Hello I have a problem with a fixed layout epub that I've tried to solve for a long time to no avail, thought maybe asking for help here would be a good idea. I'm converting a ~600-page maths textbook to fxl epub. I have the design in Indesign, interactions work and all displays very nicely. However there's a problem when opening the epub in any tablet reader (I have an older iPad 2 and a Lenovo pad for testing). Each page takes a few seconds to load on tablets. The epub itself is very large - around 40MB, since all the formulas and math symbols are represented as png pictures and it's quite heavy on them. I have two main suspects - both stemming from Indesign: For positioning exactly as seen on Indesign editor, it gives each word and image an id with which to position the element - that makes the css file about 3MB large, 93k rows. I thought I might fix that by breaking up the css so each file would get a unique css file which would have only classes and id-s used in that file. Wrote the script for that and repacked the epub with separated css files but it didn't work - the loading times were still slow. Another suspect is that for precise positioning Indesign enlarges the resolution - it gives everything 20x larger dimensions and then uses css transform to scale it 0.05 times back again. This might be another case where the reader has to think and calculate too much before displaying the page. Maybe there's a checkbox somewhere to tell it to not scale it all? I could try writing a script that would recalculate everything to normal size but maybe that's not even an issue, since Indesign makes it automatically - I don't think it's possible that it enforces a solution which would be unreadable. Example page: https://pastebin.com/vGqVatD5 I'm using Indesign CC2017 and Sigil. Using Indesign is mandatory for this project, since it holds the design and re-doing the 600 page maths textbook and realigning all formulas etc. in some other program is just not worth the time. Sigil was for cleanup, it actually reduced the file size Can anyone point me to some direction - I might not have thought about everything yet which might make the reading experience slow.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Adobe Indesign's Export to Fixed Layout Epub	verydeepwater	ePub	13	08-23-2014 03:06 AM
Creating Fixed Layout ePub3 from InDesign	flipick	ePub	12	03-14-2013 09:22 AM
Fixed layout epub	curiousgeorge	ePub	3	01-18-2013 04:27 PM
Images as fixed layout epub	Dillinquent	ePub	6	06-10-2011 02:22 PM
Fixed-layout epub	bhuvana786	ePub	2	04-07-2011 08:00 AM

01-30-2018, 05:23 PM	#2
JSWolf Resident Curmudgeon Posts: 73,845 Karma: 128597114 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	Here is one suggestion. Forget using PNG for your math formulas. You can try SVG. The link below is a site that lets you create math formulas and save them as SVG. https://www.codecogs.com/latex/eqneditor.php

01-31-2018, 12:27 AM	#3
JohannesM Junior Member Posts: 7 Karma: 100 Join Date: Jan 2018 Device: none	Thank you for the suggestion. The thing is, that the PNGs get created automatically by exporting from Indesign - I already have all of the formulas and special cases as .eps files. It's a conversion of already existing printed textbook, which was originally designed in Indesign - there are around 8000 of them, so it doesn't seem too reasonable to replace them with svg-s manually. Is there a significant performance boost by using svg instead of png? If I have to do it, I'd really rather know that it would help. I guess another thing that could be done would be to re-do everything* in Sigil, just design it in Indesign, now that I have all formatting design questions solved. But again, I'd really rather do it only if I know that I cannot use Indesign's exported epub somehow, this issue seems kind of silly.

01-31-2018, 09:42 AM	#4
JSWolf Resident Curmudgeon Posts: 73,845 Karma: 128597114 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	There can be a significant increase in clarity with SVG. I have no idea if SVG will be faster or not. But, SVG scales much better to any resolution screen.

02-01-2018, 10:33 AM	#8
KevinH Sigil Developer Posts: 7,604 Karma: 5433388 Join Date: Nov 2009 Device: many	If your "chapter" xhtml files are large and hold many many images, consider splitting them into separate files for each section. Assuming numeric section numbering, having and using a separate file xhtml file for each major section within a chapter, should greatly speed loading on all devices.

02-01-2018, 10:41 AM	#10
KevinH Sigil Developer Posts: 7,604 Karma: 5433388 Join Date: Nov 2009 Device: many	I missed that! Wow 93,000 line CSS file would definitely kill loading times. Perhaps he could make a copy of the file for each xhtml file and then link it to just one xhtml file and then strip out any and all CSS rules that are not used in that particular xhtml file? What on earth would need that many rules?

02-01-2018, 10:50 AM	#11
JSWolf Resident Curmudgeon Posts: 73,845 Karma: 128597114 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	Remember, InDesign makes a rather sloppy CSS. I've seen this in many ID created ePub. And I would think with something this complex, it owuld make even more of a mess.

02-01-2018, 01:36 PM	#12
JohannesM Junior Member Posts: 7 Karma: 100 Join Date: Jan 2018 Device: none	Thank you for your ideas so far. I tried and researched a little bit more - splitting up the css surprisingly did not help. It seems it's the combination of both every element (and word) being absolutely positioned, scaling and css issues - I redid manually a few first pages in Sigil to take control over the source code and that one loads nicely and fast. Which is a real shame for Indesign. I also looked into MathML, for performance and size issues would like to get rid of as much images and redundant css as possible - I guess there is no fast way of doing it. The fastest way to get nearly anything acceptable seems to be lots of regex and still get MathML going - most of the symbols are actually not that complicated, having {a over b} and later replacing them all with mathml syntax will indeed mean lot's of work but also finally a solution. As for splitting up the "chapters" - if it's fixed layout, each page is a separate xhtml anyway, no?

02-01-2018, 02:40 PM	#13
KevinH Sigil Developer Posts: 7,604 Karma: 5433388 Join Date: Nov 2009 Device: many	Yes, a page per file. That said, why does InDesign not simply position an entire text line or text box instead of positioning every single word?

02-01-2018, 03:26 PM	#14
JSWolf Resident Curmudgeon Posts: 73,845 Karma: 128597114 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	With fixed layout, what happens if someone wants the text to be fairly large?

02-01-2018, 03:44 PM	#15
HarryT eBook Enthusiast Posts: 85,544 Karma: 93383043 Join Date: Nov 2006 Location: UK Device: Kindle Oasis 2, iPad Pro 10.5", iPhone 6	Fixed layout means exactly that. It’s like a PDF: fixed content on a page. You can zoom in on it, but it doesn’t reflow.

Advert

Advert