ePUB reader test

[Jellby]

In the spirit of the test file posted by charleski here, I've created another more extensive test file.

Do you have suggestions for other tests to include?

Also, I wanted to show the #3 bug here (Text shifted to right after a br tag in centered text), but it doesn't seem to be triggering, any ideas why? And I'm not sure if the external SVG tests (as an <img> and as an <object>) are correct: they don't show in a browser (Opera), but ePUB is not exactly XHTML, and from the spec I believe they should work.

All comments are welcome, of course.

[pdurrant: Added v2.2 by arspr ]

[DaleDe]

One variation of bug #3 is that lines starting with special characters will also extend too far to the right causing characters to be cut off is the line ends near the right margin. For example I had a bible with verse numbers that began each indented paragraph {1:1} xxxxx. Changing the line to [1:1] xxxx corrected the problem. I believe this is fixed on that latest firmware from ADE but older eBook readers don't have this fix.

Dale

[Jellby]

I have confirmed that the centering bug (#3) is fixed both in the latest Orizon and Gen3 firmwares, I had to test in an older ADE to see the bug in action. I have also changed the PNG images to indexed colour, which is what apparently triggers the bug.

Now, this is a report of what I see in my Orizon:

Boo Reader 3.1 (build 1398)
Adobe Reader Mobile 9.2 (build 38311)

1st margin: 5mm/6mm side margins, 1mm on top of the first page

2nd margin: 4mm/5mm side margins, no margin on top

Pagebreak Test: Pagebreak, no top margin after

Justification Test: Correct justification with the "Justify" option enabled or disabled

Centering: Blocks correctly centered and aligned

Auto Margins: All blocks placed on the left.

Long Paragraphs: Spurious pagebreaks after "porttitor nisi. Morbi", "vitae feugiat nisl." With hyphenation enabled, after "enim varius hen-", "blandit rhoncus quam", "felis id urna", "consequat quis", "libero. Aliquam in-".

Empty Elements: All four boxes shown, none with gray background.

Scale Tests: 5cm square -> 5cm; 10em square -> 4cm at 6th font size; 200px square -> 3.1cm (~164 ppi, so 200 real pixels); full height box -> breaks after text, then takes the following page (minus the text height in the first?)

Headers and Footers -> Both bold texts are visible.

PNG Support: 2-bit and 4-bit PNGs have problems, they show spurious hatching in gray areas.

SVG Support: Default text size equivalent to about 26.5 at 6th font size. External SVG appears in in <img> and <object>, but apparently <object> covers everything in its page, including the "As an <object>:" text.

Links Test: Text links work correctly, image links are underlined, but not selectable (key or touchscreen). Multilevel TOC shown flat, all items appear as the same level.

Default Fonts: Default font is customizable, but standard families do not change. "cursive" and "fantasy" look like "serif".

Smallcaps: No smallcaps at all (except in the 3rd paragraph, which is hardcoded), just the normal font.

Spaces: Em-space, thin space, narrow no-break space displayed as question marks, others apparently behave properly. With hyphenation enabled all spaces are supported.

Embedded Fonts: "italic Lobster" looks like normal italic "serif", "bold Lobster" looks actually bolder than normal Lobster.

Ligatures Test: Ligatures used if defined in the font, &zwnj; breaks the ligatures.

Unicode Coverage: Latin text in normal size (:lang not supported), Armenian and Thai displayed as crossed rectangles (with hyphenation disabled, as question marks). Apparently font substitution happens for characters in Czech, Greek and Russian not included in the font (Verdana, for instance).

Bidirectional Support: Hebrew and Arabic characters not available in default font, with the embedded fonts they are rendered left-to-right and left-aligned; Arabic ligatures used when hyphenation enabled.

[Toxaris]

Perhaps it would be nice to create an overview (on the wiki?) with the results of this test epub per reader.

[Jellby]

Look here

[Toxaris]

Great, I will run it for my good old PRS-300 and will report the results. Perhaps we should do it in a table if more devices get tested.

[snarkophilus]

Just for fun, on my Sony PRS-350 from your v2 test epub:

Sony PRS-350 Version 1.0.00.14080
PRS+ 2.0.12beta

1st margin: 2mm side margins (ragid right), 3mm on top of the first page

2nd margin: 1mm side margins, 2mm on top of the first page

Pagebreak Test: Pagebreak, no top margin after

Justification Test: Correct justification with the "Justify" option enabled or disabled

Centering: First centered block incorrect - second line a little to the right, third line further again right. Left aligned block correct. First right aligned block missing end of lines 2-4 (missing "et", "iscing elit", "unt", "m").

Auto Margins: All blocks placed on the left.

Long Paragraphs: Spurious pagebreaks after "fells. Integer", "pellentesque elementum", "congue mauris."

Empty Elements: All four boxes shown, none with gray background.

Scale Tests: 5cm square -> 5cm; 10em square -> 3.2cm at "S" font size; 200px square -> 2.6cm (600 pixel screen at 7.6cm wide, so 200 real pixels); full height box -> breaks after text, then takes the following page minus the text height in the first?

Headers and Footers -> Both bold texts are visible.

PNG Support: 2-bit and 4-bit PNGs have problems, they show spurious hatching in gray areas.

SVG Support: Default text size approx double size of 12 text (2mm vs 4mm) at "S" font size. External SVG appears in in <img> and <object>, both the same (small) size.

Links Test: Text links work correctly, image links are underlined, but not selectable (touchscreen). Multilevel TOC shown as multilevel.

Default Fonts: Default font is customizable (via PRS+ firmware), but standard families do not change. "cursive" and "fantasy" look like "serif".

Smallcaps: No smallcaps at all (except in the 3rd paragraph, which is hardcoded), just the normal font.

Spaces: Em-space, thin space, narrow no-break space displayed as question marks, others apparently behave properly. Hyphenation not supported (?).

Embedded Fonts: "italic Lobster" looks like normal italic "serif", "bold Lobster" looks the same as normal Lobster.

Ligatures Test: Ligatures used if defined in the font, &zwnj; breaks the ligatures. About half the reference image is cut off on the right side.

Unicode Coverage: Latin text in normal size (:lang not supported), Russian, Armenian and Thai displayed as question marks. Czech and Greek displays some question marks.

Bidirectional Support: Hebrew and Arabic characters not available in default font, with the embedded fonts they are rendered left-to-right (wrong order) and appear centered.

Custom Entities: Appear correct.

Cheers,
Simon.

[brewt]

Kids, this is awesome. Should be required testing for all devices. Buku on the kudos.

Yo, hardware developers: This is what y'all need to pass, cause, so far, ya ain't. Ya got somethin' to do now.

-bjc

[arspr]

Bump!!!

As Jellby has asked me to post it here, here I go...

As explained in this thread (epub vs kepub) in Kobo devices subsection, I've made a small enhancement to v2 of the test book in order to cover the following new issues:

• Trimmed fonts in left/right margin when justifying (suffered in Kobo kepub renderer called ACCESS).
• The drop of white-space: nowrap; support that RMSDK has suffered at least in Kobo implementation. (It correctly works in my old Sony PRS-650).
• The strange spaces ACCESS adds around a lot of punctuation marks which also break justification.

As I said in my original post, I'm no English native speaker so feel free to fix any kind of syntax, orthography or whatever errors and/or html/CSS coding...

[arspr]

Because the discussion in this thread of the Kobo forum about how these devices handle absolute font size units like pt or px, I've uploaded a new test to Jellby's test book. I've placed it after the Scale Tests section.

The answer (at least in Kobo devices) is that neither RMSDK (epubs) nor ACCESS (kepubs) seem to perform fine...