The Problem with Text Rendering in Modern Software and Browsers

adamwhite

I tested Google Chrome, Mozilla Firefox, Microsoft Word, Adobe Illustrator, Adobe Photoshop, and Adobe InDesign.

All except InDesign fail the test.

Only InDesign provides correct parameters in relation to the em square, such as before and after margins and others. All others calculate these parameters from the edge of the selection caret. It's a really annoying problem that makes all dimensions meaningless. The em square outline as a distance-from-object parameter is already quite meaningless, but in this case, the absurdity reaches another level.

Microsoft Word has the worst text presentation, where I just got lost trying to figure out in what cra**y way it is rendering the text on the page.

The necessity for custom rendering layout solutions online and for desktop document creation is obvious. It's 2024, and you must either use DTP software or just handwrite the text if you want any logical, valuable dimensioning. All other solutions are meaningless. Your custom parameters mean nothing except "it's close to...".

Kunst X will try to resolve this problem with custom solutions on a smaller scale, but "one-man bands" don't get to play big gigs if the audience is not interested!

John Hudson

Most software uses font vertical metrics settings in the OS/2 or hhea tables to determine linespacing and distance from top of text frame, and most software offers users only fairly crude ways to change how those things are applied. DTP software like InDesign is, as you observe, different in this respect in using explicit leading values for linespacing and providing options for how to set text frame alignment. That’s because DTP software aims to provide precise control over page layout, down to fractional unit measurements. Other software does not aim to do this, so calling out its failure to do so isn’t really relevant: it uses a different paradigm than DTP. This paradigm applies a combination of metrics in individual fonts—which are not standardised and may vary considerably to reflect the use of vertical space in the glyph design or as appropriate to a particular script—and linespacing values often expressed as a multiplier of those metrics. That paradigm is based on the idea of being able to present a reasonable default for laying out arbitrary fonts in a way that ensures they are readable (presuming font metrics have been set appropriately). It isn’t aiming to provide precise page layout control to the user, for whom DTP software is available if that is what they need. Programs like Word are the digital equivalent of a typewriter: the expectation is that the user just opens a document and starts typing and does not need to set up any options for things like linespacing.

Now, there are indeed specific problems within that paradigm, which are due to a set of unfortunate historical decisions, duplicated data types, and, ultimately, to the lack of any agreed standard between software makers for how to interpret and apply font metrics.

Your custom parameters mean nothing except "it's close to...".

In the context of browsers, that is actually by design, because of a) rounding of absolute units as rendered to various resolution devices, and b) the centrality to CSS of the px unit, which is deliberately not an absolute measurement.

From the W3C:

The px unit is the magic unit of CSS. It is not related to the current font and usually not related to physical centimeters or inches either. The px unit is defined to be small but visible, and such that a horizontal 1px wide line can be displayed with sharp edges (no anti-aliasing). What is sharp, small and visible depends on the device and the way it is used: do you hold it close to your eyes, like a mobile phone, at arms length, like a computer monitor, or somewhere in between, like an e-book reader? The px is thus not defined as a constant length, but as something that depends on the type of device and its typical use.

This means that different device and rendering system makers translate px in different ways, depending on their target environments, backwards compatibility goals, and other factors. So it is indeed the case that physical text size and layout on websites can vary across different browsers, operating systems, and devices. It is that way intentionally, and ‘close to’ is actually the target.

Nick Shinn

Wordpress is bizarre, especially the way that line spacing changes drastically according to the width of the window.
I had to make special versions of my fonts (with re-engineered vertical metrics) to accommodate this, and design the typography of my web site around WP’s limitations, using one of the fonts only in all-caps. (Rather like some of the old metal fonts where certain glyphs, e.g. big figures, were not cast on the usual baseline.)

A huge problem is that one site layout design has to work in both portrait and landscape formats. It would be great if web site designers could create different layouts for each.

A central, and very broad issue, is that rendering software attempts to think for the user to “improve” their experience, rather than just do what it’s told. This patronizing paradigm sucks.  

In typography, it goes back decades to Word adding 20% line space, and making curly quotes where there are none in the text.

Autocorrect is the default—that sums it up.

