Open Bug 1289015 Opened 8 years ago Updated 2 years ago

japanese glyphs in 'text-orientation: mixed' run of text do not baseline-align centrally when alongside of latin glyphs

Categories

(Core :: Layout: Block and Inline, defect, P3)

defect

Tracking

()

People

(Reporter: mashabow, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: testcase)

Attachments

(4 files)

Attached file testcase.html
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160623154057

Steps to reproduce:

Open attached test case in Firefox.


Actual results:

In the right box, upright glyphs "天地玄黄" are shifted to the left and don't align with sideways glyphs "ABC123".


Expected results:

All glyphs should align with the central baseline (the middle of the box).
Added a screenshot on Firefox 49.0a2 and Chrome 52, OS X 10.10.5.
Notes:

- I can reproduce this bug on Windows 10 with DirectWrite ClearType, while can't reproduce with GDI ClearType.
- This bug seems to occur with fonts whose Ascender/Descender in 'hhea' table differs from its sTypoAscender/sTypoDescender of 'OS/2' table.
- It might related with bug 1230456 and/or bug 1231239.
Component: Untriaged → Layout: Text
Product: Firefox → Core
Masaya,

Your test is good, your bug report is clear and your screenshot is helpful. Thank you.

Right now, I can not reproduce the baseline-alignment problem that you see under Windows 10; I am using Firefox 47 and Firefox 50.0a1 buildID=20160711113740 under Linux KDE ... but I believe your bug report. I've tried with default system font (TakaoPGothic font: TakaoPGothic.ttf) for Japanese glyphs under Linux KDE and I still could not reproduce the problem you see under Windows 10.

I believe I can improve a bit your test in several ways:
 - by increasing font size
 - by adding writing-mode: tb-rl; /* IE11 */ so that we could also verify how IE11 and Edge handle such test. IE11 and Edge support central baseline-alignment
 - by using glyphs like "宙" "E" glyphs so that it would be visually easier to see how central baseline-alignment is rendered
 - maybe also using a background image like in text-orientation-mixed-002-GT test
 - etc...

It is important to have the words "baseline-align" or "baseline alignment" inside the summary.
I have changed component "Layout: Text" to "Layout: Block and Inline".

Masaya, are you also able to reproduce the problem under Mac OS X 10.10.5 ?
Component: Layout: Text → Layout: Block and Inline
Keywords: testcase
OS: Unspecified → Windows 10
Summary: 'upright' and 'sideways' glyphs in vertical text don't align each other → latin glyphs and japanese glyphs with 'text-orientation: mixed' do not baseline-align centrally each other
Another test:

http://www.gtalbot.org/BugzillaSection/Bug1289015-glyphs-central-baseline-alignment.html

This test could be improved or other (better or more useful) variants of such test could be created.

While using Firefox 47 and Firefox 50.0a1 buildID=20160711113740, the japanese glyph appears to be shifted 10px to the left (actual result) in the rectangles with orange color while the japanese glyph is not shifted 10px to the left (expected result) in both Chrome 52.0.2743.82 and Chrome 53.0.2785.21. 
I am using Linux 3.13.0-92-generic x86_64, Qt: 4.8.6, KDE 4.13.3; Kubuntu (trusty) 14.04.4 LTS. 
I believe there is no duplicate for this bug.

Marking as NEW for all os-es and platforms.
Blocks: writing-mode
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 10 → All
Hardware: Unspecified → All
Version: 49 Branch → Trunk
In _Bug1289015-glyphs-central-baseline-alignment.html test, IE11 does not shift the japanese glyph to the left. I do not know about Edge 13.

Latest nightly build (Firefox 50.0a1 buildID=20160725030248) appears to shift the japanese glyph approx. 10px to the left.
Another test using a latin glyph with a descender:

http://www.gtalbot.org/BugzillaSection/Bug1289015-glyphs-central-baseline-alignment-002.html

Again, Chrome 53.0.2785.21 and IE11 do not shift the japanese glyph to the left. I do not know about Edge 13.

Firefox 47 (stable release) and latest nightly build (Firefox 50.0a1 buildID=20160725030248) appear to shift the japanese glyph approx. 10px to the left.
We probably did not discover such kind of rendering layout problem, discrepancy before because we have been exclusively using, resorting to Ahem font for testing baseline-alignment in CSS Writing Modes Testing. And the Ahem font only has latin glyphs. So this is a weakness in our tests and testing procedures in CSS  Writing Modes Test. I remember we discussed before the need to add at least 1 japanese or chinese glyph into a newer version of Ahem font...

+CC Elika and Koji regarding this.
Screenshot of _Bug1289015-glyphs-central-baseline-alignment-002.html in Firefox 50.0a1 buildID=20160725030248 with the 2 associated system fonts for that test on my Linux KDE platform
I now believe we should resummarize somewhat to something like this:

japanese glyphs in 'text-orientation: mixed' run of text do not baseline-align centrally when accompanied with latin glyphs
Summary: latin glyphs and japanese glyphs with 'text-orientation: mixed' do not baseline-align centrally each other → japanese glyphs in 'text-orientation: mixed' run of text do not baseline-align centrally when alongside of latin glyphs
Screenshot of Bug1289015-glyphs-central-baseline-alignment-002.html in Firefox 50.0.2, OS X 10.10.5
(In reply to Gérard Talbot from comment #3)
> Masaya, are you also able to reproduce the problem under Mac OS X 10.10.5 ?

Although this problem still occurs on my test, I can't reproduce it on your tests. As shown in the attached screenshot, both Japanese and Latin glyphs are rendered with "Hiragino Kaku Gothic ProN W3", and they are aligned properly.

- OS X 10.10.5
- Firefox 50.0.2
- newly created profile

To improve the tests, I think it is important to specify font files explicitly by @font-face.
This seems to be quite dependent on the specific font (it occurs with the Noto webfont in the attached testcase, but looks fine if I disable this and use my system's default font).

It's also noticeable that the extent of the highlight rendered when some of the text is selected is different between the Japanese-only and mixed-script examples, and if the contenteditable attribute is added, the caret in the mixed-script example appears misplaced (offset to the right). These issues are likely all somewhat inter-related.
Priority: -- → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: