CSS units for a Kindle image size

[robertosaenz]

Hello guys, I was looking for another thread about this topic but I could'n find any.

I'm working on my first kindle ebook. This book contains many equations. I want these to keep a font size relatively close to the font size chosen by the reader.

To achieve this, I had the equations rendered as images of a fixed size of 5 inches wide, with a font size of 15pt.

In my stylesheet I made the image 20em wide, which is an approximate to achieve the desired result.

My doubt comes from the fact that the measures in em are not supported in the first generations of Kindle; According to your experience, what could happen to those images during the conversion?

[Quoth]

Use px for smaller images and % for images that are in their own paragraph.
Works on old mobi, azw3, kfx and all epub.
em is for fonts, margins and padding. Usually 12pt is exactly 1em and pt works fine for fonts and mostly for margins and padding (some epub renderers seem to use 10pt = 1em for margins/indents, but respect 12pt -1 em for fonts)

Oddly PW3 can be a bit strange on images, but that should be OK there.
Kindle screens are 4:3 approximately and 6″ are 167 dpi or 300 dpi. The 9.7″ screens are 150 dpi and all larger than 6″ on Kindle are 300 dpi. Hence % may work best vs page size, but for smaller images big enough to easily read at 300 dpi, the absolute px size works.
Only one axis should be a %, if used and other set to auto. Enclose in a centred <p ..... </p> paragraph to centre.

Upload epub2 to Amazon KDP, not doc or docx.

[robertosaenz]

Originally Posted by Quoth

Use px for smaller images and % for images that are in their own paragraph.
Works on old mobi, azw3, kfx and all epub.
em is for fonts, margins and padding. Usually 12pt is exactly 1em and pt works fine for fonts and mostly for margins and padding (some epub renderers seem to use 10pt = 1em for margins/indents, but respect 12pt -1 em for fonts)

Oddly PW3 can be a bit strange on images, but that should be OK there.
Kindle screens are 4:3 approximately and 6″ are 167 dpi or 300 dpi. The 9.7″ screens are 150 dpi and all larger than 6″ on Kindle are 300 dpi. Hence % may work best vs page size, but for smaller images big enough to easily read at 300 dpi, the absolute px size works.
Only one axis should be a %, if used and other set to auto. Enclose in a centred <p ..... </p> paragraph to centre.

Upload epub2 to Amazon KDP, not doc or docx.

Thank you for your answer, Quoth. About that, I have equations rendered as inline-block images, which I size to 1em in height, so they embed correctly in the paragraph.

The original size of these images is a little larger than the size indicated in the style sheet. What would happen to those images in the conversion from epub to kindle (in the case of old devices)? Would they stay as still images in their original size?

[Hitch]

Originally Posted by robertosaenz

Hello guys, I was looking for another thread about this topic but I could'n find any.

I'm working on my first kindle ebook. This book contains many equations. I want these to keep a font size relatively close to the font size chosen by the reader.

To achieve this, I had the equations rendered as images of a fixed size of 5 inches wide, with a font size of 15pt.

In my stylesheet I made the image 20em wide, which is an approximate to achieve the desired result.

My doubt comes from the fact that the measures in em are not supported in the first generations of Kindle; According to your experience, what could happen to those images during the conversion?

How is it that you anticipate this working with font resizing, generally, if I may ask? Font resizing/scaling, and image resizing, are done in two completely different ways and have no interlocking dependencies or...any way to tie one to the other. ???

Hitch

[Quoth]

Originally Posted by robertosaenz

Thank you for your answer, Quoth. About that, I have equations rendered as inline-block images, which I size to 1em in height, so they embed correctly in the paragraph.

It will fail when the reader (user) resizes the content as that only changes the font, as Hitch explained.

Images embedded in a line of text won't work. Text needs to be in prior and next paragraphs. Anchor images as character each in own paragraph, unless small, then several can be on one line.

Originally Posted by robertosaenz

The original size of these images is a little larger than the size indicated in the style sheet. What would happen to those images in the conversion from epub to kindle (in the case of old devices)? Would they stay as still images in their original size?

