If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Unicode character modifiers rendered horizontal instead of vertical

UNCONFIRMED
Unassigned

Status

()

Core
Layout: Text
UNCONFIRMED
2 years ago
2 years ago

People

(Reporter: Martin Häcker, Unassigned)

Tracking

({fonts})

Trunk
x86
Mac OS X
fonts
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

2 years ago
Created attachment 8640996 [details]
unicode-rendering-bugs-chromium-firefox.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.12 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.12

Steps to reproduce:

What steps will reproduce the problem?
1. Open the URL  https://github.com/atom/atom/issues/8026#issuecomment-124875482
2. Look for the unicode oddity provided in a comment
3. Compare the rendering to Safari (or other unicode compliant text renderers)



Actual results:

Some of the unicode character modifiers are rendered sideways, while they should be rendered above or below the characters they modify.



Expected results:

It should look like in Safari (Compare the screenshot, Safari (correct) to the left, middle is Chromium, right is Firefox.
(Reporter)

Comment 1

2 years ago
Companion bug filed for chromium: https://code.google.com/p/chromium/issues/detail?id=515424&thanks=515424&ts=1438249596

Updated

2 years ago
Component: Untriaged → Layout: Text
Keywords: fonts
OS: Unspecified → Mac OS X
Product: Firefox → Core
Hardware: Unspecified → x86

Comment 2

2 years ago
Created attachment 8641099 [details]
Windows7.png

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:42.0) Gecko/20100101 Firefox/42.0
20150729030208
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0
20150630154324

I can't reproduce this. The issue must be with the font that ends up used on Mac OS X.
(Reporter)

Comment 3

2 years ago
In the Chromium bug they came to a similar conclusion (as far as I understand it) they think that it is a question of how fallback fonts are chosen.
For text that uses lots of Unicode combining marks, the author should ensure that a suitable font (i.e. one that supports the characters in question, and has adequate layout support such as OpenType GPOS mark-to-base and mark-to-mark positioning features) is also specified. Without that, results may be inferior, and will vary depending on what font(s) happen to get chosen by fallback algorithms when the default font being used doesn't support all the characters involved.
You need to log in before you can comment on or make changes to this bug.