HTML books

[Reini68]

As I couldn't find a thread concerning this issue I decided to open a new one on this, even that I just can't believe that this is not a know issue.

When trying to open ebooks that are html it takes minutes until they are loaded. Well after all it's not a big issue converting them to pdf but what I'd like to know is, if this is a known issue with the iLiad that opening big html-files causes problems?

[wallcraft]

Are you reading them with FBReader?

[Reini68]

No, with FBReader (that is adding them to the library and then chosing them from there) this is different. But when I chose them directly from content-lister it seems to take an eternity to open.

[Shaggy]

Do they contain any graphics, or just text? I've heard iRex say before that if the ebook you're opening contains any graphics that are not pre-formatted for the screen size, it can be really slow if it needs to resize them "on the fly".

[Reini68]

No graphics. Just plain HTML as I use it to create mobipocket books. So no stylesheet. only using h1, h2, p and blockquote. Of course some italics, height=, width= but no complicated html. As they are books they are big of course - let's say 500+ k.

[sharpshin]

I had many problems with a large HTML book (Rainbow's End by Vernor Vinge). It would open, but links took forever to navigate from the Table of Contents. I say forever, since I would lose patience and flip the page bar; it would then display some page before I was trying to navigate to. The HTML was all just text. I eventually gave up and made a PDF with HtmlDoc. No more problems.

Bottom line, I thing the HTML reader is broken for large documents.

[DigiDirk]

I would not say broken, but...

Since said HTML book does not contain pagebreak information
it has to be rendered in one big / long / however you call it page...

Read such - but not so big - book once. Having just one page I had
to scroll every time I stopped reading back to the line I read last.

Not too bad in the beginning, but towards the end of the book
quite unnerving...

Converting your book to PDF will bring you pages and the IPDF viewer
has the capability to remember your last page read.

Dirk

[James Bryant]

Originally Posted by DigiDirk

I would not say broken, but...

Since said HTML book does not contain pagebreak information
it has to be rendered in one big / long / however you call it page...

Read such - but not so big - book once. Having just one page I had
to scroll every time I stopped reading back to the line I read last.

Dirk

But how do you do THAT? I have several 5+ MB HTML books and they're several thousand "pages" long. Even if you remember where you were, how do you get there quickly? I would call that broken.

My old REB1100 allocated page numbers, and remembered them. And when you turned it back on, there you were in a couple of seconds, not half a minute or more. I know the files were not HTML, but RB files are constructed like HTML. Moreover if you changed the font size you did not lose your place and the page numbers changed accordingly, so fast software techniques to do it must be available.

James

[Dabon]

Hi James,

Have you tried FREE Mobipocket Creator? It did work wonderfully for me...

Thanks,

Dabon.

[Jadon]

Originally Posted by James Bryant

My old REB1100 allocated page numbers, and remembered them. [...] Moreover if you changed the font size you did not lose your place and the page numbers changed accordingly, so fast software techniques to do it must be available.

The REB didn't do such calculations of the fly. When the ebook was constructed, the creation program pre-paginated for two font sizes that you could switch between. So the logic was something like "page 123 in medium font is text-block 8764 which translates to page 495 in x-large font according to the lookup table". All the heavy lifting was done at creation time, and and depended on having only two fixed choices. If a unit lets one change fonts and select any size, that "figure it out ahead of time" ability is lost.

[nrapallo]

Originally Posted by James Bryant

But how do you do THAT? I have several 5+ MB HTML books and they're several thousand "pages" long. Even if you remember where you were, how do you get there quickly? I would call that broken.

My old REB1100 allocated page numbers, and remembered them. And when you turned it back on, there you were in a couple of seconds, not half a minute or more. I know the files were not HTML, but RB files are constructed like HTML. Moreover if you changed the font size you did not lose your place and the page numbers changed accordingly, so fast software techniques to do it must be available.

James

Originally Posted by Jadon

The REB didn't do such calculations of the fly. When the ebook was constructed, the creation program pre-paginated for two font sizes that you could switch between. So the logic was something like "page 123 in medium font is text-block 8764 which translates to page 495 in x-large font according to the lookup table". All the heavy lifting was done at creation time, and and depended on having only two fixed choices. If a unit lets one change fonts and select any size, that "figure it out ahead of time" ability is lost.

This is only true for the Ebookwise 1150 as it has actual page numbers and can display only two font sizes for which the page numbers are pre-computed at "creation time".

The REB 1100 only has a vertical bar that shows your progress "into the ebook" and does not display page numbers. I believe the REB 1100 can calculate the pages "on the fly" since it can use any two sizes of "user selected" fonts which are not (necessarily) known at "creation time".

Both readers (EBW 1150 and REB 1100) were designed and manufactured in early 2000, but are very capable at handling large html files with many hyperlinks once they are "converted" into the reader's native format by its conversion software.

[James Bryant]

Originally Posted by Dabon

Hi James,

Have you tried FREE Mobipocket Creator? It did work wonderfully for me.

Dabon.

I have over 5,000 books in HTML format - I want to read THEM, not waste my life converting them all into something else.

Is it really unreasonable to expect an ebook reader to handle all the formats it is supposed to handle properly?

If they are to work for the general public, rather than enthusiasts who appear on forums, they must plug in and go. I regard any start-up time in excess of 5 seconds as unacceptable, too.

James

[DigiDirk]

As I already mentioned here the iLiad's html viewer (note the name) is based
on the minimo browser.

Irex apparently did not consider books in html format, so the viewer
behaves as your average browser.

That is the underlying bug.

Irex is working on a new viewer concept (see posting #6) and I have high hopes that they
will take html books into account.

Dirk

P.S.: You certainly could install FBReader, but that includes the Developer Package
and certainly is not plug in and go.

[wallcraft]

Originally Posted by James Bryant

I have over 5,000 books in HTML format - I want to read THEM, not waste my life converting them all into something else.

This is precisely the philosophy behind FBReader. Many of us were under whelmed by Adam B.'s heroic efforts to fully integrate FBReader into the iLiad scheme of things (prefering FBReader's standard interface), but Integrated FBReader 0.8.14 with ePub and Registry Support is open source code that works exactly like "standard" iLiad software and iRex could bundle it with their releases. Adam did not change the registration of HTML and TXT files to FBReader, but this package will likely provide a much improved experience for these filetypes than the current rudimentary support. It is also better than the MobiPocket Reader for DRM-free MOBI files (e.g. it supports different fonts). In fact, since iRex has a licence for MOBI DRM, they could bundle a binary-only version of FBReader with DRM-support and get rid MobiPocket's poorly supported Reader completely.