Depends how you have defined them. The Kindle screens are 150 dpi (9.7″) or 167dpi (6″) for old devices. Later devices are 300 dpi for all size of screen. Absolute pixels and % behave differently. Before the Kindle Basic 2022 the Kindle 5 and Basic models (After Paperwhite) used the newer format but used a 6" 167 dpi screen. Later the KK3 and all later models except the DXG (really an upgraded DX that was before KK3) got FW updates to at least azw3. Much later models got also KFX.
If a Kindle has a Publisher option on Theme or Aa menu, then it can do azw3 (KF8, which is like epub2), otherwise it only does old mobi (KF7), the original 2007 Kindle format based on HTML3 with only inline styles and no separate CSS files or embedded fonts. KFX is more about delivery and encryption, maybe since PW2? It renders a bit differently to azw3 and different internals, but nothing that Amazon couldn't have updated azw3 to do as an option.

The eink isn't well suited for text books as the formats were designed for novels with some illustrations dropped in. Thus images never resize with resized text and are either absolute pixels or a % of width or height (never both, the other property must be set to auto).
Images embedded in text behave badly. Text flow with images is very non-portable code.

Hitch has great experience at this. I now avoid ebooks that need images like yours. Actual maths like LaTex or svg etc would be great but there is almost no support for it (especially none on Kindles).

So options are an App for iOS/Android/Fire or a fixed layout /PDF (almost no eink, needs 8″ or bigger screen).

[robertosaenz]

Originally Posted by Hitch

How is it that you anticipate this working with font resizing, generally, if I may ask? Font resizing/scaling, and image resizing, are done in two completely different ways and have no interlocking dependencies or...any way to tie one to the other. ???

Hitch

Well, with respect to the formulas that are in their own paragraph, I made a script to render formulas in Latex and place them on a 5 inches wide page, with a 15pt font size. They are small images because they are math expresions.

Then, in the html and css files, play around with the width and the max-width so that the image fonts have the same (or similar) proportion of the font size in the paragraphs. The max-width is in EM, and the width is 100%, in such a way that the letters and numbers in the image may appear smaller than those of the paragraphs (if the screen is very small) but they will never appear larger than the font size in the paragraphs.

I didn't know if that would work, but that's what I was thinking of doing.

[Hitch]

Originally Posted by robertosaenz

Well, with respect to the formulas that are in their own paragraph, I made a script to render formulas in Latex and place them on a 5 inches wide page, with a 15pt font size. They are small images because they are math expresions.

Then, in the html and css files, play around with the width and the max-width so that the image fonts have the same (or similar) proportion of the font size in the paragraphs. The max-width is in EM, and the width is 100%, in such a way that the letters and numbers in the image may appear smaller than those of the paragraphs (if the screen is very small) but they will never appear larger than the font size in the paragraphs.

I didn't know if that would work, but that's what I was thinking of doing.

Roberto:

May I ask, do you have any actual Kindle devices? Have you tried rendering these into MOBI and then sideloading them and trying to see if what you think is going to happen, is what happens?

I have to tell you..we've done dozens of books, maybe scores, with math formulae and various scientific/thermodynamic notation, etc. (Out of slightly over 7,000 eBooks total, over the last decade-plus.)

For one thing, using points in eBooks doesn't work worth two s**ts. It simply doesn't. It freezes the size, irrespective of the actual text font size. That's one thing. Secondly, images--of ANY KIND--are sized based not upon ems, points or any of that, (n.b., I mean, not reliably!) but percentages of screen size, pretty much, period, end statement. How will that reconcile with your thinking around a "5" wide page with 15-point font size" and what bearing does that have, those numbers, on "font size 4" in a Kindle Voyage, let's say?

You keep saying that you're going to "...play around with the width and the max-width so that the image fonts have the same (or similar) proportion of the font size in the paragraphs. The max-width is in EM, and the width is 100%, in such a way that the letters and numbers in the image may appear smaller than those of the paragraphs (if the screen is very small) but they will never appear larger than the font size in the paragraphs," but of course, the formulae may appear larger. They may appear smaller. It's a...it's nightmare of juggling and testing and playing and all that, trying to make it work even remotely closely. And then what happens in the LookInside, and KCR (Kindle Cloud Reader), both of which are basically KF7 "devices" or readers, which will promptly ignore almost everything?

I know, I know, I sound like Dora Doom here and that's not my intention, but you need to realize that the best you're going to do is get close. It's not going to be like print and LaTEX. It's really not.

