With my first foray into creating an epub, I've encountered a situation where the epub readers I'm using (ADE and Nook) don't recognize a couple of named entities found in Eastern European languages: &ccaron; (č) and &rcaron; (ř). I get a question mark -- though they do recognize &scaron; (š). Any idea why? I tried the number codes, also with no luck. The correct symbols appear in Kindle, so I'm wondering if this is a problem with the epub spec, or if there's a workaround.

Thanks.

DiapDealer

11-05-2012, 03:16 PM

Nothing to do with the spec, and everything to do with the default fonts that come with the device/app. Most devices that use Adobe's RMSDK don't ship with fonts that include the full range of unicode "characters."

Embedding your own font within your ePub is the only real workaround.

Points

11-05-2012, 05:55 PM

Thanks. Besides embedding, I'll see if Adobe and B&N have any plans to include the full set. Doesn't seem like it would require much additional effort on their part.

Update: I contacted Adobe and B&N, and, as expected, both said they didn't know anything about it but that they'd pass it on to the developers.

Toxaris

11-06-2012, 03:50 AM

But that won't solve your issue, since updates are scarce. Also older devices won't have updates at all. Font embedding is your best bet.

Jellby

11-06-2012, 04:12 AM

Good readers allow the user to install and use his/her own fonts, no embedding needed.

mrmikel

11-06-2012, 05:42 AM

Good readers allow the user to install and use his/her own fonts, no embedding needed.

But not everyone is knowledgeable enough to do so, so embedding the fonts is reasonable. However a full font set bloats the file size, no question about it.

DiapDealer

11-06-2012, 06:30 AM

It's definitely a tough situation. I've never liked the idea of embedding fonts to be used for the main "body" font of an ebook. It takes away the choice of the reader to use their preferred font (without editing the ebook). Yet being able to reliably count on special characters showing up as the content creators intended (without asking the reader to jump through hoops) is important too.

Adobe/vendors just really needs to nut-up here and start shipping "full-featured" unicode fonts with their devices/apps. It's a big world out there... and some of it uses squiggly marks over its letters.

Jim Lester

11-06-2012, 10:52 AM

Update: I contacted Adobe and B&N, and, as expected, both said they didn't know anything about it but that they'd pass it on to the developers.

I won't speak for Adobe, but for B&N we are in the process of updating the fonts we put into devices. While they won't have full Unicode coverage, the Latin-A set was definitely in there.

Points

11-06-2012, 02:02 PM

That's good news. When do you expect to release this?

DaleDe

11-06-2012, 03:04 PM

Another choice that will sometimes work is to embed an image inline with the text to represent the character. With many readers this image will even scale when the font size is changed.

Dale

Points

11-06-2012, 07:27 PM

But not all readers flow text around images, right?

DaleDe

11-06-2012, 08:42 PM

But not all readers flow text around images, right?

ADE does and that covers a lot of readers.

Dale

Jellby

11-07-2012, 04:00 AM

If the image is not higher than normal text, you don't need reflowing, you can treat the image as an inline element (a letter/word).

Toxaris

11-07-2012, 05:28 AM

In that case I would rather create a subset of a font with those letters and embed that. In my opinion that is more elegant than an inline image.

mrmikel

11-07-2012, 06:52 AM

I put in some Greek text in a John Buchan book at Harry's request and it looked just fine with the image inline with regular text. Since it was just in 4-5 places in the whole book which was in English, it was the reasonable thing to do without bloating the book with embedded fonts.

For those of us for whom Greek is Greek to us, it also makes sure it is correct!

Jim Lester

11-07-2012, 09:58 AM

That's good news. When do you expect to release this?

Well the HD and HD+, are going to be available this month (November). For the software updates, we haven't announced anything yet.

Points

11-07-2012, 02:22 PM

For some reason, I thought this thread had veered into using images for initial drop caps, which I had posted about in a different thread. I now see that you're referring to inline images for the special characters. I'd thought of that, but it wouldn't take into account the font or size the ereader is using. According to B&N, the Nook has three fonts. I suppose I could embed the three special characters for all three fonts (if I knew what the fonts were), but would the ereader select the correct one for the font being used? Could I code for it? And what would happen if the user changes the font size? Would the images scale with it?

DaleDe

11-07-2012, 02:38 PM

yes the image should scale with it but it would not change the image based on the font selection.

Jim Lester

11-08-2012, 10:50 AM

For some reason, I thought this thread had veered into using images for initial drop caps, which I had posted about in a different thread. I now see that you're referring to inline images for the special characters. I'd thought of that, but it wouldn't take into account the font or size the ereader is using. According to B&N, the Nook has three fonts. I suppose I could embed the three special characters for all three fonts (if I knew what the fonts were), but would the ereader select the correct one for the font being used? Could I code for it? And what would happen if the user changes the font size? Would the images scale with it?

I don't know who said 3, but that's not right. It's 6 Fonts, and the font sets change slightly between our color and e-ink devices.

I'm pretty sure that there isn't a way to select images based upon font styling.

Points

11-14-2012, 09:55 PM

If one were going to embed a font to use for the body of the text, to get the special characters, does anyone have any thoughts on serif vs. sans-serif? Are there any stats or a consensus on what users prefer?

JSWolf

11-14-2012, 10:14 PM

What I've found that works is to use a font family name of serif. That's generic and allows the system to still use serif to change the font family.

font-family: serif

JSWolf

11-14-2012, 10:16 PM

If one were going to embed a font to use for the body of the text, to get the special characters, does anyone have any thoughts on serif vs. sans-serif? Are there any stats or a consensus on what users prefer?

Use serif. More people prefer it to sans-serif. also, Charis SIL is a very good font to embed. Plus, it's free. I have a modified version that's slightly darker that looks good on eink. There's the link for the modified fonts. Even includes the smallcaps as well.

http://www.mediafire.com/download.php?64cse2dshispx08

Points

11-15-2012, 03:52 PM

Thanks--I'll try serif, though I read in another thread that embedding a font for body text slows down page turns significantly.

I found a character map for Charis, but it doesn't seem to have Eastern European characters. Also, if I specify serif, wouldn't that allow the device to choose another serif font, which won't have the special characters? I can find an appropriate cheap or free font at fontspring.com, which classifies them by languages, among other categories.

Jellby

11-16-2012, 04:06 AM

You can use Free Serif (http://www.gnu.org/software/freefont/) as a default embedded font.

In order to make the reader use the font, you have to define it in a @font-face rule, where you assign it a "font-family", and then you use that same "font-family" in other CSS styles. You are right, if you use simply "serif" the reader will probably choose its own default font (which may be serif or not, actually).

Points

11-16-2012, 03:26 PM

Thanks. Free Serif looks a lot like Times, but it may work. I'll give it a try.

JSWolf

11-19-2012, 06:42 PM

Charis SIL is a much nicer font especially the version I've created that has been tweaked to look better on an eink screen.

Here is the URL if you want to give it a go. Charis SIL is free and allowed to be used in eBooks.