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
Created attachment 129858 [details] Screenshot
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
(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?
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.
Created attachment 129884 [details] print to PDF w default rendering
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.
Also, while the glyphs are rendered clipped to the Print Preview, they are not clipped in the actual Windows printing service print jobs.
I have also got more OTF fonts from Google Code, they are all affected. https://code.google.com/archive/p/kingfont/downloads
It seems to be that OpenGL engine does not follow font metrics for vertical glyph origin.
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.
Created attachment 129972 [details] Test with Chinese and Tangut
So what happened if you intergrated HarfBuzz 1.3.4?
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.
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.
(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.
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.
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).
Hi Khaled, It works ( verified with master before and after the commit. ). Thank you.