- From: Koji Ishii via GitHub <sysbot+gh@w3.org>
- Date: Tue, 01 Mar 2022 07:57:29 +0000
- To: public-css-archive@w3.org
@jfkthame > Note that (if I'm understanding correctly) Blink simply passes the control characters through the same rendering pipeline as printable characters, so the result may be visible or not depending on the particular font being used. Some fonts map control-character codepoints to invisible glyphs, and in this case they'll remain invisible in Blink, while other fonts may render a `.notdef` box or even some other graphical representation. Correct. Blink has not implemented that part yet, so mac users do not complain about visible L-SEP ([crbug.com/550275](https://crbug.com/550275)) until we implement it. @litherum > This came up because the Notes app on iCloud.com assumes that `.notdef` is invisible and has zero width. I’m assuming this one website is not the only one. While Blink does not check U+0000, it does check glyph 0, so maybe that's what you observed in icloud.com? The glyph id 0 is `.notdef` as long as the font follows the [Recommendations for OpenType Fonts](https://docs.microsoft.com/en-us/typography/opentype/spec/recom#glyph-0-the-notdef-glyph). Blink has some places that assume all fonts follow this recommendation, such as [here](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/fonts/shaping/harfbuzz_shaper.cc;l=477?q=%20HarfBuzzShaper::ExtractShapeResults&ss=chromium%2Fchromium%2Fsrc). -- GitHub Notification of comment by kojiishi Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/6983#issuecomment-1055127180 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 1 March 2022 07:57:31 UTC