Quote:
Originally Posted by Jellby
True. But it is also true that it's not sensible to expect unlimited size support in all applications.
|
I don't think that's the case. In virtually all modern programming environments, there's no reason to impose file size limits, except for the cases where system APIs or system resource allocation restrict the application.
Quote:
Originally Posted by Jellby
The ePUB spec should probably have stated some minima for filesizes (and maybe nesting levels or number of styles) rendering software must support, so that a file can be guaranteed to work in conformant readers. Readers with more resources available could support larger limits, but there would be some minimum we could rely on.
|
Not at all. The parse tree required to display any given point in an ebook is never going to be complex enough to be an issue (we're talking kilobytes in systems that have had megabytes of user space memory for approaching a decade or so). If a device is resource restricted it might have to take the long way round to display a page, but that's a design decision on the part of the device manufacturer and shouldn't be the concern of the standards committee.
Certainly epub offers the developer many choices as to how they render the document. Nothing in the spec requires that any given section of the document have to be stored in memory at one go in order to be rendered.
The only 'reasonable' restriction might be to say that a device with X megabytes of storage space should be able to render the largest single book that can fit on it's storage. How they go about doing that is up to the firmware developer. Again though, it's really no business of the standards body.