Download it now!
Bug 104855 - Chinese characters clipped within vertical column when OpenGL is enabled
Summary: Chinese characters clipped within vertical column when OpenGL is enabled
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.3.0.0.beta2
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: VCL-OpenGL Regressions-HarfBuzz Vertical-Text
  Show dependency treegraph
 
Reported: 2016-12-22 08:32 UTC by Volga
Modified: 2017-03-08 11:05 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot (81.34 KB, image/png)
2016-12-22 08:33 UTC, Volga
Details
print to PDF w OpenGL rendering (86.92 KB, image/png)
2016-12-22 17:57 UTC, V Stuart Foote
Details
print to PDF w default rendering (89.22 KB, image/png)
2016-12-22 17:58 UTC, V Stuart Foote
Details
test doc in Writer w OpenGL enabled (41.96 KB, image/png)
2016-12-22 18:03 UTC, V Stuart Foote
Details
Test with Chinese and Tangut (11.34 KB, application/vnd.oasis.opendocument.text)
2016-12-27 17:03 UTC, Volga
Details
Test with Chinese and Tangut (12.88 KB, application/vnd.oasis.opendocument.text)
2016-12-27 20:16 UTC, Volga
Details
test sample and screenshot(side by side comparison) (26.52 KB, application/x-zip-compressed)
2017-03-06 12:35 UTC, Mark Hung
Details
Screenshot using PMingLiU without clipping (51.39 KB, image/png)
2017-03-08 02:35 UTC, Khaled Hosny
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Volga 2016-12-22 08:32:19 UTC
Description:
Chinese characters within vertical text looks clipped when OpenGL is enabled, this problem can be reproduce with OTF fonts.

Steps to Reproduce:
1. Enable OpenGL
2. Open attachment 128802 [details]

Actual Results:  
When I ueed Source Han Sans, top and right edge are clipped. I have tested with another OTF fonts, the problem looks the same to me.

Expected Results:
This problem shouldn’t appearing with OTF fonts.


Reproducible: Always

User Profile Reset: No

Additional Info:
Version: 5.3.0.0.beta2
Build ID: a7e30712ad6d8bc9286007b37aa581983e0caba3
CPU Threads: 4; OS Version: Windows 6.2; UI Render: GL; Layout Engine: new; 
Locale: zh-CN (zh_CN); Calc: group


User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:50.0) Gecko/20100101 Firefox/50.0
Comment 1 Volga 2016-12-22 08:33:10 UTC
Created attachment 129858 [details]
Screenshot
Comment 2 V Stuart Foote 2016-12-22 14:53:20 UTC
Confirming. 

And, with current master, continue to have clipping of the OTF fonts on the document canvas. PDF export is not clipped with or without OpenGL enabled.

With attachment 128802 [details] the 思源黑体 (Sīyuán hēitǐ) font is fall back replaced with Sim Sun on my Windows system, it is clipped at the top edge of the frame.  I have the BableStone Han font used on system--interesting in that it is correct in both the OpenGL and the default rendering.

I replaced the Sīyuán hēitǐ font in attachment with Source Han Sans Regular, assuming it would have correct hinting.  But with that, both the top edge and the right edge of the glyphs are clipped with OpenGL rendering.

Same results if rather than fallback SimSun, I replace with SimSun-ExtB that OTF font like Source Han Sans is clipped on both top and right edge displayed on the document canvas--PDF export is fully formed.

tested on Windows 10 Pro 64-bit en-US with
Version: 5.4.0.0.alpha0+
Build ID: 2a4cd80abcf9e515d1ce3b3a944b573bdc42bff2
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; 
TinderBox: Win-x86@39, Branch:master, Time: 2016-12-22_00:11:39
Locale: en-US (en_US); Calc: CL


