Sony Reader file size limits and ePubpreflight

[Dave Cramer]

Hi,

I'm getting anecdotal reports of ePubs that pass ePubpreflight but
won't load on the Sony Reader due to the file size limits. I have a
few questions about this issue (which has been a major headache for
us, especially given we created lots of ePubs before this problem was
widely publicized!).

[1] It appears that ePubpreflight only check that files are less than
300k uncompressed. A file that size could conceivably be more than
100k compressed (which is the other restriction). Which is the actual
limit on the Reader?

[2] The Desktop version of Digital Editions can issue a warning about
components being too large. Does this use the same check as
ePubpreflight? Is it more or less reliable?

[3] Does every model of the Sony Reader have exactly the same limits?
Are they at all dependent on circumstance?

One publisher we work with has adopted much tighter restrictions (200k
uncompressed or 80k compressed).

Dave

[Peter Sorotokin]

Dave,

[1] both limits must be met.
[2] it is the same and it is probably more reliable.
[3] this is configurable by OEM, but no one is going below 100k/300k limits as far as I know.

You may want to adhere to tighter restrictions so that performance is good. The smaller the chapter size the faster navigation is, especially to the end of the chapter. Contrary to popular belief, these restrictions are for performance, not memory reasons, so a better test would be to just look at the performance on the device (e.g. going to the end of the book and flipping through it backwards) instead of relying on such rough measurements as compressed/uncompressed size.

Peter

[Stuart A. Yeates]

On Thu, Oct 8, 2009 at 3:32 AM, Dave Cramer <d.cr...@textechinc.us> wrote:
>
> I'm getting anecdotal reports of ePubs that pass ePubpreflight but
> won't load on the Sony Reader due to the file size limits. I have a
> few questions about this issue (which has been a major headache for
> us, especially given we created lots of ePubs before this problem was
> widely publicized!).

I've got to admit that we're treating this issue as a bug in the Sony
Reader and thus not our problem.

We have a number of reference works with a content.opf of larger than
a megabyte uncompressed. Restructuring the works to reduce this size
is not really an option for us, unfortunately.

See for example: http://www.nzetc.org/tm/scholarly/tei-Cyc03Cycl.html

cheers
stuart

[Rajesh Kumar]

I agree Stuart. We should not enhance the ePubPreflight tool to meet condition for a specific device limitation, instead whichever device that advertise themselves as supporting EPUB must strictly adhere to EPUB specification. According to me, this is a bug with Sony Reader. Let them fix it. Let our validation tools focus only on EPUB guidelines recommendation.

2009/10/8 Stuart A. Yeates <sye...@gmail.com>

[Peter Sorotokin]

Just because EPUB spec does not define a specific limits does not mean limits are not allowed for EPUB Reading Systems – there is pretty much consensus on that in the IDPF WG. Or do you take a position that resources of absolutely any size should be acceptable for these fairly low-powered devices? It is up to you, of course, – but I do not think that position is reasonable.

 

We do plan to relax chapter size limitation in the future, but documents with long chapters will always work slow, drain device battery faster, may have artificial page breaks and may have some styling dropped. They will never perform as good as documents with short chapters. Almost all ebook distributors want such documents flagged if not rejected.

 

BTW, the important limit is for chapter size, not OPF. It is understood that OPF can grow to a fairly large size.

 

Peter

[Stuart A. Yeates]

On Thu, Oct 8, 2009 at 8:42 PM, Peter Sorotokin <psor...@adobe.com> wrote:
> Just because EPUB spec does not define a specific limits does not mean
> limits are not allowed for EPUB Reading Systems – there is pretty much
> consensus on that in the IDPF WG. Or do you take a position that resources
> of absolutely any size should be acceptable for these fairly low-powered
> devices? It is up to you, of course, – but I do not think that position is
> reasonable.

We're a not-for-profit unit mainly republishing historic New Zealand
works and a handful of contemporary New Zealand serials; most under CC
licenses. We switched to epub from lit as our preferred eBook format
because as a consequence of the open format we can generate and
validate them more easily.

If you look in one of our epubs, you'll notice that the real work is
actually adding non-epub educational metadata (see
http://en.wikipedia.org/wiki/IMS_Global ) into our eBooks. If our
funders had to pick, I'm pretty sure they'd prefer that users were
able to upload their content into their VLE rather than their eBook
reader.

> We do plan to relax chapter size limitation in the future, but documents
> with long chapters will always work slow, drain device battery faster, may
> have artificial page breaks and may have some styling dropped. They will
> never perform as good as documents with short chapters. Almost all ebook
> distributors want such documents flagged if not rejected.

I don't believe we're overly beholden to eBook distributors.

How would they be flagged, exactly?

> BTW, the important limit is for chapter size, not OPF. It is understood that
> OPF can grow to a fairly large size.

Thank you, I'd forgotten that.

cheers
stuart