Image sizeing no longer working on some platforms?

[JSWolf]

Originally Posted by Jellby

No, because a CSS px is an absolute unit equal to 1/96 inch. It is not a screen pixel.

Another thing, of course, is whether the reading application knows this and complies with it, but that's the realm of bugs and quirks.

% would be better because you can make that fit the screen regardless of the screen.

[Jellby]

Originally Posted by JSWolf

% would be better because you can make that fit the screen regardless of the screen.

But % refers to the width/height of the containing block, which may not be what you want (e.g., the height is usually unknown/undefined, the width depends on the margins).

[Quoth]

Originally Posted by Jellby

No, because a CSS px is an absolute unit equal to 1/96 inch. It is not a screen pixel.

Only guaranteed on paper.
1) A CSS px in a web page on a screen in a browser is a magic unit. The behaviour is variable. It's only absolutely always 1/96″ on print to paper. The spec also changed maybe 2011.

2) As ever with ALL HTML and CSS an ebook isn't a web page and doesn't work quite the same. It's a little like web to screen and a little like web to paper (which paginates).

A px specified image won't scale as font is changed. It may or may not be ereader or screen physical pixels 1:1, or an exact integer multiple. The Kindle PW3 KF8 doesn't do them the same as most epub eink, or other some other Kindles.

The 1em = 12pt should apply on ereaders, but for paper or some web browsers 1em might not be 12pt. It is on KF8 (azw3), mobi (KF7), KFX and epub, but horizontal margins on kepub don't use 12pt=1em (I forget what it is). PDFs should use inches or cm.

Normally all text, margins and padding should used em, though for all except kepub, using pt (12pt = 1em) will work, which is handy as wordprocessor styles don't use em.

Images should normally be correct H & V px, except when you want it always the same % of screen, when you set either V to % (large portrait images) or H to % (large landscape images). The image % will use the screen height or width if the only enclosing scope is a <p class="cntp"> where the css is as below. The othe size property should be auto.
Never auto on margins.

.cntp{
// add font face
// add font size
margin-bottom: 3pt; //For landscape if using same class for caption or zero otherwise
margin-left: 0;
margin-right: 0;
margin-top: 0;
padding-bottom: 0;
padding-left: 0;
padding-right: 0;
padding-top: 0;
text-align: center;
text-indent: 0
}
Optionally add a font for a caption

The same enclosing p can be used for specific sized images that are centred.

I've not tried that with a heading, but h2 should work instead of p if a suitable font size and face is specified.

Note this page on CSS only applies to Webpages and web browsers.
https://www.w3.org/Style/Examples/007/units.en.html
The epub2, epub3, kepub, mobi/KF7 (only inline, no CSS), KF8 (azw3) and KFX are NOT web pages rendered by a browser, though much w3 org stuff does work, plenty doesn't or behaves differently.
For example never use rem or px for fonts on ebooks and mostly 12pt is 1em and relative on ereaders, so that user font size change works (browsers can zoom in / out but not the same way as ebook views)

Apps on Android may ignore much CSS or mangle it.

[JSWolf]

I thought 1em = 16pt.

[Jellby]

Originally Posted by Quoth

The 1em = 12pt should apply on ereaders

Originally Posted by JSWolf

I thought 1em = 16pt.

What? Did I miss something?

I know the stuff with px is confusing, device-dependent and CSS-version-dependent. But I thought em and pt were well-defined and in two different worlds.

1 em is a font measure. You can think of it as "the width of the letter M" (although that's most of the time not exact). Change the font size and the size of the em changes, but will keep the relative proportions with the characters.

1 pt is a fixed absolute unit of measure, like mm and in, and it is always 1/96 in or ~0.3528 mm (https://en.wikipedia.org/wiki/Point_(typography)). Regarless of the font size.

What you can have is that by default a given reading application chooses to have fonts sized such that 1em = 12pt, but that can be changed by user and the book's formatting. If I choose my fonts to be sized at 10.5, then 1em = 10.5pt, and if there is a title sized at 200%, then inside that title 1em = 21pt, and a superscript set to 80% will be 1em = 8.4pt (or 16.8pt inside the title). And if I change the font and feel that it's too small and increase the default font to size 13, then 1em = 13pt.

[Quoth]

Originally Posted by Jellby

What? Did I miss something?

1 pt is a fixed absolute unit of measure, like mm and in, and it is always 1/96 in or ~0.3528 mm (https://en.wikipedia.org/wiki/Point_(typography)). Regarless of the font size.
.

No, that's web pages and maybe even only paper. Also not even exactly true on paper, two different font family/faces at same pt size can be wildly different in size. The 1/96 in = 1pt will only 100% apply to word proccessor or PDF print to paper and only for dimensions of everything not actually a font. For clarity all non-font dimensions used in documents for paper or PDF should use inchs or mm.

Almost all ereader platforms use 12pt = 1 em (which only really matters on indent, margins and padding as all the fonts will be relative and scaled by user, those scale with font too.). The only common exception is things like first line indent on kepub, not sure what else is odd on kepub, but the obvious difference on first line indent on kepub vs epub and kindle vanishes if em rather than pt is used.

Wikipedia articles on typography tend to paper or web (esp CSS & HTML) and are not always accurate for those.

While ebooks use HTML, and unless old mobi, also CSS they are not web pages rendered by regular browsers. Even the regular browsers may have user changeable settings for scaling css to real pixels.

Experiment. You will find web pages in a browser vs ebook are not using the same rules on the common platforms (some Android apps simply ignore som or all of CSS or inline styles anyway).

Also look at kf7/old mobi, KF8/azw3, ADE, epub2 and epub3 specs vs current web pages and browsers. The ebooks are a subset and because of easy user font slider, margins, line spacing etc and pagination some stuff would be crazy to work the same way on ebooks as web.

Also only PDFs absolutely use absolute sizes. Web pages only mostly do when printed to paper, but a web page might have separate screen and paper CSS. Also "responsive" websites mostly work differently to an ebook reflowing to app/program window or physical screen size.

[nabsltd]

Originally Posted by Jellby

1 em is a font measure. You can think of it as "the width of the letter M" (although that's most of the time not exact).

For horizontal measurement, 1em always equals the width of the "m" in the current font at the current font size. You can see this is true by using a hanging indent of 1em and start the paragraph with "m".

For vertical measurement, 1em always equals "the height of the current font at the current font size". This creates a bit of chicken and egg because at some point the "current font size" needs to have an initial value. This is supplied by the renderer, and most default to 16px. As we know, "px" is a flexible unit, so this isn't the same on all devices.

Note that a margin-top of 1em will create a space above the element that is less than the height of a line of text. Text lines have a line-height property, with the default being the recommended line spacing metric that is stored inside the font file.