Problem with inline image

[JSWolf]

Originally Posted by Hitch

I'm beat tonight, and tied up MOST of tomorrow

You are a kinky one.

[eggheadbooks1]

Tex,

I do know how to embed a font, but I wrongly thought the symbol was only available in Webdings (which the author used), and Webdings is copyrighted.

The problem with font embedding is 1) not all ereaders support font embedding; 2) if the user turns off publisher formatting, the symbol will disappear; 3) if the ereader does not read CSS, the symbol will disappear.

On the other hand, if the reader does not read CSS, the image will become HUGE because the em value is in the CSS. (I wonder if I should do both: put the em value in the CSS and in the HTML?)

What a dog's breakfast. This is why I suggested she not use the image. It's not integral to the book.

I am curious, though, as to why you included SSs of Kindle. Kindle reads the Unicode without the need to embed the font. (I am naming my firstborn after Doitsu for that.)

Thanks, Tex, for taking the time to create a test book, screenshots, and the code for embedding a font. Much appreciated.

[eggheadbooks1]

Okay, just tried a test whereupon I put the 1em value in BOTH the CSS and the HTML -- and voila! The symbol image appears and scales as intended whether or not the user turns publisher formatting on or off.

HTML:

<p class="NoIndent">While reading the novel, when you see <img alt="note symbol" height="1em" src="../Images/note2.gif"/> together with the name of a song, the link will take you to the song on YouTube.</p>

and CSS:

img
{height:1em;}

[eggheadbooks1]

Originally Posted by Hitch

I see your other post about the hell of Apple images; I'm beat tonight, and tied up MOST of tomorrow, but I'll try to get to it tomorrow night or Sunday, if I can.
Hitch

Hitch,
In the interest of not sidetracking this thread, I started a new thread on the above issue. When you come up for air it's here:
https://www.mobileread.com/forums/sho...82#post3389482

Thanks.

[Tex2002ans]

Originally Posted by eggheadbooks1

Thanks, Tex, for taking the time to create a test book, screenshots, and the code for embedding a font. Much appreciated.

Originally Posted by eggheadbooks1

I am curious, though, as to why you included SSs of Kindle. Kindle reads the Unicode without the need to embed the font. (I am naming my firstborn after Doitsu for that.)

Many people here create their MOBIs by feeding an EPUB into KindleGen. I just wanted to show that the font embedding for those musical notes works in EPUB + MOBI at the same exact time.

Many of us try to settle on solutions that work across formats, instead of having to annoyingly create format- and vendor-specific EPUBs (one set of code for Apple, one set of code for ADE, one set for Nook, one set for Amazon, [...]).

Originally Posted by eggheadbooks1

I do know how to embed a font, but I wrongly thought the symbol was only available in Webdings (which the author used), and Webdings is copyrighted.

I believe almost all of Webdings symbols have an equivalent UTF-8 character. Here is a giant table of equivalents:

http://www.alanwood.net/demos/wingdings.html

Side Note: I forget if Toxaris's EPUB Tools handles the conversion of Webdings -> UTF-8? I know that Toxaris implemented the Symbol font -> UTF-8 after we came across some Greek/Math shenanigans.

Originally Posted by eggheadbooks1

The problem with font embedding is 1) not all ereaders support font embedding; 2) if the user turns off publisher formatting, the symbol will disappear; 3) if the ereader does not read CSS, the symbol will disappear.

Indeed indeed. If I didn't lay out my typical list of Pros/Cons in that Apple Symbol topic, I would add that as a Con for the Font Embedding method. I typically like to organize all of the Pros/Cons I can think of, and leave it up to you to decide which method you want to go with.

Personally? I have settled on using the UTF-8 characters + Font Embedding. If the device doesn't handle UTF-8 reasonably AND can't handle fonts? Too bad, that is on them.

Side Note #1: Similar to your music notes, I run into this situation all the time with Polytonic Greek characters. Many fonts/devices don't have some of the more obscure accented Greek characters. That won't stop me from actually using the actual UTF-8 characters. All of the Pros of actual characters heavily outweighs the Pros of a bitmap (in my mind).

Would you rather read this?

[...] cannot therefore conceive that social institutions could have arisen in any way except through the intervention of a ‘world shaper’ of the Platonic

or this?

[...] cannot therefore conceive that social institutions could have arisen in any way except through the intervention of a ‘world shaper’ of the Platonic δημιουργὸς.

I don't believe I can upscale that image in ems on MobileRead, but you can imagine how crappy that would look compared to the pure text. The problem with bitmaps only gets worse the higher DPI becomes as well.

