Embedded font bug or CSS bug in ADE
 

1. Get a copy of Notepad++ and an ePub with Charis SIL embedded.
2. Extract the CSS and load the CSS into Notepad++.
3. Change the encoding of the CSS to Encode in UTF-8.
4. Put the CSS back into the ePub and view the ePub in ADE.

Now, you'll see that the base font is bold when it's not supposed to be.

Take the same CSS and change the encoding to Encode in UTF-8 without BOM

The base font will be fine. The bold is gone and the text is normal once again.

Does anyone know why this happens and that the cause is? It also happens on my 650 as well as ADE for Windows.

For those with a different reader that uses ADE, I'd be interested in seeing if that bug exists.

At a first guess, I would think it has less to do with the embedded font, and more to do with the encoding of the CSS.

While the ePub 2 spec wasn't explicit on it, the CSS should be UTF8 encoded, but the whether or not the byte order marks are there shouldn't matter. So my guess is that there is something in the tool chain you are using that is outputting UTF8 that is causing RMSDK problems.

Have you tried editing CSS with non embedded fonts?

I am using Notepad++ to do the editing. If I change the encoding of the CSS to UTF-8, the bold shows up. If the encoding is UTF-8 without BOM, then the font displays fine. If I remove the embedded font, the bolding is normal and no problem using the default ADE fonts.

I'll attach a couple of B&N samples later tonight. One that shows the problem and one that does not. And the only difference will be the CSS encoding.

I just tried what you described and confirmed that (at least on my OSX machine) ADE fails to load files containing the ByteOrderMark.

Here's what I did:

I created a simple html containing a paragraph with bold text and added an external stylesheet which resets the font-weight of the bold element to normal.

When I create the book with those files in the normal UTF-8 (or ascii) encoding everything's fine. But if I change the encoding of the stylesheet to UTF-8 with BOM the bold element is displayed bold again, meaning that the css file has not been loaded. Whats even more curious: changing the encoding of all of the other files to contain the BOM as well doesn't disturb ADE - even for the mimetype file. So stylesheets are the only one affected...

What does that mean in your case? You probably have either presentational elements in your html markup (b, hx, unclosed hx, ...) or you have a css rule somewhere that declares your global text as bold which is then overridden back to normal by the stylesheet with the BOM - which isn't loaded due to its BOM, so the text remains bold.

Don't use the BOM and you're fine.

This is an eBook sample from B&N. I've added in Charis SIL as the embedded font. The first sample and the second sample are identical except for the CSS. The CSS in the first sample is ansi encoded and the second sample has the CSS UTF-8 encoded.

When you view the first sample (using ADE), the embedded font is as it should be. When you view the second sample (using ADE), the embedded font is not correct. It's bold where it should be normal.

Why this is, I do not know. It's a very odd bug. The code in both CSS is perfectly OK.

RMSDK 9.1 is not happy with the CSS in SSM02.epub and emits the following errors:
RMSDK 9.2 handles the files correctly (and renders both correctly). So it looks like a bug handling the text encoding format, that has been fixed (Peter could confirm this).

Unfortunately ADE 1.7 is using a fairly old version of the RMSDK 9.1 or before IIRC. Here's hoping Adobe will come up with a more modern version of ADE.

But why is ADE using the bold font instead of the regular font? That's just odd. Anyway, I do see one major issue happening with ADE.

As ADE improves, we are going to have a lot of devices out there with an old version of ADE. So the problem will be that ePub eBooks will have to pander to these older versions instead of using any of the new features. So when ePub gets upgraded, it won't matter as we'll have old ADE that needs to work. I doubt every company will be updating all their readers and/or apps. This is going to cause a splintering if publisher go with new ePub features.

For example, I doubt Sony would update the 500, 505, 300, 600, 700, 650, 350, & 950 with a newer ADE. If Sony was to use a newer ADE, it would be on a newer reader. And this would mean when ePub is updated to use CSS3, and ADE follows, and publishers start using CSS3, all those Sony users would be stuck big time.

I think Adobe should have made it mandatory for companies to update the ADE as they do as long as it would run on the given hardware. That way, we would not have to worry about updated spec with non-updated ADE.

Sorry, I didn't feel like spending the time to figure out what is happening in the cascade of the style. But basically RMSDK partially read in the style sheet and got to a particular point and errored out. The style at that point indicated it should be bold. If you rejiggered the style sheet a bit, I bet you could avoid it (BTW just in case this is your style sheet there are some minor errors in the style sheet at lines 651, and 977,1657 ), but you can also avoid it by making sure it is UTF8 encoded without a BOM, so I didn't dig into much further.


Well given Sony's track record for firmware updates (1 that I remember 500 -> 500A), I'm not going to argue about that. That's certainly something to keep in mind when shopping for devices :)

And perhaps onerous requirements could've scared off the developers before the market got started --- there are arguments either way. Same arguments to be had here as there are for the various app stores, btw.

Other then adding in the code for the fonts and the body, the rest of the CSS is as it came from the publisher.


I see the same thing for other companies as well. Not just Sony. But we'll just have to wait and see if publishers force their hand when the new ePub spec is released.


True, I can see it from both sides. But from a realistic standpoint, I don't see why not to update ADE so it will handle the newer spec when it's out and ADE is updated for it.

The biggest block of changes in the upcoming ePub3 spec is the HTML5 elements - Video tag, Canvas tag, et al and JS support. On an eInk screen, and especially eInk devices with no network connectivity(ie 350/650 vs 950) - support for this would seem to be a less than compelling use case.

However vertical text support (among other things needed to do good layout of CCJK text) is also in the ePub3 spec, and Japanese text layout in ePub may be a compelling use case for Sony.

I hope so. Since Sony released the 650 in Japan. That would be good to see Sony update ADE.