BableStone Han v.9.01
Sim Sun v.5.15
Comment 3 Volga 2016-12-22 16:52:39 UTC
(In reply to V Stuart Foote from comment #2)
> And, with current master, continue to have clipping of the OTF fonts on the
> document canvas. PDF export is not clipped with or without OpenGL enabled.

What happened if you print with PDFCreator?
Comment 4 V Stuart Foote 2016-12-22 17:57:38 UTC
Created attachment 129883 [details]
print to PDF w OpenGL rendering

(In reply to Volga from comment #3)
> (In reply to V Stuart Foote from comment #2)
> > And, with current master, continue to have clipping of the OTF fonts on the
> > document canvas. PDF export is not clipped with or without OpenGL enabled.
> 
> What happened if you print with PDFCreator?

If printing to PDF (CutePDF w/ghostscript 9.18)--the OpenGL rendering of the canvas matches the default rendering.
Comment 5 V Stuart Foote 2016-12-22 17:58:21 UTC
Created attachment 129884 [details]
print to PDF w default rendering
Comment 6 V Stuart Foote 2016-12-22 18:03:36 UTC
Created attachment 129885 [details]
test doc in Writer w OpenGL enabled

attachement is clip of the test doc with SimSun-ExtB substituted in left column, right column is BableStone Han. Clipping is evident on canvas, but when printing (ghostscript based) or when exporting to PDF the glyphs are fully rendered.
Comment 7 V Stuart Foote 2016-12-22 18:11:21 UTC
Also, while the glyphs are rendered clipped to the Print Preview, they are not clipped in the actual Windows printing service print jobs.
Comment 8 Volga 2016-12-24 09:06:24 UTC
I have also got more OTF fonts from Google Code, they are all affected.
https://code.google.com/archive/p/kingfont/downloads
Comment 9 Volga 2016-12-26 02:37:31 UTC
It seems to be that OpenGL engine does not follow font metrics for vertical glyph origin.
Comment 10 Volga 2016-12-27 17:03:51 UTC
Created attachment 129965 [details]
Test with Chinese and Tangut

This problem affect not only OTF fonts but also TTF fonts. Also, I tested with Unicode encoded Tangut fonts. When I select the text, they looks sightly deviationed.

Selected text with SimSun
http://tinypic.com/view.php?pic=mkhs04&s=9

Selected text with SimKai
http://tinypic.com/view.php?pic=i5pu9z&s=9

Tangut errors is already reported in bug 104874.
Comment 11 Volga 2016-12-27 20:16:00 UTC
Created attachment 129972 [details]
Test with Chinese and Tangut
Comment 12 Volga 2016-12-31 04:01:53 UTC
So what happened if you intergrated HarfBuzz 1.3.4?
Comment 13 Khaled Hosny 2017-03-05 00:23:42 UTC
I can’t reproduce this, and this bug report is vague and confusing.

Please attach a document that clearly show the issue, that uses either a font shipped with Windows 10 or provide a direct URL to the *font file* use or better (if the license allows) attach the font here.
Comment 14 Mark Hung 2017-03-06 12:35:01 UTC
Created attachment 131673 [details]
test sample and screenshot(side by side comparison)

Hi Khaled,

I've uploaded the test sample, which use PMingLiu that shipped with Windows10. Please check if you can reproduce this. Thanks.
Comment 15 V Stuart Foote 2017-03-06 13:33:45 UTC
(In reply to Mark Hung from comment #14)
> Created attachment 131673 [details]
... 
> I've uploaded the test sample, which use PMingLiu that shipped with
> Windows10. Please check if you can reproduce this. Thanks.

I still see the same issue(s) with this sample document on Windows 10 Pro, on the 5.3.1.1 build. So should reproduce for you Khaled.
Comment 16 Khaled Hosny 2017-03-08 02:35:33 UTC
Created attachment 131741 [details]
Screenshot using PMingLiU without clipping

I still can’t reproduce this with attachment 131673 [details] (I had to manually change the font name to PMingLiU since we don’t seem to support localized font names when using different locale). See the attached screenshot from a relatively up to date master.
Comment 17 Khaled Hosny 2017-03-08 02:40:26 UTC
I’m guessing this has been fixed with bug 103831 since now vertical text goes through GDI regardless of OpenGL use, so please confirm you are testing with an up to date master (this landed in 5-3 just yesterday).
Comment 18 Mark Hung 2017-03-08 11:05:15 UTC
Hi Khaled,

It works ( verified with master before and after the commit. ). Thank you.