(This was an example of Greek Images used in one of the latest books I fixed.)

Side Note #2: Back in 2014, we also had a nice discussion about Image/SVG/HTML Tables:

https://www.mobileread.com/forums/sho...69#post2850269

Almost all of the same exact arguments apply here (as you can probably guess, I am in the HTML Tables camp). :P You can also see example images where I changed the background to black + red font.

[eggheadbooks1]

Many people here create their MOBIs by feeding an EPUB into KindleGen. I just wanted to show that the font embedding for those musical notes works in EPUB + MOBI at the same exact time.

But I was reading on another thread that people are having trouble with font embedding with Kindle after the file is uploaded, likely due to Amazon's decision to strip out font family information (that others leave in not knowing this interferes with the user's ability to change fonts). So even though Amazon say you can have font embedding, they are screwing people's files up by automatically removing the font family information from the CSS; their automatic system cannot seem to tell the difference between font-family information not attached to an embedded font, and that which is. WTF Amazon? (Don't know if they've fixed it since.)

I, too, wish it were possible to create an ePub that works across all platforms, but that has become a fantasy ever since device manufacturers began using image coding as their new DRM.

And since Kindle is a format all its own I don't worry about making the ePub work with Kindle. I also use Kindlegen to make my mobi files from ePubs, but I modify a copy of the ePub to make it Kindle-specific before conversion.

Thanks for the link to the Unicode Webding equivalents. Will bookmark that for later reference.

I am also in the HTML table camp. I believe the more you can do in HTML, the better. But in this case, the symbol worked well when I put the em value in both the CSS and the HTML -- no matter the ePub reader, whether it reads CSS or not, this works (at least in the few options I have to test; the author is testing on her boyfriend's Mac). And it's only the one symbol. Your Greek issue is a whole other can of worms. Yikes.

[Tex2002ans]

Originally Posted by eggheadbooks1

But in this case, the symbol worked well when I put the em value in both the CSS and the HTML -- no matter the ePub reader, whether it reads CSS or not, this works (at least in the few options I have to test; the author is testing on her boyfriend's Mac).

I created a Music Notes v2 EPUB (attached).

It includes a few more test cases:

• No Embedded Font
• Embedded Font
• Transparent GIFs
  
  • I generated all 4 Musical Notes at 300px height using Inkscape.
• Transparent PNGs
  
  • In the long ago past, KindleGen converted PNG alphas -> black background.
    
  • Also, depending on how the PNGs were optimized, I ran across KindleGen outputting a giant black box. Who knows what regressions could potentially be introduced in later versions, so I like to test stuff like this every so often.
• GIFs (White Background)
• PNGs (White Background)

Night Mode

So, I open up my book. White background black text, who could read any other way?



My book looks PERFECT!

It is getting a little late and the white is starting to blind me. Let me flick on Night Mode:



Oh crap, where did those musical notes go? Well let me go to the non-transparent version:



Woof, I can't even tell what those notes are. Now let me just swap over to the Embedded Font:



Beautiful!

Colors, Colors, and More Colors

Now, forgive me ahead of time for these abominations, but I wanted to show how it would look if a reader picked a Green background + Red text:



I love to read in Red text, but those stupid musical notes are ruining my perfect look! As you can see, the Transparent/Non-Transparent Images have some serious mismatches.

One of the things you have to keep in mind when you create these ebooks is that people will be reading on all different types of settings, and you should make sure your book does great in most/all of these situations. Night Mode and Color are two of the most used settings (on non-e-ink devices).

Originally Posted by eggheadbooks1

And it's only the one symbol.

One symbol? One symbol? The entire fate of the world is in the balance here!

Originally Posted by eggheadbooks1

And it's only the one symbol. Your Greek issue is a whole other can of worms. Yikes.

The same issues still apply (Text-to-Speech problems, Search problems, Font Color problems, [...]), only different in scale.

[eggheadbooks1]

Tex,

In the iBooks Asset Guide, it states that, for fixed layout books, one must specify an embedded font:

ibooks:specified-fonts
Example:

<meta property="ibooks:specified-fonts">true</meta>

Must be defined if your book contains embedded fonts. This is equivalent to specified-fonts : true|false in EPUB 2.

Does this apply to regular, flowing ebooks? Or do I just need to add the font and the relevant CSS for the Apple-specific ePub?

[eggheadbooks1]

Back when I started this thread, I used a Unicode character in the Kindle book in order to solve the problem of the musical symbol in the Kindle version of the book (as per Doitsu's suggestion).

Today I was going through the Kindle Publishing Guidelines again and Amazon write: "Do NOT use Unicode format characters, as they may cause problems."

This, even though they also write: "The source of a Kindle book can be encoded in many different ways. All encodings are supported, provided that: The encoding of the HTML files is clearly stated in the HTML [and ] The computer used for compiling the sources supports the encoding and knows how to convert it to Unicode."

So if the encoding is Unicode, and when tested the Kindle devices and apps display Unicode characters, why would Amazon "forbid" Unicode characters?

What am I missing?

[Doitsu]

Originally Posted by eggheadbooks1

So if the encoding is Unicode, and when tested the Kindle devices and apps display Unicode characters, why would Amazon "forbid" Unicode characters?

"Unicode format characters" most likely refers to Unicode control characters, in particular bi-directional text control characters.

[Tex2002ans]

Originally Posted by eggheadbooks1

Today I was going through the Kindle Publishing Guidelines again and Amazon write: "Do NOT use Unicode format characters, as they may cause problems."

That part is ABYSMALLY written. It was talking about different Unicode SPACES besides Non-Breaking Space + Zero-Width Non-Joiner:

Originally Posted by AmazonPublishingGuidelines2016.1

The only supported spaces are the normal space, the non-breaking space (&nbsp;), and the zero-width non-joiner (&zwnj;). Use of any other space can break the selection, dictionary lookup, and line-wrap algorithms.

Do NOT use Unicode format characters, as they may cause problems.

There are a ton of different spaces in Unicode:

U+0020 SPACE
U+00A0 NO-BREAK SPACE
U+1680 OGHAM SPACE MARK
U+180E MONGOLIAN VOWEL SEPARATOR
U+2000 EN QUAD
U+2001 EM QUAD
U+2002 EN SPACE
U+2003 EM SPACE
U+2004 THREE-PER-EM SPACE
U+2005 FOUR-PER-EM SPACE
U+2006 SIX-PER-EM SPACE
U+2007 FIGURE SPACE
U+2008 PUNCTUATION SPACE
U+2009 THIN SPACE
U+200A HAIR SPACE
U+200B ZERO WIDTH SPACE
U+202F NARROW NO-BREAK SPACE
U+205F MEDIUM MATHEMATICAL SPACE
U+3000 IDEOGRAPHIC SPACE
U+FEFF ZERO WIDTH NO-BREAK SPACE

Just stick with the two mentioned above (Non-Breaking Space + Zero-Width Non-Joiner) and you will be fine.

Side Note: Besides those two, the only other space that is commonly used would be the Thin Space, and that is used in languages like French (around punctuation marks like guillemets « » + colons, etc. etc.). To be more compatible, you can swap Thin Spaces <-> Non-Breaking Spaces (not as typographically pleasing though)... although I don't believe I have seen any problems with thin spaces on Kindles.

Originally Posted by eggheadbooks1

This, even though they also write: "The source of a Kindle book can be encoded in many different ways. All encodings are supported, provided that: The encoding of the HTML files is clearly stated in the HTML [and ] The computer used for compiling the sources supports the encoding and knows how to convert it to Unicode."

Again, seems to me like this is some horrid writing.

From what I could tell by looking at previous guidelines (2014.3), there used to be two separate subsections:

• Other Encoding Are Supported
  
  • Talked about using UTF-8 OR other encodings (why you would use non-UTF-8 in this day and age, I have no clue).
• Spaces and Unicode Characters
  
  • This just discussed the &nbsp; + &zwnj; + gave the same warning about Unicode characters.

Somewhere along the line, they merged both and added in the line: "XML entities are strictly required for "<" (&lt;), ">" (&gt;), and "&" (&amp;).".

Their previous version seemed to make a lot more sense in my mind. Merging them together just created some needless confusion.

Originally Posted by eggheadbooks1

So if the encoding is Unicode, and when tested the Kindle devices and apps display Unicode characters, why would Amazon "forbid" Unicode characters?

Just use the Unicode characters, and avoid using all those rarer spaces. Problem solved. :P

[Notjohn]

I can use the Unicode thin space?

Will an epub containing the thin space cause any problems outside the Kindle universe?

[eggheadbooks1]

Again, seems to me like this is some horrid writing.

From what I could tell by looking at previous guidelines (2014.3), there used to be two separate subsections:
Other Encoding Are Supported
Talked about using UTF-8 OR other encodings (why you would use non-UTF-8 in this day and age, I have no clue).
Spaces and Unicode Characters
This just discussed the &nbsp; + &zwnj; + gave the same warning about Unicode characters.

Somewhere along the line, they merged both and added in the line: "XML entities are strictly required for "<" (&lt, ">" (&gt, and "&" (&amp.".

Their previous version seemed to make a lot more sense in my mind. Merging them together just created some needless confusion.

Tex: Thanks for the clarification. I have noticed that the Kindle Guidelines and the website are indeed badly written. Which, as you noted, just creates needless confusion, particularly around us non-coders.

Another point to this issue: Amazon still promote the idea that Kindle books can only read Latin-1 (ISO-8859-1) characters. Yet after I learned here about using Unicode to create the musical symbol, I began experimenting more. I randomly chose 10 Unicode characters and tested them in both Previewer and my Kindle Fire device. In Previewer all the characters display correctly except for the older Kindle DX, which could only display 3 of the 10 characters. My Fire displays all fine.

So why would Amazon not want to promote the use of Unicode, seeing as it solves a number of issues? If they promote KF8 formatting, which the DX also cannot read, why not promote Unicode too?

Last question (she says): when exporting to HTML from Word, should we now select UTF-8 encoding or leave it as the default Windows-1252, before importing into Sigil? And does it make a difference if PC or Mac?

I ask because on the KDP website is written: "If you are experiencing conversion failures when trying to upload HTML content, please open the HTML file in Notepad and save it with "Encoding: ANSI" (this is an option in the 'Save As' Notepad dialog). On non-Windows platforms, make sure to save it as ANSI or ASCII, avoiding 'UTF-8' or 'Unicode' as the encoding type."

I'm wondering if that is restricted to Mac and/or restricted to the auto-conversion from HTML to mobi, or if it affects Sigil ePub-to-mobi conversions. When I look at my early Sigil ebooks, built from a Word-to-HTML file, the charset is Windows-1252 but the encoding is of course UTF-8. (I have never experienced an issue in my ebooks but wondering if I just got lucky.)

It also doesn't makes sense to me to tell users to avoid UTF-8, especially as in the Publishing Guidelines (Section 6.6) Amazon give as an example UTF-8 coding. So is the above issue a Mac or Linux (or other non-Windows platform) thing?

[DaleDe]

I think Amazon continues to worry about fall-back solutions for older products, which is why they discourage UTF-8.

Dale

[Tex2002ans]

Originally Posted by Notjohn

I can use the Unicode thin space?

Will an epub containing the thin space cause any problems outside the Kindle universe?

Many fonts do not have the Thin Space. It would most likely show up as �. For example, on my Nook, only 1 of the fonts has it (I don't have a Kobo on hand right this second to test).

As DaleDe mentioned, they most likely say to avoid those rarer spaces to be FULLY compatible with older Kindles/firmwares. I am not too sure of all of the fonts Kindles have/had available since the Kindle 1 + firmware 1.0.

Again, the more compatible substitution would be &thinsp; -> &nbsp;.

For example, in French:

<p>This is an example of a French quote&thinsp;:&thinsp;«&thinsp;Il est très beau&thinsp;!&thinsp;»</p>

This is a perfectly valid substitute:

<p>This is an example of a French quote&nbsp;:&nbsp;«&nbsp;Il est très beau&nbsp;!&nbsp;»</p>

In English, the Thin Space is rarely used. Notjohn, what is the use case where you were thinking of using a Thin Space? I can only think of a handful off the top of my head, and all can be handled fine with Kerning/Normal Space/Non-Breaking Space.

Originally Posted by eggheadbooks1

Amazon still promote the idea that Kindle books can only read Latin-1 (ISO-8859-1) characters.

May I ask where you saw this?

I don't recall ever seeing anything about that in the Amazon Kindle Publishing Guidelines:

https://kindlegen.s3.amazonaws.com/A...Guidelines.pdf

MAYBE that was just a troubleshooting step if you were doing some horrible Word -> Kindle conversion. Who knows what madness some WYSIWIG editor like Word might introduce. I have seen some really scary files, and I just shudder to think what kind of horrors Amazon has seen.

Side Note: I bet as Amazon/Kindles expanded internationally they made sure to expand the characters included in their default fonts (via firmware updates). I mean, it would be preposterous selling Russian ebooks without Cyrillic characters.

Originally Posted by eggheadbooks1

When I look at my early Sigil ebooks, built from a Word-to-HTML file, the charset is Windows-1252 but the encoding is of course UTF-8. (I have never experienced an issue in my ebooks but wondering if I just got lucky.)

To be a valid EPUB, HTML files must be UTF-8 or UTF-16. Calibre/Sigil already makes files UTF-8 on import.