Hi folks,

I'm hoping to draw on your collective experience here. I have decided (almost) to get the prs-505 over the prs-700 and the other equivalents available to me here in Canada (BeBook, Cybook, NOT the Kindle). I was gung-ho for the 700 until I saw it in person sitting beside the 505 and there was really no question. The screen quality was the one thing I decided I would not compromise on given the choice. Anyway, why am I posting this here in the 700 forum? Well, it seems like there is a push for ePub to become a new standard and I am choosing Sony because they support it (and because I can buy it in person rather than online [sorry Cybook, it was a close one!], and because of Calibre). The 505 received a firmware update to support ePub, I believe, but is there anything about the ePub format that could overwhelm the slightly aging hardware of the 505 (compared to the 700) that I should consider? I think I read in another forum thread that large ePubs (or maybe complex ones?!) could cause the 505 to choke. Is this a realistic concern?
This is sounding less and less like a 700 thread, but I am in some small way considering the 700 for its pdf support (I'm a university prof who is kidding himself that he will use his reader for work related journal articles...but I might!) and its beefier internals.
Anyway, it seems clear the the 700 will handle PDFs better, but will this be true for other formats like ePub (beyond quicker loading and page flipping)?

Ramblingly yours... another flip-flopping liseuse shopper who should probably be in the 'which one should I buy' thread. Thanks!

the 700 is in no way hard to read. i prefer it over the kindle i used to have its a much better reading experience.

the 700 is faster, but i dont think its That much faster.

any place i could have read my kindle i can read the 700, and any place i couldnt read my kindle, i can read the 700.

i like my 700

Hi,

Thanks for the response. I have read and respect the many opinions about the 700 readability, and I will just have to balance the 700's strengths against the compromises that I perceive. I'm sure I would be happy with either one! Just curious about the potential strains that certain formats may place on the different hardware.

Thanks!

Both the 505 and the 700 use Adobe DE to render EPUB files. Adobe DE has several bugs, some of which cause the readers to reset when reading certain EPUBs (it isn't their length or complexity, it appears to be a bug in DE that causes it). I have seen reports of epub files that work on the 505 but not on the 700 and vice versa.

Both the 505 and the 700 use Adobe DE to render EPUB files. Adobe DE has several bugs, some of which cause the readers to reset when reading certain EPUBs (it isn't their length or complexity, it appears to be a bug in DE that causes it). I have seen reports of epub files that work on the 505 but not on the 700 and vice versa.

I've seen the reset bug: if you use both @page in CSS and XPGT it'll reboot the Sony Reader and crash desktop DE.

I've seen the reset bug: if you use both @page in CSS and XPGT it'll reboot the Sony Reader and crash desktop DE.

That's just one reset bug. There are several, including a few that desktop DE handles fine but the SONY Reader doesn't.

Hi,

Thanks for the responses. Sounds like an equal, but unpredictable flaw in both the 505 and 700.

That's just one reset bug. There are several, including a few that desktop DE handles fine but the SONY Reader doesn't.

Yeah, I also experienced this reset bug with files that were not using valid XHTML.

That's just one reset bug. There are several, including a few that desktop DE handles fine but the SONY Reader doesn't.

I've noticed the 505 has gotten a lot more unstable after the firmeware release. I've seen reset problems with their LRF files as well.

Personally I think they have a memory leaks in their reader.

=X=

I've seen the reset bug: if you use both @page in CSS and XPGT it'll reboot the Sony Reader and crash desktop DE.

Hadrien,

I am creating an ePub by hand and have an @page in my CSS and an XPGT file. Could you explain this bug more thoroughly? Or at least the conditions which cause it?
--MH

I've noticed the 505 has gotten a lot more unstable after the firmeware release. I've seen reset problems with their LRF files as well.

Personally I think they have a memory leaks in their reader.

=X=

Yeah, I don't understand why they don't fix this, it's been a know problem for two years now.

I've been making a lot of EPUB files lately out of some rather technical CHM related files (I'm slowly replacing my pulp library so I can keep everything, including all my notes(!) in this wonderful device) and have found that it's quite difficult to get right.

Some rules of thumb I've come across:


Make sure all tags are complete (no dangling tags). htmltidy does a great job here
Get rid of as many tables as you can! A lot of these CHM type files put the entire content of the page in one table and that causes tons of problems
"normal" tables tend to get truncated in the reader due to being too wide. Convert these tables to some intelligent lists with <hr/>'s around them
Play with the CSS to get the colors cleaned up. A lot of the "color" gets translated to light grey and it sucks. Best just to change everything to black that you can
<pre> blocks of code can go off the page as well. Use the CSS to shrink their font size and, at worst, reformat the blocks to keep them into a 70 character width at 6pt.


And get yourself a good editor. These are extremely complex edits and they occur across a ton of files... VIM (http://www.vim.org) has always been my editor of choice and it makes these kinds of edits a breeze (relatively speaking - say about 5-10 minutes per book) but if you're not used to this kind of editor, it's going to be more trouble than it's worth.

Good tips, applicable to many formats these days. How are you getting your CHM to work on you Sony?

Good tips, applicable to many formats these days. How are you getting your CHM to work on you Sony?

Essentially, it's a decompress of the CHM (via "Tubby" for the Mac), cleaning, and then html2epub specifying --breadth-first on the toc.html file.

The cleaning is the difficult part... sometimes much more labourious than it's worth. Some books are dead simple, but with books that have a lot of <pre> code, tons of tables, etc... these can be a real bear.

Honestly, my best tool for this (as with most things I do) is VIM (http://www.vim.org). I'm a seasoned VIM user and can make use of its vast amount of power for editing text, but for the average user to get a hold of and make good use of... it's tough. I've been using it for over 10 years, and I still have a lot to learn.

One of the most powerful features I use is the macro record and the ex commands. Most of the files "look" the same (i.e. have the same structure), so removing the big tables, getting rid of the annoying "next" and "previous" buttons, cleaning up the cruft, this is all something you can do "once" and then repeat automatically for all files. Standard search and replace across files is also very easy (like changing the unicode 0x97 character to a '-'), getting rid of the '\r' characters, which screw up the <pre> tags, etc... all of this stuff is quite easy.

I actually have been reversing the <pre> tag output to white on black instead of black on white and it looks a bit better.

Fixing up <pre> tag data can be simpler if you set VIM up to treat the HTML as Java, or C++ or whatever the <pre> contains and then tell it to reformat the <pre> section automatically - again, with a pre-recorded macro.

It's a bit of black art, voodoo kinda stuff that I haven't managed to script in any general way... I started by trying to write up some Ruby to do it, but the human element is hard to get rid of (i.e. does this table have a header that isn't declared as <thead>? where's the "right" spot to break this line of C++ code? Is this table superfluous or can it stay? etc...)