Lock Fonts in eReaders

[Ken_Moorhead]

Hello;

I am not sure this is the correct forum, but I am looking to see if something is possible. If this needs to be moved, please let me know!

Let me start from the beginning: I've written a novel and I am in the process of sending it off to my beta-readers as an epub. Using a combination of LibreOffice, Calibre and Sigil I have a very polished epub v2. It looks perfect in all the devices/apps my beta readers asked for, and a few random others I tried along the way.

But, there are a few passages that use fonts to convey things to the reader. Provided the users don't muck with my settings/fonts/defaults it's all good. However, if you change the font on the device itself, those passages follow suit and lose their formatting. It's not the end of the world, but it annoys me.

That brings me to my question. At this juncture I should point out that I am very new to this and working our CSS/X-HTML as I go. I understand it, but a guru I am not.

So...

Is there a way to force a block of text to use the specified (embedded) font no matter what the user does? This would preserve my styling, and the desired effect.

It would also preserve my pretty section breaks.

I've read something to the effect that you can do this with clever use of the <div> tag, but have so far failed to make it stick.

Is this even possible? Or am I resigned accepting that it can not be nailed to a wall?

TIA;

Ken

[JSWolf]

Do you know what device each person is using to read with?

Different devices have different ways of doing things.

A Kindle needs to have the Publisher Font selected.
A Kobo just works.
Apple Books needs a file called com.apple.ibooks.display-options.xml in META-INF directory of the ePub containing the following text.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<display_options>
<platform name="*">
<option name="specified-fonts">true</option>
</platform>
</display_options>

For Apple Books, this is something you have to do before you send out the ePub. But you should just do it for everybody as it won't cause any issues for anyone not using Apple Books.

I'm mentioning this because the only way to do it is to send a note to each person telling them what needs to be done to get the ePub to display as you'd like with their device. There is no way to lock embedded fonts as you want.

Question, before you send your ePub to everyone, what is the embedded font you are using? The reason I ask is that a lot of embedded fonts do not look good on an eInk display (such as Kindle and Kobo) because they are too thin (need more weight).

[kovidgoyal]

You cannot force reading software to use embedded fonts. There will always be reading software that will override your choices in favor of the reading person's preferences. The closest you can get is using an image for the text.

[JSWolf]

And if an image is used instead of text, it will not be a pleasant reading experience.

[Quoth]

I test Kindle azw3 and kobo epub on default settings and also test KF7/oldMobi on an old Kindle to make sure any new style degrades OK with limited font support.

You can only assume
Faces: Serif, Sans and Monospace.
Styles: Normal, italic, bold and bold-italic (some old readers just use the normal font in oblique rendering to do italic, like Sony LRF).
Sizes: as desired, but not all fractional sizes are exact.

A box around a paragraph will work, but maybe corner radius will default to a right angle.

Ensure each page break is a new internal HTML, or there may be no page break.

If a letter, telegram, TV caption, note, sign, quotation blocks, epigram etc "needs" a different font insure the margins (left, right, top, bottom), padding, size and basic style/face (as above) differentiate from the body text.

Only use one body font. Never a different face per character or similar trick. Been tried 100s of years ago and painful to read. Use good action & speech tags and context and character's "voice". See Pratchett's Witches Abroad.

Also Amazon will strip excessive use of body fonts.

[JSWolf]

[QUOTE=Quoth;4331682]

You can only assume
Faces: Serif, Sans and Monospace.

You can't use monospace on a Kobo as it won't work without fixes that most won't be doing both on the Kobo and with the eBook. You are best to embed a monospace font if you need such and expect this to possibly be read on a Kobo.

[Calenorn]

It may be that the art of arranging a printed page cannot transfer to ereaders. Trying to preserve section breaks, when different readers have screens of different sizes and shapes? Trying to control the font, when readers need to change the size because of vision problems, or to change the font because of dyslexia?

Think of it this way: can an audio recording control the user's bass and treble levels? Can a video control the user's color balance or brightness settings?

[Ken_Moorhead]

Thank you everyone!

In short, this is NOT possible. And I am resigned accepting that it can not be nailed to a wall!

I can do that! I'm just used to the printed page and hoped, maybe, just maybe, that I could replicate it authentically. It was worth a try!

[Martinoptic]

Print replication in my view can only be achieved either by an image or pdf.