John Hudson

Hi Nick. The Wordpress behaviours you describe are most likely in the CSS of whatever theme is being used, rather than being WP per se. You can edit the CSS if you don’t like the behaviour, or you can use a different theme.

A huge problem is that one site layout design has to work in both portrait and landscape formats. It would be great if web site designers could create different layouts for each.

They can. CSS provides for a lot of conditional control, in terms not only of text layout but of where various page elements are arranged in portrait vs landscape mode or in desktop vs mobile. A very common case is moving menu items around or collapsing them.

Thomas Phinney

Nick Shinn said:

In typography, it goes back decades to Word adding 20% line space

The thing about Word is that it makes the basic “single spacing” vary between fonts. IMO, the 20% isn’t the problem — InDesign and other pro design apps do that as well. The fact that Word needs to be inconsistent about what it is even adding 20% to, at any given point size, between fonts... that is irksome.

adamwhite

the expectation is that the user just opens a document and starts typing and does not need to set up any options for things like linespacing.

If that was the case then the problem would be less relevant, but actually Word is setup with almost all advanced controls as InDesign, but doesn't provide acurate results. It does offer options for line spacing and all other details. For an example why do they even have margins after paragraph options with exact pt or px values when it doesn't provide specific relations?

If it were like you described it, than aproximate relations wouldn't be such a problem.

In regards to px web rendering, there is no situation where em square px would be rendered diferently then it's relations, so the problem is the same. You can specify em sizes or percents without thinking about the pixels, but if it would render correct relations than it would be a different story.

Only solution I didn't test is LaTeX and other TeX solutions. I believe they present text properly, I will check.

John Hudson

Word is an example of a long-lived program that has, at the same time, far outstripped its original functionality and also burdened itself with a massive amount of backwards compatibility commitments. So yes, it has a lot of text layout control options, but all built on top of a paradigm in which a lot of things are derived from font metrics and in which many, many users never engage with those layout options but either use the defaults of predefined styles.

Ray Larabie

And the loss of Clippy was tragic.

John Butler

LibreOffice Writer is free and lets me use true small caps, which Word still does not do. Word’s OpenType implementation has been half-baked for over a decade.

I use Scribus when I want more precision, and I use Writer when I’m feeling lazy.

adamwhite

I forgot to include Corel Draw in my research. I never prefered it but if it comes up as optimal with text display I will switch to it from Illustrator.

There are other solutions like TeX, LaTeX, LuaTeX and all TeX based processors, Asciidoctor; Php, Python and C based PostScript and PDF generators. That would be the best way or to create custom text processing software in C, C++ or what ever stack to control everything from the base. I am starting with that aproach but it's a shame on development industry in 2024. to provide such lame solutions.

John Butler

I had completely forgotten about SILE and pagebot. SILE appears to continue in active development. Not so sure about pagebot. Dig Simon’s demo of justification alternates in SILE in this thread.

John Butler

Also dig LyX, the most refined bridge I can think of between 1990s WYSIWYG word processing style and programmed layout, though still encrufted with TeX barnacles. I’d love to see a LyX with SILE foundations instead of TeX.

John Savard

I can't tell from this thread if Scribus, a free DTP application, succeeds where other programs fail in the same fashion as InDesign. My temptation, though, when I see discussions like this is to claim that the TrueType specification is a failure because it wasn't designed to make digital typefaces behave enough like metal type so that it would be natural for any application using proportionally-spaced type (i.e. even Microsoft Word, or even Microsoft WordPad) to behave in ways relatable to the setting of metal type.

That, though, is probably a silly way of thinking on my part, given that digital type has a great deal of flexibility that metal type didn't, and one doesn't want to just throw all that away.

adamwhite

Corel didn't pass the test but Adobe FrameMaker did, which is probably the best solution so far. I forgot about it but did remember some days ago.

Simon Cozens

John Butler said:

I had completely forgotten about SILE and pagebot. SILE appears to continue in active development. Not so sure about pagebot. Dig Simon’s demo of justification alternates in SILE in this thread.

If the question is "how do you dispose the leading", I got so fed up with there being so many right answers to this question, I made SILE support all of them.