Okay? Listen...if you find some magic way to make that crap work, go with God, contact me and I'll pay you for the coding. Seriously. But don't beat your brains out against the wall on it. I have bookmakers here at my office still wearing gauze around their own head-wounds, trying to make this sort of thing "perfect." We've done a lot fo them--and we've done a ton of painstaking coding, trust me, and in these instances, yes, perfect is the enemy of really quite good enough.

Hitch

[robertosaenz]

Originally Posted by Quoth

It will fail when the reader (user) resizes the content as that only changes the font, as Hitch explained.

Images embedded in a line of text won't work. Text needs to be in prior and next paragraphs. Anchor images as character each in own paragraph, unless small, then several can be on one line.


Depends how you have defined them. The Kindle screens are 150 dpi (9.7″) or 167dpi (6″) for old devices. Later devices are 300 dpi for all size of screen. Absolute pixels and % behave differently. Before the Kindle Basic 2022 the Kindle 5 and Basic models (After Paperwhite) used the newer format but used a 6" 167 dpi screen. Later the KK3 and all later models except the DXG (really an upgraded DX that was before KK3) got FW updates to at least azw3. Much later models got also KFX.
If a Kindle has a Publisher option on Theme or Aa menu, then it can do azw3 (KF8, which is like epub2), otherwise it only does old mobi (KF7), the original 2007 Kindle format based on HTML3 with only inline styles and no separate CSS files or embedded fonts. KFX is more about delivery and encryption, maybe since PW2? It renders a bit differently to azw3 and different internals, but nothing that Amazon couldn't have updated azw3 to do as an option.

The eink isn't well suited for text books as the formats were designed for novels with some illustrations dropped in. Thus images never resize with resized text and are either absolute pixels or a % of width or height (never both, the other property must be set to auto).
Images embedded in text behave badly. Text flow with images is very non-portable code.

Hitch has great experience at this. I now avoid ebooks that need images like yours. Actual maths like LaTex or svg etc would be great but there is almost no support for it (especially none on Kindles).

So options are an App for iOS/Android/Fire or a fixed layout /PDF (almost no eink, needs 8″ or bigger screen).

Well I guess that's very bad news for me. When you talk about an App, do you mean the kindle app? Will the settings I mentioned above work correctly in the app?

I take the opportunity to ask the following, let's say I forget about the idea of ​​publishing for kindle and I generate an epub2 file for other platforms, would my configurations with EM values ​​work correctly in this format?

[Quoth]

Originally Posted by robertosaenz

Well I guess that's very bad news for me. When you talk about an App, do you mean the kindle app? Will the settings I mentioned above work correctly in the app?

No, I mean a regular app. Those sell better on iOS Apple store and especially on Google's Playstore (which mysteriously fails to sell many books). Android apps can be installed on the Amazon Fire (which is not a Kindle). Amazon has a Fire app store too.
An app can use real re-scaleable maths equations and text. There are free frameworks, but unless you have experience, you'd need someone to build it from your docx files.

This kind of ebook is never going to work well on real eink Kindles other than the Scribe. All are too small for PDF version in an Amazon wrapper, and often Amazon won't sell fixed layout content to eink readers, only to their Fire and apps (where it is useless on a phone).

[Quoth]

Originally Posted by robertosaenz

I take the opportunity to ask the following, let's say I forget about the idea of ​​publishing for kindle and I generate an epub2 file for other platforms, would my configurations with EM values ​​work correctly in this format?

You'd want epub3 and svg, not images. Image based equations will work poorly on epub2 or epub3.
Eink ereaders only somewhat support svg or epub3, best support is a few Android ereader apps.

You can convert docx or laTex equations to svg so they are vectors and rescale on some platforms. Very few sadly.

This is an issue that could have been addressed a few years before the Kindle (2007) or possibly any eink (2005 Sony), but at the time PDAs and phones with small screens were the only platform and Mobipocket was the biggest seller. It was all ebooks of fiction/novels and the earliest Mobipocket on Wiindows CE, Symbian and PalmOS only did basic reflowable text (probably Latin/Roman only).

The early Kindles up to DXG only do a subset of Greek and otherwise only Latin/Roman. No Cyrillic, Arabic, Asian, Hebrew etc, even though that was a solved problem on underlying Linux OS more than 10 years earlier.

