View Single Post
Old 06-21-2009, 12:00 PM   #41
kovidgoyal
creator of calibre
kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.
 
kovidgoyal's Avatar
 
Posts: 45,423
Karma: 27757236
Join Date: Oct 2006
Location: Mumbai, India
Device: Various
Quote:
Originally Posted by Tuna View Post
I'm fully aware of CSS selectors thank you :-) I've been involved with web browsers - at the software level - for just shy of 15 years now. There's no reason why you can't stream through an XML document and flatten the selector space as you index it - and as the range of styles in a document is rarely that extensive the penalty for doing so is minimal.
So every time either the user or some javascript makes a change to the DOM/CSS you propose re-indexing the entire tree (at least upto the current point?) For example, calibre's EPUB viewer actaually supports a reference mode that changes the DOM and the CSS of document elements on the fly in response to user interaction. The scheme you propose might work well for static content that the user never interacts with/modifies but not for anything else. And frankly making that trade-off (removing size restrictions but making interactivity much slower) is just wrong.

Quote:
Inelegant solutions are necessary where you are trying to provide the ideal user experience. Agreed that completely free font sizing, line spacing and margin adjustments present an insurmountable task. However, it's worth noticing that most devices don't offer unlimited options, and most users will only ever select a small subset of those. Indexing (not storing rendered versions - ugh!) need only be performed on the most recent and most preferred choices. It's only when the user is determined to cycle through every option whilst reading the last page in a document that the interface need degrade to worst case re-parsing. Notice that even then, the experience is no worse than current 'all in memory' solutions. With indexing for rendering being a multi-level process, even that worst case can be hurried along by removing the need for dealing with overly complex parse trees.

Umm imposing a size restriction is an inelegant solution, but one that works for end users, EPUB creators (provided they just keep it in mind) and the creators of EPUB document viewers. Instead you propose a system that offers a very slight benefit to EPUB document creators and very large overhead on the creators of EPUB rendering software for no benefit to EPUB end users. If people had to guarantee that EPUB renderers could render any size/complexity of XHTML on any device, the format would never have gotten off the ground.
kovidgoyal is offline   Reply With Quote