These epubs make my PRS650 very slow

[KenJackson]

I was delighted to find that Red Hat Linux has it's documentation available in epub format. I downloaded several to my PRS650. They look good, but they're awful to read.

For one thing, regardless of what font size I choose from XS to XXL, the text is always displayed in the same tiny size.

Sometimes it takes over 10 seconds to change pages. I thought maybe the reader had developed a problem until I went back to different books and confirmed there was no problem with other books. The time to changes pages is sporadic, so I'm not certain if I'm imagining it, but it seems like the pages change slightly faster when I have text size S selected, even though they look identical to other sizes.

The table of contents is missing or blank on my reader, though it's quite visible and useful on the HTML version on the site.

Finally, it seems like the battery indicator dropped faster than it had been, so I wonder if the reader is wrestling with this document so much that it's using more power.

One specific document I was looking at is the Virtualization Guide.

Has anyone experienced anything similar?

[SkyDream]

I'm going to verify on my 650 once i'm back from brunch.
Basically i had no problems with ePub but will check the RedHat books.

[DoctorOhh]

Originally Posted by KenJackson

One specific document I was looking at is the Virtualization Guide.

I tried this in 505. The original untouched version locked up my reader. I tried to open it in Sigil (epub editing software) to take a look at it and Sigil threw up an error and ran an hid.

I did get to look at it in Calibre's epub viewer and it looked fine and the fonts adjusted fine. I can even verify it has a nice TOC.

Originally Posted by KenJackson

The table of contents is missing or blank on my reader, though it's quite visible and useful on the HTML version on the site.

The HTML TOC is inline the TOC for epub is in the menu. You should have a Table of Contents button on your screen under the book menu. This is where you will find the TOC.

I took the liberty of converting it from epub to epub using calibre. The resultant epub was half the size. The converted epub also was easy to navigate on my PRS-505 and the font size changed without any problem.

I would suggest doing a epub to epub conversions (no options checked). Then use the converted file to read on your 650 and see how that works.

[SkyDream]

Originally Posted by SkyDream

I'm going to verify on my 650 once i'm back from brunch.
Basically i had no problems with ePub but will check the RedHat books.

I've loaded the original Virtualization ePub and the calibre epub-to-epub converted one onto a sd-card.

The original one opened within 15 seconds, page turn 10-15 seconds. That's really slow. Changing the font size is ignored; still the same size.

The calibre converted one opened within 2 seconds, each page turn ~1 seconds. Jumped to page 100 ~1 sec,page turns ~1sec. That's what i know from my other books. Changing the font size works fine. While M is too big S seems to be best for me.

It seems that the Red Hat ePub books had some problems. Better convert them using calibre before using them.

[elemenoP]

I have a question about epub to epub conversion in Calibre, because I'm hoping it might help some problems I'm having. After I do an epub to epub conversion, the FORMATS on the right side still just says "EPUB." Shouldn't it say EPUB [1], EPUB [2] or something like that? How do I know if I'm opening the original or the new?

eP

[SkyDream]

After ePub to ePub conversion there's only one ePub left.
So there's nothing to choose from.

[KenJackson]

Originally Posted by dwanthny

I took the liberty of converting it from epub to epub using calibre. The resultant epub was half the size. The converted epub also was easy to navigate on my PRS-505 and the font size changed without any problem.

Thank you dwanthny! What a world of difference.
I don't think I would have thought of a like-to-like conversion to solve the problem

I find it convenient to use the command-line, so I did this. The ebook-convert command is part of calibre. INPUT.epub and OUTPUT.epub stand for the long original name and my selected output name. Option --no-default-epub-cover avoids adding the picture of a book on the front (I wish this were the default). The result was barely more than a third the original size and works great.

ebook-convert INPUT.epub OUTPUT.epub --no-default-epub-cover

The command spews out diagnostics and it's progress to the terminal as it goes. There were twelve of these errors. Maybe this was the problem.

CSS import of missing file u'OEBPS/Common_Content/css/common.css'
CSSImportRule: While processing imported style sheet href=u'common.css': IOError('Cannot read Stylesheet.',)

Originally Posted by dwanthny

The HTML TOC is inline the TOC for epub is in the menu. You should have a Table of Contents button on your screen under the book menu. This is where you will find the TOC.

Thanks again. I hadn't found that yet.

This seems more bothersome than it could be. I press the OPTIONS button, then Go to, then Table of Contents, then the name of the book (what else?), then finally several layers of TOC.

Anyway, my initial delight in finding online documentation in epub format is restored.

