Monaco.dfont breaks text height calculations (Linux)
Reported by
grawity@gmail.com,
Sep 18 2017
|
|||||||||
Issue description
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.91 Safari/537.36
Example URL:
data:text/html,<style>b,tt{background:orange;padding:2px;font-family:Monaco,Arial,monospace}</style><p>foo<b>bar</b><tt>baz</tt>quux</p>
Steps to reproduce the problem:
1. Use Linux.
2. Have the Monaco font (in .dfont format) installed.
3. Have Chromium 61 or Google Chrome 61.
4. Open a page which uses Monaco somewhere.
What is the expected behavior?
The elements should look like in other browsers.
What went wrong?
The elements seem to be 0 pixels tall (not counting padding). The text itself isn't clipped, but the background and the clickable area *are*.
Does it occur on multiple sites: Yes
Is it a problem with a plugin? No
Did this work before? Yes 60.x
Does this work in other browsers? Yes
Chrome version: 61.0.3163.91 Channel: stable
OS Version:
Flash Version: Shockwave Flash 27.0 r0
I found Monaco.dfont on GitHub. I'm not sure which macOS version it's from; will try to find a newer one. Regardless, it's still a bug compared to v60.
,
Sep 19 2017
(Oh, and as you can see from the screenshot, the affected text is using the 2nd font – perhaps Chrome is thinking that Monaco is a completely empty font?)
,
Sep 21 2017
Unable to reproduce the issue on 61.0.3163.91 and on latest dev 63.0.3218.0 using Ubuntu 14.04 with below steps. 1.Cloned monaco font from https://github.com/todylu/monaco.ttf 2.Launched chrome and typed data:text/html,<style>b,tt{background:orange;padding:2px;font-family:Monaco,Arial,monospace}</style><p>foo<b>bar</b><tt>baz</tt>quux</p> in omnibox. 3.Text is seen clearly without any breakage. Attaching screenshot for reference. NOTE: Same behaviour is seen in Firefox and M50 of chrome. @Reporter: Could you please provide actual monaco .dfont to be added? and could you also please check in fresh profile which don't have any apps and extensions added. Thanks!
,
Sep 21 2017
The font I use is from: https://github.com/vjpr/monaco-bold/raw/master/Monaco.dfont (The repository's README claims it is unaltered from OS X.) Can still reproduce on empty profiles, with the official binary builds of Chrome Stable 61.0 and Dev 63.0 (i.e. not limited to Arch's chromium).
,
Sep 21 2017
Thank you for providing more feedback. Adding requester "sc00335628@techmahindra.com" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 21 2017
Can also reproduce on an empty user account, after copying Monaco.dfont to ~/.local/share/fonts/ (the format is supported directly – no conversion to TTF needed). It *could* be a combination of Chrome 61 and the library versions that's triggering this. Arch has freetype 2.8, harfbuzz 1.5.1, pango 1.40.12 … not sure what else is involved.
,
Sep 23 2017
,
Sep 26 2017
Do you have FT_CONFIG_OPTION_MAC_FONTS enabled on the bundled FreeType? What about system FreeType? Your system might think that Monaco is available, while Chromium cannot open it. Whatever is shown is not Monaco btw.
,
Sep 27 2017
,
Sep 27 2017
> Do you have FT_CONFIG_OPTION_MAC_FONTS enabled on the bundled FreeType? I'm not 100% sure where to look, but Arch does not customize the bundled freetype – it's exactly whatever Chromium includes... Is that in 'third_party/freetype/include/freetype-custom-config/ftoption.h'? I see that file does not have _MAC_FONTS defined. > What about system FreeType? It's enabled in system FreeType, yes. > Your system might think that Monaco is available, while Chromium cannot open it. I see, I'll have to ask the Arch packager to enable this option in Chromium, then. Though, I still feel that Chromium should be ignoring unsupported fonts entirely, and not pretending they're 0×0-sized...
,
Sep 27 2017
Thank you for providing more feedback. Adding requester "eae@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 28 2017
,
Sep 28
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 30
No longer able to reproduce. |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by dtapu...@chromium.org
, Sep 18 2017