Description: The bottom half of a letter (i.e. g) is missing on vertical text. Steps to Reproduce: see attached document Actual Results: see attached document Expected Results: a 'complete' visible letter ('g') Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 152073 [details] tweeendertig is the Dutch word for 32.
Confirming on Windows 10 Home 64-bit en-US with Version: 6.2.4.2 (x64) Build ID: 2412653d852ce75f65fbfa83fb7e7b669a126d64 CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded Version: 6.4.0.0.alpha0+ (x64) Build ID: 87238627b025ee6aa61378667e56b1769d4460c2 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-06-09_03:04:32 Locale: en-US (en_US); UI-Language: en-US Calc: threaded But, I think this will end up a font metric issue. IIUC The Vertical Text box is looking for font support for 'vert' glyph rotation, those fonts provide metrics that support non-rotated glyphs. For example descenders for any of the Microsoft CJK fonts are correctly handled in the draw Vertical Text box objects. @Khaled, Jan-Marek?
Created attachment 152094 [details] I can't reproduce it I can't reproduce it in Version: 6.4.0.0.alpha0+ Build ID: ec905d131374f0860bac77c52873eed984b1966f CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk2; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded nor in Versión: 6.2.4.2 Id. de compilación: 2412653d852ce75f65fbfa83fb7e7b669a126d64 Subprocs. CPU: 1; SO: Windows 6.1; Repres. IU: predet.; VCL: win; Configuración regional: es-ES (es_ES); Idioma de IU: es-ES Calc: threaded
it also fine in Version: 6.3.0.0.beta1+ (x86) Build ID: 5cfac16dbd4af456a7fb6d52c8953c69a72ba2ba CPU threads: 16; OS: Windows 6.3; UI render: default; VCL: win; Locale: en-GB (en_GB); UI-Language: en-US Calc: threaded @Luuk, @V Stuart Foote, please attach a screenshot of the problem
Created attachment 152105 [details] vertical Text Box dependent on font metrics (In reply to Xisco Faulí from comment #4) > @Luuk, @V Stuart Foote, please attach a screenshot of the problem attached. Copied the vertical Text Box, but changed font for the copy to one with correct metrics. Britanic Bold of the original is clipped in its descenders --g and added y, q, p. A font with better metrics, Microsoft Yahei, is correctly bounded.
(In reply to V Stuart Foote from comment #5) > Created attachment 152105 [details] > vertical Text Box dependent on font metrics > > (In reply to Xisco Faulí from comment #4) > > @Luuk, @V Stuart Foote, please attach a screenshot of the problem > > attached. > > Copied the vertical Text Box, but changed font for the copy to one with > correct metrics. Britanic Bold of the original is clipped in its descenders > --g and added y, q, p. A font with better metrics, Microsoft Yahei, is > correctly bounded. Should add that the metrics issue is even more apparent if you select the text, shows the clipping of the stamped glyph relative to its bounding box held in the vertical text box.
QA - wrong meta... adjusted to bug 71732
I tried to repo, but it works for me in current master on either win10 or kf5. If this is a font based problem, and it's still broken, we need that font. If you can attach the broken font (copyright?), someone can at least try to fix the problem. As it, there isn't anything I can do. And please retest with current 6.4 beta or a daily build from https://dev-builds.libreoffice.org/daily/. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds and reset the bug from NEEDINFO to NEW, if it's still broken, or RESOLVED FIXED, if not.
Created attachment 156200 [details] example in version 6.3.0.4 Will try to update (soon), and see what this does to this problem.
[Automated Action] NeedInfo-To-Unconfirmed
The font is: 'Britanic bold' https://docs.microsoft.com/en-us/typography/font-list/britannic-bold (as should ave been clear from the exmaple doc i uploaded)
(In reply to Luuk from comment #9) > Will try to update (soon), and see what this does to this problem. Luuk, anything new after update? => NEEDINFO
Created attachment 158678 [details] example in 6.4.0.3 nothing changed (comparing 6.3.0.4 to 6.4.0.3)
Found the font online, installed it and tested on Linux and Windows. I got the same good result as shown in the Win part of Xisco's screenshot. Possibly Luuk has a font version that is different from what me and Xisco used.
The font that i am using is: 'Btitannic Bold', that comes with Windows. Version: 1.51 Copyright: Typeface © 1992 Stephenson Blake (holdings) Ltd. Data © 1992 URW. Portions © 1992 Microsoft Corp.
(In reply to Luuk from comment #16) > The font that i am using is: 'Btitannic Bold', that comes with Windows. > > Version: 1.51 > Copyright: Typeface © 1992 Stephenson Blake (holdings) Ltd. Data © 1992 > URW. Portions © 1992 Microsoft Corp. https://docs.microsoft.com/en-us/typography/font-list/britannic-bold
(In reply to Luuk from comment #16) > The font that i am using is: 'Btitannic Bold', that comes with Windows. > > Version: 1.51 > Copyright: Typeface © 1992 Stephenson Blake (holdings) Ltd. Data © 1992 > URW. Portions © 1992 Microsoft Corp. Hmm, the version I found is the same, 1.51
I also can't confirm with Version: 7.0.0.0.alpha1+ (x64) Build ID: 99c337d1d3831ce9d2c7dc1cbff713f4ac49d6ac CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win; Locale: en-GB (de_DE); UI: en-GB Calc: CL
I was looking at this (again) and i wondered how i did to this vertical text.... You can rotate a textbox by 90 degrees, but there is also another option in Libroffice. It's named "Text direction from top to bottom", en it's in the toolbars...
Please close this bug, - It has ben open for more than 1 year (even 1.5 year) - Nobody seems to be able to reproduce this - Anyone who can confirm this, put blame on fonts being used - Looking again at my document, using version 7.0.0.3, seems to indicated that this problems has solved itself.
(In reply to Luuk from comment #21) > Please close this bug, > - Looking again at my document, using version 7.0.0.3, seems to indicated > that this problems has solved itself. => RESOLVED WORKSFORME Luuk, if the problem has been gone in a newer version, you are allowed to change status to RESOLVED WORKSFORME.