Description: The trikethrough does not through the middle of Chinese characters within vertical writing for several fonts. Steps to Reproduce: 1. Open Writer 2. Insert -> Frame -> Frame Interactively 3. Right click to open Object dialog, then set the text direction as right-to-left (vertical) at Options tab 4. Insert some texts 5. Click Trikethrough button at formatting toolbar Actual Results: The trikethrough looks shifted to the left with Micorsoft JhengHei, Source Han Sans. See the attachment. Expected Results: When trikethrough used in vertical texts, Chinese characters as well as other upright characters should be aligned properly to make trikethrough always go through their center. Also see this sample: Reproducible: Always User Profile Reset: No Additional Info: Version: 5.3.0.3 (x64) Build ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1 CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; Locale: zh-CN (zh_CN); Calc: group User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:51.0) Gecko/20100101 Firefox/51.0
This example can be found at W3C page, which is indicate as “Vertical baseline of an upright glyph”. https://drafts.csswg.org/css-writing-modes-3/#line-orientation
Created attachment 130798 [details] Test file
Created attachment 130799 [details] Screenshot
Created attachment 130800 [details] Screenshot 2 Screenshot after OpenGL is enabled. Version: 5.3.0.3 (x64) Build ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1 CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; Locale: zh-CN (zh_CN); Calc: group
Both GDI and OpenGL rendering performanced badly in this case, and OpenGL looks more serious.
With OpenGL rendering the strikethrough does not center on the rotated glyphs, and the position of the strikethrough differs between the Latin and the CJK glyphs. With Default GDI rendering the strikthrough may still be off center, how far seems to depend on the font but the Latin and the CJK glyphs get closer match of base for a seamless line. I see this reproduced using Adobe Source Han Sans SC which I believe has good vertical font metrics available. On Windows 8.1 Ent 64-bit en-US with Version: 5.4.0.0.alpha0+ Build ID: 0cd819b68ced2a95a127a246c0558153fbdbcae2 CPU Threads: 8; OS Version: Windows 6.2; UI Render: GL; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2017-01-31_12:28:03 Locale: en-US (en_US); Calc: CL and with Version: 5.3.0.3 (x64) Build ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1 CPU Threads: 8; OS Version: Windows 6.29; UI Render: GL; Layout Engine: new; Locale: en-US (en_US); Calc: group Interestingly an Export to PDF places the strikethrough closer to centered (minor difference between the Latin and CJK glyphs), and the OpenGL matches the Default GDI. So very different from results for export, compared to rendering to the on displayed document canvas.
Created attachment 130802 [details] on export to PDF OpenGL and Default GDI rendering same result attached comparison of PDF export from OpenGL (left) and Default GDI (right) -- export to PDF has similar results for both. Better than rendering to on screen document canvas. The first and last column are the sample text added with Source Han Sans SC
To give quality layout in vertical writing, I think we should create an algorithm to make every upright glyph adapt the trikethrough.
Again, this algorithm should always effective even if trikethrough is not used in the text.
Volga, The term as corrected in summary by Julian, is "strikethrough" was there some technical reason to change it back to "trikethrough"?
(In reply to V Stuart Foote from comment #10) > Volga, > > The term as corrected in summary by Julian, is "strikethrough" was there > some technical reason to change it back to "trikethrough"? I made a mistake, sorry.
Created attachment 130830 [details] Test file 2 I made another testcase with Yi, the text is found at http://scripts.sil.org/cms/scripts/page.php?item_id=SILYi_home. I use three Yi font to make this testcase: Microsoft Yi Baiti, this is an Yi font that includes in MS Windows Nuosu SIL Noto Sans Yi (available at Google Noto Fonts website) STR 1. Open Writer 2. Insert -> Text box 3. Insert Yi poem ꀉꂿꅩꌺ 4. Click Text direction from top to bottom button 5. Select the who text and click Strikethrough button With Nuosu SIL, the strikethrough seems shifted to the right a bit, but after I enabled OpenGL, the strikethrough seems shifted to the left a bit.
Created attachment 130831 [details] Screenshot 3 This is another testcase with Tangut. STR 1. Copy texts from Wikisource: https://wikisource.org/wiki/Hymn_of_the_Holy_Origin_of_Tangut 2. Open Writer 3. Insert -> Text box 4. Paste the text into Text box 5. Set the font face as Tangut N4694 6. Click Text direction from top to bottom button 7. Select the whole text and click Strikethrough button Then the text looks shifted to the left.
Note: Comment 13 is works only with OpenGL.
(In reply to V Stuart Foote from comment #6) > I see this reproduced using Adobe Source Han Sans SC which I believe has > good vertical font metrics available. OK, I think Source Han Sans is suitable for this test, but although Source Han Sans has good vertical font metrics available, we should making our text layout engine smarter to care for other fonts which does not optimized for vertical layout, W3C draft CSS Writing Modes Level 3 have the following note for this: “When text-orientation: upright, the baseline is still vertical, and the vertical baseline in the font is used, or the vertical baseline is synthesized if the font does not provide. ” This is a good guidance for vertical layout in digital typography, I think this implementation shouldn’t be made only in web browser, this should be made in all clients that needs vertical writing.
(In reply to V Stuart Foote from comment #7) > Created attachment 130802 [details] > on export to PDF OpenGL and Default GDI rendering same result > > attached comparison of PDF export from OpenGL (left) and Default GDI (right) > -- export to PDF has similar results for both. Better than rendering to on > screen document canvas. They looks as expected, but still less perfect.
*** Bug 104828 has been marked as a duplicate of this bug. ***
Created attachment 131581 [details] Sceenshot from Firefox Here is my test case with Tangut N4694 font on Firefox 51. You can try to get the font from attachment 130653 [details]. STR 1. Open codepen.io on Firefox 2. Click New Pen button 3. Input following codes: <div style="font-family: Tangut N4694; font-size: 2em; writing-mode: vertical-rl; text-orientation: upright"> <p><s>𗀀𗀂𗀇𗀈𗀊𗀌𗀍𗀐𗀔𗀘𗀙𗀚𗀛𗀝𗀞𗀟𗀠𗀡𗀥𗀫𗀯𗀸𗀹𗀻𗀽𗀾𗀿𗁀𗁂𗁃𗁅𗁆𗁉𗁊𗁋𗁍𗁏𗁑𗁕𗁜𗁝𗁟𗁡𗁢𗁣𗁤𗁦𗁧𗁫𗁬𗁭𗁮𗁴𗁶𗁷𗁺𗁽𗁿</s></p> <p><s>𘠀𘠁𘠃𘠈𘠊𘠋𘠐𘠒𘠔𘠕𘠙𘠚𘠛𘠞𘠠𘠡𘠣𘠤𘠧𘠨𘠪𘠫𘠬𘠭𘠮𘠲𘠳𘠵𘠶𘠼𘡀𘡂𘡃𘡄𘡅𘡈𘡉𘡊𘡋𘡍𘡎𘡒𘡓𘡔𘡖𘡗𘡘𘡚𘡛𘡜𘡡𘡢𘡣𘡤𘡦𘡩𘡪𘡫𘡮𘡯𘡰𘡱𘡵𘡷𘡸𘡽</s></p> <p><s>𖿠</s></p> </div> Then you can see the strikethrough always go through the middle of a glyph, and all upright glyhs are well aligned.
Created attachment 131582 [details] Screenshot from LibreOffice Here is equivalent test on LibreOffice, note this is works only with OpenGL enabled. STR 1. Open LibreOffice Writer 2. Insert -> Frame -> Frame Interactively 3. Insert Tangut characters from previous commit, then change the font name as Tangut N4694 4. Right click the frame, them click Object 5. Option tab -> Text directon -> Right-to-left (vertical) 6. Select the who text and then click Strikethrough button on the toolbar. Then you will see the bad alignment with strikethrough.
Created attachment 132213 [details] Screenshot from LO 5.3.2.0.0 I opened attachment 130798 [details] on LO 5.3.2.0.0, only PMingLiU performanced well on both OGL and GDI rendering engine. Version: 5.3.2.0.0+ (x64) Build ID: c8f0a37ff804e6329b21a4b7bfabb0667263c6e5 CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; Locale: zh-CN (zh_CN); Calc: group Version: 5.3.2.0.0+ (x64) Build ID: c8f0a37ff804e6329b21a4b7bfabb0667263c6e5 CPU Threads: 4; OS Version: Windows 6.19; UI Render: GL; Layout Engine: new; Locale: zh-CN (zh_CN); Calc: group
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear Volga, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Volga: please test with Skia/Vulkan on Windows.
Created attachment 168074 [details] Screenshot from LO 7.0 Unfortunately, the problem is still there if I used Skia/Vulkan backend.
Volga: could you follow this link: https://wiki.documentfoundation.org/QA/FirstSteps#Graphics-related_issues_.28Skia.29 ?
Created attachment 168123 [details] Screenshot 2 from LO 7.0 Unfortunately, it doesn’t help. Version: 7.0.3.1 (x64) Build ID: d7547858d014d4cf69878db179d326fc3483e082 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: zh-CN (zh_CN); 界面: zh-CN Calc: threaded
Created attachment 168124 [details] Screenshot 2 from LO 7.0 Unfortunately, it doesn’t help. Version: 7.0.3.1 (x64) Build ID: d7547858d014d4cf69878db179d326fc3483e082 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: zh-CN (zh_CN); 界面: zh-CN Calc: threaded
Seen from attachment 168124 [details], MingLiU is the only font works as expected after I enabled Skia/Raster backend.
Mark Hung committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/68c1682929d5b8af95e299a2cfb3fdbb4f97e5ed tdf#105650 different strikethrough offset for vertical writing. It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.