Bug 105650 - Wrong text alignment with strikethrough within vertical writing
Summary: Wrong text alignment with strikethrough within vertical writing
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.3.0.2 rc
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 104828 (view as bug list)
Depends on:
Blocks: VCL-OpenGL Vertical-Text
  Show dependency treegraph
 
Reported: 2017-01-31 17:27 UTC by Volga
Modified: 2020-03-29 02:27 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Test file (10.56 KB, application/vnd.oasis.opendocument.text)
2017-01-31 17:32 UTC, Volga
Details
Screenshot (47.16 KB, image/png)
2017-01-31 17:33 UTC, Volga
Details
Screenshot 2 (48.48 KB, image/png)
2017-01-31 18:40 UTC, Volga
Details
on export to PDF OpenGL and Default GDI rendering same result (142.19 KB, image/png)
2017-01-31 19:09 UTC, V Stuart Foote
Details
Test file 2 (10.99 KB, application/vnd.oasis.opendocument.text)
2017-02-02 09:39 UTC, Volga
Details
Screenshot 3 (92.34 KB, image/png)
2017-02-02 09:50 UTC, Volga
Details
Sceenshot from Firefox (76.21 KB, image/png)
2017-03-02 16:23 UTC, Volga
Details
Screenshot from LibreOffice (109.74 KB, image/png)
2017-03-02 16:34 UTC, Volga
Details
Screenshot from LO 5.3.2.0.0 (123.50 KB, image/png)
2017-03-28 10:15 UTC, Volga
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Volga 2017-01-31 17:27:45 UTC
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
Comment 1 Volga 2017-01-31 17:31:06 UTC
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
Comment 2 Volga 2017-01-31 17:32:16 UTC
Created attachment 130798 [details]
Test file
Comment 3 Volga 2017-01-31 17:33:11 UTC
Created attachment 130799 [details]
Screenshot
Comment 4 Volga 2017-01-31 18:40:14 UTC
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
Comment 5 Volga 2017-01-31 18:46:20 UTC
Both GDI and OpenGL rendering performanced badly in this case, and OpenGL looks more serious.
Comment 6 V Stuart Foote 2017-01-31 19:04:39 UTC
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.
Comment 7 V Stuart Foote 2017-01-31 19:09:53 UTC
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
Comment 8 Volga 2017-02-01 18:28:39 UTC
To give quality layout in vertical writing, I think we should create an algorithm to make every upright glyph adapt the trikethrough.
Comment 9 Volga 2017-02-01 18:38:47 UTC
Again, this algorithm should always effective even if trikethrough is not used in the text.
Comment 10 V Stuart Foote 2017-02-01 18:57:24 UTC
Volga,

The term as corrected in summary by Julian, is "strikethrough" was there some technical reason to change it back to "trikethrough"?
Comment 11 Volga 2017-02-02 08:47:30 UTC
(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.
Comment 12 Volga 2017-02-02 09:39:23 UTC
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.
Comment 13 Volga 2017-02-02 09:50:18 UTC
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.
Comment 14 Volga 2017-02-02 10:00:31 UTC
Note: Comment 13 is works only with OpenGL.
Comment 15 Volga 2017-02-03 13:15:22 UTC
(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.
Comment 16 Volga 2017-02-11 23:54:44 UTC
(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.
Comment 17 Volga 2017-02-13 22:42:53 UTC
*** Bug 104828 has been marked as a duplicate of this bug. ***
Comment 18 Volga 2017-03-02 16:23:23 UTC
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.
Comment 19 Volga 2017-03-02 16:34:59 UTC
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.
Comment 20 Volga 2017-03-28 10:15:00 UTC
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
Comment 21 QA Administrators 2018-03-29 02:33:48 UTC Comment hidden (obsolete)
Comment 22 QA Administrators 2020-03-29 02:27:06 UTC
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