There are frequent questions about the number of pages shown for e-books compared with paper books. This is an interesting side-effect of Adobe's attempt to provide page numbering in an e-book format (EPUB) that doesn't really do pages.
The text in an EPUB file basically consists of a collection of HTML files, just like Web pages. Just like on the Web, each text file is one huge page that you scroll down (or up) through. How the text of the e-book is broken up into separate files varies, but commonly each file contains one chapter. It's recommended that no file be over about 1/4 Megabyte, to keep readers from running out of memory from trying to handle a big file.
When your reader transitions from one of those "chapter" files to the next, there is a page break. The earlier file might finish near the top of the screen, leaving a bunch of white space. This works very nicely if each file contains a chapter—the new chapter heading appears at the top of the next screen. There also can be a delay while the reader opens up the next file. For this reason, it's not recommended (and rarely done) to put each book page into a separate file.
So… a typical EPUB ebook might have a couple dozen "chapter" files in it. One for each chapter, plus a few for pieces like the front cover, front matter, etc. But the number of pages shown is a whole lot more than a couple of dozen, right?
Here's the deal: Adobe "synthesizes" the page count and page numbering. Adobe reader software looks at the size of each of those HTML files and counts one page for each 1K (1024) bytes in size, rounded up. So if the file is 114 bytes, that's one page. 1024 bytes, one page. 1025 bytes, two pages. Now, what it's looking at is the actual size of the file inside the EPUB, and an EPUB is just a ZIP file with a specific layout. Since it's a ZIP file, the contained HTML files are compressed. Adobe uses the compressed size, not the actual number of bytes in the original HTML file. Anyway, it adds up all of those page counts and that's the number of "pages" in the e-book.
Within each "chapter" file, the pages are divided up evenly. So a "chapter" file that was 1025 bytes is two pages, right? Let's say that after it's uncompressed, there are 2425 characters in that "chapter" file. The first page will be 1212 characters long, and the second will be 1213 long.
Notice that because the page count is based on the compressed size, the actual number of characters per page is not really predictable. It also varies between "chapter" files, since the compression ratios may be different. It'll probably be somewhere around 2000 characters, or 350 words, plus or minus a bunch. (The character counts include the HTML markup in addition to the actual visible text.)
By the way, if DRM has been applied to the compressed "chapter" file, Adobe will attempt to account for any DRM overhead before calculating the number of "pages" in that file. This way the number of "pages" is (we hope) the same for DRMed and un-DRMed versions of the same e-book.
Keep in mind that this is just how Adobe does it. Since NOOK uses Adobe Reader Mobile for EPUBs, and Adobe Digital Editions and the various NOOK apps also use EPUB software from Adobe, they all agree as to "page" numbering. That's Adobe's plan: the page numbers don't mean anything you can put your finger on, but for a given e-book they are constant from one platform to another.
P.S. Adobe offered an EPUB extension called a "page map" which allowed specific page numbers to be applied to HTML anchor tags. However, that extension is non-standard EPUB and is generally discouraged. The NCX file inside the EPUB (essentially the table of contents file) also has the ability to tie page numbers to specific locations within the EPUB text, but pretty much no readers pay any attention to that. So for now, Adobe's synthesized "page" numbering is about all we've got for EPUB.