Ebooks work best for novels, with optionally some illustrations were size doesn't matter chucked in. The older Kindles only support Western European text. You need epubs or later Amazon Kindle azw3 for Cyrillic, Arabic, Asian, Hebrew etc. And even on later Kindles the user has to always manually select Publisher option (in Aa or Theme) for publisher embedded fonts.
Note many apps for epub ignore embedded fonts and so special characters for maths won't work. Good free epub Apps for Andriod do exist, but Android has no built in ereader app and people are attached to "broken" apps they install.

[robertosaenz]

Originally Posted by Hitch

Roberto:

May I ask, do you have any actual Kindle devices? Have you tried rendering these into MOBI and then sideloading them and trying to see if what you think is going to happen, is what happens?

I have to tell you..we've done dozens of books, maybe scores, with math formulae and various scientific/thermodynamic notation, etc. (Out of slightly over 7,000 eBooks total, over the last decade-plus.)

For one thing, using points in eBooks doesn't work worth two s**ts. It simply doesn't. It freezes the size, irrespective of the actual text font size. That's one thing. Secondly, images--of ANY KIND--are sized based not upon ems, points or any of that, (n.b., I mean, not reliably!) but percentages of screen size, pretty much, period, end statement. How will that reconcile with your thinking around a "5" wide page with 15-point font size" and what bearing does that have, those numbers, on "font size 4" in a Kindle Voyage, let's say?

You keep saying that you're going to "...play around with the width and the max-width so that the image fonts have the same (or similar) proportion of the font size in the paragraphs. The max-width is in EM, and the width is 100%, in such a way that the letters and numbers in the image may appear smaller than those of the paragraphs (if the screen is very small) but they will never appear larger than the font size in the paragraphs," but of course, the formulae may appear larger. They may appear smaller. It's a...it's nightmare of juggling and testing and playing and all that, trying to make it work even remotely closely. And then what happens in the LookInside, and KCR (Kindle Cloud Reader), both of which are basically KF7 "devices" or readers, which will promptly ignore almost everything?

I know, I know, I sound like Dora Doom here and that's not my intention, but you need to realize that the best you're going to do is get close. It's not going to be like print and LaTEX. It's really not.

Okay? Listen...if you find some magic way to make that crap work, go with God, contact me and I'll pay you for the coding. Seriously. But don't beat your brains out against the wall on it. I have bookmakers here at my office still wearing gauze around their own head-wounds, trying to make this sort of thing "perfect." We've done a lot fo them--and we've done a ton of painstaking coding, trust me, and in these instances, yes, perfect is the enemy of really quite good enough.

Hitch

I have a Paperwidth, but the truth is I haven't tested it yet. I have read several books that contain mathematical formulas (although very few) and they look relatively good on my device.

I suppose that an approximate solution (without being perfect) is the one you indicate, configuring the size of the images based on the percentage of the width of the screen.

If that were the case and I were to use Media Querys to better adapt that percentage based on the size of the screen, what would happen to the old kindles when they were converted by Amazon?

I ask this because you commented that the old kindles work with html3, and of course, there are no media queries here.

[Hitch]

Originally Posted by robertosaenz

I have a Paperwidth, but the truth is I haven't tested it yet. I have read several books that contain mathematical formulas (although very few) and they look relatively good on my device.

I suppose that an approximate solution (without being perfect) is the one you indicate, configuring the size of the images based on the percentage of the width of the screen.

If that were the case and I were to use Media Querys to better adapt that percentage based on the size of the screen, what would happen to the old kindles when they were converted by Amazon?

I ask this because you commented that the old kindles work with html3, and of course, there are no media queries here.

Well, I wish I had a great answer for you. If the older devices are converted, you have an excellent chance that the "new' format (or old format?) would simply start using the media queries in the 'new' format, say KF8 or whatever. That's my best guess.

Nobody knows what Amazon will do and on many days, I'm not sure that Amazon knows, either.

Hitch

[robertosaenz]

Thank you very much for your support. I am trying to convert two math books of about 300 pages each, I understand that it will be a complicated and frustrating task, that's why i didn't try it before.

Thanks to your help I decided to automatically render (with a script) each formula so that it generates 3 objects (for inline and block equations): a png image, a svg image, and a mathml object; this way I will be able to generate 3 different ebooks, the first of which will be for KDP.

I'm finishing the script this week, but you're seeing me on the forum quite often posting questions and progress.