Rendering issue where <var> abut {}[]()

[TallTed]

Originally posted by @TallTed in #110 (comment)

Now we have an example rendering issue —

In particular, note the collisions between t and ), and also (though to a lesser degree) between µ and ( and Ω and (.

The above is seen in Chrome Version 116.0.5845.187 (Official Build) (x86_64) on macOS Mojave version 10.14.6 (18G9323).

This would be resolved by my previous suggestion to add a space between all {}[]() and the non-whitespace characters they abut, or by (much more complicated) adding <i> tags to all {}[]() that abut a <var> or other character that is italicized for whatever reason.

[hartig]

Characters such as {} [] () should not be italicized in formulas.

[afs]

I have 118.0.5993.88/Ubuntu 23.10 with the "Advanced Font Settings" extension in Chrome : this is what I see (screen 3840x2160 at 200% on a 24" monitor).

---

It may be to do with the font hinting and kerning. Italic-plain is a tricky transition to typeset and hints are often not so great even on common fonts.

For what I get, the "t)" has kerning and is quite tight at the top but clear. The CSS font is "sans-serif", the generic choice, coming from W3C base.css. "sans-serif" is is "Open Sans" 400 on my machine. As the image shows, "Open Sans" is a quite light weight font and is not very narrow in style; The between "t" and ")" shows.

For the -> I'm getting in "?x->t" is pretty uck; the hyphen is low. That is font design.

An oddity is that I get "Menlo" for monospace from W3C base.css.

From the fragment showing, @TallTed seems to have some kind of courier/serif monospace font which is curious as base.css is setting it for me.

https://www.w3.org/StyleSheets/TR/2021/base.css

[TallTed]

If I'm reading things right, my Mac is rendering the PR-Preview sans-serif as Helvetica, and the monospace as Courier.

In my PR-Preview rendering, "t)" (where neither character is italic) is fine, but "t)" (where the t is italicized) is not.

You getting Menlo doesn't seem odd to me — it's the first monospace font asked for by base.css —

/** General monospace/pre rules ***********************************************/

	pre, code, samp {
		font-family: Menlo, Consolas, "DejaVu Sans Mono", Monaco, monospace;

I don't see any sans-serif list in base.css.

But I don't know why mine is falling back to generic monospace and delivering Courier, as I have all of Menlo, Consolas, and Monaco.

It's almost like consistent presentation on the web is a dark art!

[afs]

Helvetica

https://en.wikipedia.org/wiki/Helvetica -- "an unusually tight spacing between letters"

It's almost like consistent presentation on the web is a dark art!

s/It's almost like /C/ !!

[TallTed]

[@afs] https://en.wikipedia.org/wiki/Helvetica -- "an unusually tight spacing between letters"

Maybe so, but it's a widely used font, and one of the promises made by HTML is that browser users can choose their own preferred (fallback) fonts (settings link for Chrome is chrome://settings/fonts, which refuses to be rendered as a live, clickable link, even using <a> markup here, but you can copy and paste it) ... which weirdly includes proportional fonts in the monospace drop-down, monospace fonts in all the drop-downs, and blends both serif and sans-serif fonts into both of those drop-downs), which I apparently did at some point in the relatively distant past, as I have no recollection of doing so... (And there's no option to revert to defaults!)

That said, these settings are not generally expected to override fonts set via CSS.

Still, it's a partial explanation of why I get Courier and Helvetica, instead of Menlo and whatever-proportional-I-"should"-see.

[afs]

From looking at your image at 500%

it looks like the anti-aliasing combining with the resolution is a factor.

[TallTed]

Absurdly magnified via ⌘-+, I reveal a tiny separation between these ginormous characters. (Click to see the original image, rather than the 25% scaled one shown in this comment.)

It will not be readers' fault if these characters collide as they do for me.

Generating a PDF with embedded fonts, or making a collection of PNG images, are the only ways I know to guarantee content will display the same on all screens. As those are not viable for a W3C TR, I will again suggest inserting space characters between all {} [] () and their abutting non-whitespace characters.