It sounds like the original ePub file had hardcoded the font sizes. Some folks use crappy apps to create ePub files. For example, MS Word is good for a self-contained document, but does a horrible job if you export a DOC file to HTML. MS Word, like most desktop word processors, wants to put a style on nearly every sentence in a document and this results in a huge overkill of styles that if converted to an ePub might result in hardcoded font sizes, font families, etc. I suspect the linux team didn't know squat about documentation and therefore created an extremely poorly formatted ePub from a DOC or some equally innappropriate format. When creating an ePub from scratch it is best to use an ePub creation tool or use simple HTML with as little CSS garbage as is possible.

[KenJackson]

Originally Posted by jswinden

I suspect the linux team didn't know squat about documentation and therefore created an extremely poorly formatted ePub from a DOC or some equally innappropriate format.

Your analysis of the problem may be correct, but let's not dump on the linux team.

I work for a company that is extremely image concious and is constantly harping on protecting our identity with correct colors and logos. I can well imagine them making the same mistake.

It's quite amazing that Red Hat is still in business and AFAIK still profitable. The CentOS Linux distribution copies the Red Hat source code, lock, stock and barrel (as the expression goes) and puts out a nearly duplicate product for free, though all mention of Red Hat is scrubbed. It's legal because of the GNU General Public License.

So what's left for Red Hat to make a profit on? Service. And their good name. So of course they are very sensitive about protecting their image by protecting how their docs look.

I just hope they find a way to protect it while making the docs readable too.


BTW, I can guarantee that Red Hat, a Microsoft antithesis, does not use Microsoft word for anything.

[KenJackson]

Here's one more piece of info.

Calibre also comes with the epub-fix command, which I also tried.
It found lots of errors, but almost all of them were images, .png, jpg and .svg, that were not in manifest.

Result: About the same size file, but it's still extremely sluggish. No value.

[elemenoP]

>After ePub to ePub conversion there's only one ePub left.
So there's nothing to choose from. <

What happened to the original file? It's been overwritten?

eP

[jashsu]

Originally Posted by KenJackson

One specific document I was looking at is the Virtualization Guide.

Has anyone experienced anything similar?

That document is hilariously out-of-spec.

Here's Azardi's reference spec report: http://goo.gl/sB4cg

[CazMar]

I also had this problem with some material I got off the web for Uni. I have done this before and just imported some texts etc into Sigil to make my own EPUB book - but in this instance it acted like a cold treacle! I had usually just copied a text file and added some basic HTML, but because I used the site's HTML it turned out to be full of unnecessary code (probably the web site was done in MS Word or similar). After stripping out all the rubbish it worked OK. Perhaps the ebook publisher had prepared the EPUB version using some program that used non-standard HTML code and is full of bugs. I think some publishers are having difficulty coping with a different way of presenting material, they are printers not web page designers. Different skills.

[KenJackson]

On doing some research, I suspect this file was created with the publican software package.

Publican is a DocBook publication system, not just a DocBook processing tool.

DocBook is kind of a miracle format that allows you to create a document once and convert it to almost any format. I'm pleased to see there is a DocBook to epub conversion tool. But I sure hope it generally does a better job than this or is fixed soon. Though I'm not certain that's what they used to create it.

Originally Posted by jashsu

That document is hilariously out-of-spec.

Here's Azardi's reference spec report: http://goo.gl/sB4cg

Interesting. I hadn't heard of Azardi, but it seems to be an epub verifier. You must have run it locally and posted the output on your own web page. Yes, that looks bad.

Originally Posted by KenJackson

DocBook is kind of a miracle format that allows you to create a document once and convert it to almost any format. I'm pleased to see there is a DocBook to epub conversion tool. But I sure hope it generally does a better job than this or is fixed soon. Though I'm not certain that's what they used to create it.

Does NOT sound much like a miracle format to me!

BTW, my intent was not to bash Linux, Red Hat, or say that any MS app was used. You obviously seem to hold you Linux feelings on your sleeve. My point, having been a technical writer for more than 25 years, was that many companies might know how to create software and hardware but few know how to create good documentation, especially ebook documentation. Most companies seem to put documentation on the bottom of their list of priorities.

My main point was and is that ANY format converted to ePub will not likely be as good as a document originally created in ePub. Most of the WYSIWYG document creators for HTML placed way too many tags and used way too much unnecessary CSS. The same is true of apps not designed to natively create ePubs. Whatever app they used to create their ePub, it did a lousy job, whether that offends you or not I could care less.