Under new Overdrive model users will no longer choose a file format, just 'ebook'

[khalleron]

Originally Posted by Sil_liS

How does the page number thing really work? Does it hold across different devices? When you increase font size and modify the margins, what is the meaning of a page?

I don't know about Kindle, but an epub page is 1024 characters, so it's consistent among all epubs.

[vaughnmr]

Originally Posted by khalleron

I don't know about Kindle, but an epub page is 1024 characters, so it's consistent among all epubs.

Kindle provided page numbers correspond to an actual paper book edition, while the epub page number won't.

[Sil_liS]

Originally Posted by khalleron

I don't know about Kindle, but an epub page is 1024 characters, so it's consistent among all epubs.

And if you have an image?

[eBookNoir]

For OverDrive, they'll make their app which you have to use already, be the central point and it will in the background take care of mobi, epub or pdf, you just won't be able to tell, maybe features will be different, but it's not truly agnostic because you need their app to run it on your device.

Reasoning for PDF, many pubs have their titles in PDF and many of the systems for public libraries for eBooks run on pdf, ePub and mobi have only really taken off in the past couple of years. PDF isn't a true eBook since it lacks the reflowing abilities, it's a solution because the aggregators that libraries, all libraries work with work in pdf, only now are a small amount of true epub or mobi formats flowing into libraries.

[elemenoP]

An epub page is not necessarily 1024 characters. It CAN be tied to a print page. I did a test of creating an epub file from an InDesign file. When my InDesign file was 12 pages, the epub was 12 pages. When I changed the dimensions of the InDesign file such that it was now 20 pages, the epub was 20 pages.

eP

[khalleron]

Originally Posted by elemenoP

An epub page is not necessarily 1024 characters. It CAN be tied to a print page. I did a test of creating an epub file from an InDesign file. When my InDesign file was 12 pages, the epub was 12 pages. When I changed the dimensions of the InDesign file such that it was now 20 pages, the epub was 20 pages.

eP

I think what we have here is clash of the definitions of 'pages'.

An epub 'page' is 1024 characters, no matter what the formatting of the original document is. It is independent of 'page turns'. Page turns change when you change the formatting, pages don't.

It's why epubs have page numbers in the margins, to denote the beginning of each new page.

If you load your file into your reader and change the font size, is it still 20 pages, or 20 page turns? The number of page turns will change, but the number of pages should be constant.

[AnemicOak]

Originally Posted by khalleron

I think what we have here is clash of the definitions of 'pages'.

An epub 'page' is 1024 characters, no matter what the formatting of the original document is. It is independent of 'page turns'. Page turns change when you change the formatting, pages don't.

It's why epubs have page numbers in the margins, to denote the beginning of each new page.

If you load your file into your reader and change the font size, is it still 20 pages, or 20 page turns? The number of page turns will change, but the number of pages should be constant.

Generically they're 1024 characters when nothing tell it any different, but an ePub can also be marked up so that the page numbers correspond to the page numbers in a print edition instead (you'll still have any given number of 'screens' per page of course).

[elemenoP]

Thanks, AnemicOak, that explains a lot. I wasn't talking about page turns, by the way.

But now I am also reading that the generic definition of a page is 1024 bytes, not 1024 characters. I am not sure what the difference is?

For most books that you would get through B&N (let's say), would they use the "page map" function that ties to a print edition, or would the number of pages be calculated by the number of bytes or characters?

And why does Calibre's book viewer calculate the number of pages so differently than my Sony Reader does?

eP

[HarryT]

Originally Posted by elemenoP

Thanks, AnemicOak, that explains a lot. I wasn't talking about page turns, by the way.

But now I am also reading that the generic definition of a page is 1024 bytes, not 1024 characters. I am not sure what the difference is?

A "page" in a reader that uses Adobe's ePub firmware is 1024 bytes in the compressed file; the number of "pages" will therefore change if, for example, the level of compression of the file changes. This page definition is specific to Adobe's software; it certainly isn't a part of the ePub specification.

And why does Calibre's book viewer calculate the number of pages so differently than my Sony Reader does?

Because Calibre isn't using Adobe's ePub viewer.

[AnemicOak]

Originally Posted by HarryT

This page definition is specific to Adobe's software; it certainly isn't a part of the ePub specification.

The page-map attribute is specific to Adobe, but I thought I read that the <pageList> markup had been added to the regular ePub spec.

[ATimson]

Originally Posted by AnemicOak

The page-map attribute is specific to Adobe, but I thought I read that the <pageList> markup had been added to the regular ePub spec.

Harry's talking about the "automatic" page numbering that ADE does in the absence of the page-map.

page-map is generally Adobe specific, though Kindlegen supports it. And <pageList> was added to the ePub spec, but only Kindlegen does anything with it.

[Namekuseijin]

Originally Posted by Sonist

Uhm, no. You are wrong. PDFs can reflow to display on smaller screens just fine. Do a search for "tagged PDF."

I searched for it and it requires manual intervention, which means the millions of book scans from Google Books PDFs do not have it. PDF is not used just for fixed layout, but also as a simple container of images, which is what scans are.

ePubs require either manual typing of the text (easy for new books but hard for classics a la gutenberg) or OCR to automatically convert from the scans. PDF is way cheaper because it doesn't need OCR, just the page scans.

The very purpose of PDF is fixed layout. It's simply not ideal for electronic displays and people wanting to define their own preferred font, line and margin sizes.

[Sil_liS]

Originally Posted by Namekuseijin

I searched for it and it requires manual intervention, which means the millions of book scans from Google Books PDFs do not have it. PDF is not used just for fixed layout, but also as a simple container of images, which is what scans are.

ePubs require either manual typing of the text (easy for new books but hard for classics a la gutenberg) or OCR to automatically convert from the scans. PDF is way cheaper because it doesn't need OCR, just the page scans.

I don't think that Sonist was talking about scans. You do know that you can easily generate pdf files from other file types, and that those will reflow, right?

[ATimson]

Originally Posted by Sil_liS

I don't think that Sonist was talking about scans. You do know that you can easily generate pdf files from other file types, and that those will reflow, right?

Kinda, sorta, not very well in my experience.

[Sil_liS]

Originally Posted by ATimson

Kinda, sorta, not very well in my experience.

Which device did you use? And which software?