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:
Created attachment 154916 [details] Sample document
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
Created attachment 154939 [details] Win10 (1903) w SourceHanSanTC (v2.001) marks vertical runs are above baseline
@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.
@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.
Created attachment 154969 [details] More precise description for the expectation
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.
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?
(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.
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
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 ?
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.
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