Bug 128080 - Bopomofo tone marks position incorrectly in vertical writing.
Summary: Bopomofo tone marks position incorrectly in vertical writing.
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
6.0.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: CJK
  Show dependency treegraph
 
Reported: 2019-10-11 03:18 UTC by Mark Hung
Modified: 2021-06-14 02:49 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample document (17.60 KB, application/vnd.oasis.opendocument.text)
2019-10-11 03:19 UTC, Mark Hung
Details
Win10 (1903) w SourceHanSanTC (v2.001) marks vertical runs are above baseline (117.08 KB, image/png)
2019-10-11 14:47 UTC, V Stuart Foote
Details
More precise description for the expectation (5.91 KB, image/png)
2019-10-13 14:02 UTC, Mark Hung
Details
How it looks in Libo 5.3 (61.15 KB, image/png)
2019-10-23 12:16 UTC, Xisco Faulí
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Hung 2019-10-11 03:18:57 UTC
Description:
Support of bopomofo and their tone marks were added in Source Han Sans 2.0, as described in its readme:
The glyphs and support for bopomofo, along with their tone marks, were improved. This involved adding the 'GDEF' (Glyph Definition) table, the 'mark' (Mark Positioning) GPOS feature, and the 'ruby' (Ruby Notation Forms) GSUB feature.

It doesn't work in current LibreOffice. This is related to my commit 51b9042efea09 to fix tdf#95656.


Steps to Reproduce:
1.Open the attached file.
2.Compare the attached file and the expected result ( image is also in the attached file. )

Actual Results:
Tone marks were clamped into the line, not in its expected position.

Expected Results:
Tone mark should be positioned right side of the vertical line.


Reproducible: Always


User Profile Reset: No



Additional Info:
Comment 1 Mark Hung 2019-10-11 03:19:26 UTC
Created attachment 154916 [details]
Sample document
Comment 2 V Stuart Foote 2019-10-11 14:42:30 UTC
Can not confirm on Windows 10 Home 64-bit en-US with
Version: 6.3.2.2 (x64)
Build ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded

I make font substitution of test document (otherwise fallback font):

Noto Sans TC Regular (v1.004)
Source Sans Pro (v2.010)
Source Han Sans (v2.001) [1]

The Source Han Sans elevates tone marks (ox02c7, 0x02c9, 0x02ca, 0x02cb) on both the Horizontal and the Vertical runs. Maybe not a fully offsset from baseline as needed, but not sitting on it for either orientation. Clip attached...

The Source Sans Pro elevates tone marks in the Horizontal run, but not for the vertical.

Interestingly the Noto Sans TC does not elevate any of the tone mark glyphs in horizontal layout. I guess they have not been updated to Adobe-fonts new baseline.


=-ref-=
[1] Source Han Sans release on Git-hub: https://github.com/adobe-fonts/source-han-sans/tree/release
Comment 3 V Stuart Foote 2019-10-11 14:47:58 UTC
Created attachment 154939 [details]
Win10 (1903) w SourceHanSanTC (v2.001) marks vertical runs are above baseline
Comment 4 Mark Hung 2019-10-12 11:49:21 UTC
@V Stuart Foote

https://www.w3.org/TR/clreq/#positioning_of_zhuyin
3.3.3.1 Positioning of Zhuyin Symbols
Mandarin non-neutral tones and dialectal non-checked tones, are placed outside the upper right corner of the last phonetic symbol. ( Or check Figure 15. )

So the screenshot you uploaded confirms the issue. The tone marks overlapped with the consonants instead of being placed at the right side of the consonants.
Comment 5 V Stuart Foote 2019-10-12 12:12:04 UTC
@Mark Hung,

Not so sure. You'd said in OP that they were "clamped into the line", and for the Source Han TC/Noto Han TC before the v2.001 builds that appears true. But with Source Han San TC the tone marks are shifted for both the horizontal and the vertical layouts.

Is the fact that they are not now shifted far enough a font metric issue or a hb issue? But point is they are shifted from the vertical baseline.
Comment 6 Mark Hung 2019-10-13 14:02:31 UTC
Created attachment 154969 [details]
More precise description for the expectation
Comment 7 Mark Hung 2019-10-13 14:07:55 UTC
Hi V Stuart Foote,

I uploaded a new image. I hope it can describe what I expect more precisely. Note that there isn't any problem with horizontal writing mode. I just put it in the original test document for reference. I think they should not compare to each other in this case.
Comment 8 V Stuart Foote 2019-10-13 15:27:35 UTC
In your OP you said it "doesn't work" and it was "clamped into the line" in vertical mode text. Was that not the case?

But, I agree we do not shift the tone marks 'far enough' to the right of the base line in vertical mode. But they are shifted so the traditional Chinese mode in zh-TW locale is activating the 'mark' position alternates provided in the Source Han Sans 2.001

So is it  a font metric issue with the TC version of Source Han Sans? Or the LO handling? And would the tweak be needed to harfbuzz, or in our CommonSalLayout?
Comment 9 Mark Hung 2019-10-14 01:45:43 UTC
(In reply to V Stuart Foote from comment #8)
> In your OP you said it "doesn't work" and it was "clamped into the line" in
> vertical mode text. Was that not the case?
> 

All I want to express is in Attachment 154969 [details]. I said that the tone marks were "clamped" into the line because they were overlapped with other characters. Saying "it doesn't work" might exaggerate. It's possible that I expressed in a wrong way.

> But, I agree we do not shift the tone marks 'far enough' to the right of the
> base line in vertical mode. But they are shifted so the traditional Chinese
> mode in zh-TW locale is activating the 'mark' position alternates provided
> in the Source Han Sans 2.001
> 
> So is it  a font metric issue with the TC version of Source Han Sans? Or the
> LO handling? And would the tweak be needed to harfbuzz, or in our
> CommonSalLayout?

It's not easy to answer. Harfbuzz utility compiled in Linux rendered as expected. Simply reverting 51b9042efea09 make the tone marks shift correctly relative to other bopomofo marks but shift the whole line.
Comment 10 Xisco Faulí 2019-10-23 12:16:51 UTC
Created attachment 155256 [details]
How it looks in Libo 5.3

How it looks in

Version: 5.3.0.0.alpha1+
Build ID: 4136757b4e51c4e6f7cb4132c95538a7f831ef2c
CPU Threads: 4; OS Version: Linux 4.15; UI Render: default; VCL: gtk3; Layout Engine: new; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group
Comment 11 Xisco Faulí 2019-10-23 12:24:02 UTC
it seems the problem is related to HarfBuzz. they were shown as in my screenshot up to https://cgit.freedesktop.org/libreoffice/core/commit/?id=5aab2900dfdc9f12adda378470149670a2a069df when HarfBuzz was updated to 1.4.8.

@Khaled Hosny, should this issue be reported to HarfBuzz instead ?
Comment 12 V Stuart Foote 2019-10-23 14:40:38 UTC
See also the older harfbuzz issue #532, predating the Adobe work on the GPOS 'mark' and bopomofo support in Source Han Sans v2.0 TC.
Comment 13 Mark Hung 2021-06-14 02:49:49 UTC
This issue should have been fixed with dd0d0b44fd1c6c0292d7b2eb3f5cf2baa21e4481 and the subsequent patches for vertical writings. 

Verified works for me with

Version: 7.2.0.0.alpha1+ (x64) / LibreOffice Community
Build ID: 0c8fa16c78e6887d6d3a6041166d388e266bbce7
CPU threads: 16; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: zh-TW (zh_TW); UI: en-US
Calc: CL