[Quoth]

Originally Posted by JSWolf

You can't use monospace on a Kobo as it won't work without fixes that most won't be doing both on the Kobo and with the eBook. You are best to embed a monospace font if you need such and expect this to possibly be read on a Kobo.

A kobo is least problematic of all apps and ereaders. Mobi is worst.

[JSWolf]

Originally Posted by Quoth

A kobo is least problematic of all apps and ereaders. Mobi is worst.

A Kobo is problematic if the ePub is using monospace. Kobo won't support it without an embedded monospace font or the other workarounds that most people won't be doing.

[Ken_Moorhead]

I'm going to tack this on this thread mostly for feedback, that is, why what I stumbled across is wrong

I was playing with the e-readers at my disposal, all of them apps really, just to see what changing the font did. Then I could adjust the CSS accordingly and find a different way to highlight what I was highlighting with fonts.

Then I noticed that while the body font face changed, the header font face did not change. However, color and size adjusted as expected. This worked in the Nook app, the current Kindle app as AZW3 for Mac OS (iOS to be tested later today), All variants of Apple Books I can lay hands on, and the Pocket Books app.

After some digging I discovered that tags h1... h6 were ignored when the font changes.

So, of course I set about trying to use this to protect my font.

And it sort of worked.

I gave up on the text body protection since h1 thru h6 are intended to be single line animals and technically paragraphs as children of headers is a no-no. I could fake it with old school breaks but that looked worse and seemed too hacky for the real world.

But, this trick was very useful for the section break glyph. I have an unhealthy aversion to the three asterisk business, it's ugly.

If I wrap up like so:

<h4 class="p-section_20_break">
P
</h4>

Where p-section_20_break defines the font, weigh, and alignment, I get a protected glyph that is ignored when the readers (at least the ones I have tried) change the font. But changes to color and size execute nicely. All in all it seems to work. For the purposes of my beta-readers it suffices since I know what devices are in play.

I have no doubt this is NOT a real world fix. There has got to be an e-reader out there that changes the headers too.

But, my question is three fold:

1. Why does this even work?
2. Is there any way of knowing which readers ignore h1...h6 or is it just dumb luck?
3. Once the TOC written, do headers, as intended, ever matter any more? Or is it just an artifact of how Calibre got from ODT to ePub?

The book goes out to the first betas this weekend, so the time for mucking with it is over. At this point it is just curiosity.

Thanks!

Ken

[Quoth]

Also save edits as odt but EXTRA Save As in docx to add to Calibre to convert to epub.
Works better.

The Calibre docx import is more often updated.

Don't reload the docx to LO Writer, as that converts it always, only edit odt, even if first version arrived as a docx.

Different ereaders & apps treat headers differently, but indeed you can make it look the same with NO headers, just <p and classes.

Many apps and ereaders have a limit to levels possible esp in TOC. A max of 3 is good.

Apps are not like real ereaders.

Section breaks can be just by a larger margin etc of a first breaking paragraph with no first line indent. They don't need a fleuron or character(s), but if used then that has its own WP style and CSS.

body text should always use <p

<h only for headings, but only needed for ancient renderers that ignore css
You can build a TOC automatically in Calibre from docx using various methods other than <h tags.

[Quoth]

Originally Posted by Ken_Moorhead

I
2: Is there any way of knowing which readers ignore h1...h6 or is it just dumb luck?
3: Once the TOC written, do headers, as intended, ever matter any more? Or is it just an artifact of how Calibre got from ODT to

2: It's worse than that. Some renderers will use builtin styles for H1 to h6.
Yes, some applications and ereaders only change the body font, others change face of all of them. Mobi is worst (Kindles older than KK3, or those and some later never upgraded FW).
Some apps mostly or entirely ignore CSS.
Some apps will not use embedded fonts at all, they will only use ones already on the phone/tablet or included in the app.

3: Really headers are just optionally used by Calibre to build a system TOC. There are other ways. You can exclude header levels from TOC building or use none for TOC. Headers historically (HTML3 and earlier) simply rendered larger or smaller bold text for headers. Some apps and ereaders ignore css and thus use header level to decide how to render.

[Ned]

I must admit I'm not keen on the author/publisher telling me what font to use - I prefer my own, and will edit any 'enforced' font rather than read in it.