Closed Bug 1704255 Opened 4 years ago Closed 4 years ago

ℏ is displayed too small

Categories

(Core :: Layout: Text and Fonts, defect)

Firefox 87
defect

Tracking

()

RESOLVED FIXED
89 Branch
Tracking Status
firefox89 --- fixed

People

(Reporter: ml, Assigned: jfkthame)

References

Details

Attachments

(2 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:87.0) Gecko/20100101 Firefox/87.0

Steps to reproduce:

On the page https://www.motionmountain.net/bet.html the character h-bar (ℏ) is much smaller than an h, and hard to read. This happens only with Firefox, not with Opera, Chrome or Safari.

Notes:

The character appears a few times on the page. The first time in part 1 of the proposed physics bet. The font used is a Google font.

Actual results:

the character h-bar (ℏ) is much smaller than an h

Expected results:

Same size.

The Bugbug bot thinks this bug should belong to the 'Core::SVG' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → SVG
Product: Firefox → Core
Component: SVG → Layout: Text and Fonts

Cannot reproduce. I don't think there is anything that can be done in Firefox if your local fonts are broken. Please provide info which fonts are used (Developer Tools > Inspector > Fonts).

Flags: needinfo?(ml)

The page is using Open Sans, but this does not support the h-bar character; and neither do any of the other fonts listed in the font-family property. So font fallback takes place and the browser uses whatever the operating system provides; on macOS, this is Apple Symbols, and in this font the letter is significantly smaller than in Open Sans.

Andre's screenshot (comment 2) is presumably from Linux, where DejaVu Sans is found as a fallback for the h-bar, and it has similar sizing to Open Sans. But this is entirely dependent on the fonts that happen to be provided by the platform, as the fonts explicitly chosen/loaded by the page just don't support that character.

There is a larger h-bar symbol in some Japanese fonts, so that adding for example "Hiragino Sans" to the font-family list will cause this to be used instead of Apple Symbols, and the result looks better in this particular case. But of course that's quite arbitrary. Perhaps a more principled option would be to include STIXGeneral in the font-family list, as it supports a wide range of technical symbols, and its sizing is at least closer to that of Open Sans although not quite as large as Hiragino.

The other thing that would help here is to use the font-size-adjust property, which is designed for exactly situations like this: it asks the browser to attempt to normalize the x-height of all the fonts used, so that fallbacks will be better harmonized with the primary font. Setting font-size-adjust: 0.54 on the content here seems to work pretty well.

One thing we can do in Firefox here is to adjust the "common fallback fonts" heuristics to prefer STIXGeneral over Apple Symbols, as the latter does tend to look small in relation to other common fonts. That will somewhat mitigate the issue.

However, the real solution is for the site author to explicitly choose appropriate fonts that provide all the characters needed; otherwise the appearance will always be subject to unpredictable variations depending what fallbacks occur on different browsers and platforms. I suspect that U+210F ℏ, being a technical symbol rather than a normal part of an alphabet -- for that usage, there's U+0127 ħ, which is much more widely supported -- will be missing from the majority of commonly-used text fonts, so fallback to a symbol font of some kind is highly likely.

In addition, using the font-size-adjust property would be a good precaution, such that if fallback does have to be used, the apparent sizes will be better matched.

The glyphs in Apple Symbols tend to be visually quite small relative to common text fonts,
so preferring STIXGeneral will give a less jarring appearance in some cases.

Assignee: nobody → jfkthame

I changed from ℏ to ħ
Now it works.

A more detailed description of the original problem is found at
https://webmasters.stackexchange.com/questions/133964/how-can-i-avoid-a-too-small-h-bar-hbar-showing-in-firexfox/133968#133968

Regards
Christoph

Flags: needinfo?(ml)

Well, you're now using the Unicode letter LATIN SMALL LETTER H WITH STROKE rather than the technical symbol PLANCK CONSTANT OVER TWO PI. If that's OK for your purposes, great -- but it does mean a change in the content, and ħ (unlike ℏ) does not carry a specifically italic style as an inherent feature of the character; as a result you might want to style it in italics.

If the content here really is supposed to be PLANCK CONSTANT OVER TWO PI, a better option (in my opinion) would be to stick with the precise Unicode character, and add the font-size-adjust property as suggested in comment 3 to the page's CSS.

Thank you. I implemented the font-size-adjust solution now. It works very well.

Again, thank you all for your help. It is the first time that the Firefox team helped me.
Nevertheless, I have you all in the acknowledgments of my physics book since many years:

https://www.motionmountain.net/sponsors.html (at the end).

Go on with the great work.

Best regards
Christoph

I also added your solution to stackexchange.

hbar is a constant that is very dear to me - thank you again.

Regards
Christoph

I'm glad we could resolve the problem for your site.

I see you applied font-size-adjust to the individual occurrences of ℏ. Another approach you might like to try would be to just set it on the <body> at the same time as you set your desired font-family list, so that it applies throughout the content. It won't affect -- at least not significantly, depending how accurately I guessed the value -- the Open Sans content, as its ex-height is already around 0.54 times the font size, but it will mean that any time ℏ (or any other symbol) ends up being rendered with Apple Symbols (or some other font) the size will be adjusted appropriately to maintain the same ex-height as the main text.

That's the real "magic" of font-size-adjust: you don't have to set it on each individual piece of text that needs adjusting (which may be difficult to anticipate); you can set the desired factor (ratio of ex-height to font-size) once, and let the browser make the adjustments as needed depending what font ends up getting used for any given character.

I tried it, but it has a very bad effect of the title: the title font size (of "Crimson Text" in h1 and h2) gets multiplied by 2 or 3 - it gets huge.
Again, this happens only on Firefox. You see, I understand fundamental physics, but not font-size-adjust. It will be for another life.

So I left the inline version. Thank you for all your help!
Christoph

Ugh - so it does! Sorry about that.

That's caused by an error in the Crimson Text font; checking its OS/2 table, it claims to have an ex-height of 125 units (in an em-square of 1024), which is far from the truth (it's actually something like 430), and that thoroughly misleads the font-size-adjust calculation.

So unfortunately font-size-adjust can't be safely applied to that font because of its wildly inaccurate metrics. I've just sent a report of that problem to Google Fonts, but for the time being we're stuck with this.

Pushed by jkew@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/65c3136b4fb1 Include STIXGeneral ahead of Apple Symbols in common fallbacks for symbol characters on macOS. r=m_kato
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 89 Branch
Regressions: 1705193
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: