Steps to Reproduce: 1. New Writer. In "Format > Page Style > Text Grid", select "Grid (lines only)". Click OK to close the dialog. 2. Type in "Hello". Observe that the current font size is 10.5 pt, and font family is "Liberation Serif". 3. Select the text, change its font family to "Noto Sans CJK SC", and change font size to 14pt. Current Result: Text becomes invisible in step 3. Expected: Text should be visible in step 3. ----- This bug was initially reported in the Chinese discussion forum: https://bbs.libreofficechina.org/forum.php?mod=viewthread&tid=2887 and was confirmed on both Linux and Windows platforms. This is a regression started in version 7.2.
Bibisected and bisected to the following commit: commit 301278b656e76b6f42af5cf8a6f5c6c02acfffeb Author: Miklos Vajna <vmiklos@collabora.com> Date: Thu May 20 18:02:12 2021 +0200 sw: allow the height of a line to be larger than 65536 twips Adding Miklos Vajna to CC: would you please take a look? Thanks.
This can also be reproduced with (almost all) the other Noto fonts, such as "Noto Sans" font at size "22pt", or the "Noto Mono" font at size "22pt".
Reproduced in the following environment. Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: 84e1c79dd7394168459a3bbdea8bd94d765708e0 CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: ja-JP (ja_JP.UTF-8); UI: ja-JP TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-09-10_21:28:22 Calc: threaded Version: 7.2.0.4 / LibreOffice Community Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: ja-JP (ja_JP.UTF-8); UI: ja-JP Calc: threaded Not reproduce in the following environment. Version: 7.1.4.2 / LibreOffice Community Build ID: a529a4fab45b75fefc5b6226684193eb000654f6 CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: ja-JP (ja_JP.UTF-8); UI: ja-JP Calc: threaded
It was also reproduced in "Liberation Serif" depending on the font size. This is not just a problem with CJK fonts. It becomes the following situation when changing the font size of "Liberation Serif": 43pt: display 44pt-52pt: not display 53pt-69pt: display 70pt-79pt: not display 79pt-95pt: display 96pt-104pt:not display 105pt: display
Created attachment 174975 [details] Changed the font size of Liberation Serif
Created attachment 174976 [details] Sample file of the case where the font size of Liberation Serif is changed
(In reply to Kevin Suo from comment #2) > commit 301278b656e76b6f42af5cf8a6f5c6c02acfffeb > Author: Miklos Vajna <vmiklos@collabora.com> > Date: Thu May 20 18:02:12 2021 +0200 > > sw: allow the height of a line to be larger than 65536 twips Bug 144305 started from the same commit.
Created attachment 175275 [details] Another sample Attaching another sample, I had a fix for attachment 174976 [details], but even after that change, this sample still has hidden text.
Aron Budea committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/da110b1414ffe727abd94804022fb85472e267ee tdf#144122, tdf#144305 Revert "sw: allow the height of a line... It will be available in 7.2.3. 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.
Aron Budea committed a patch related to this issue. It has been pushed to "libreoffice-7-2-2": https://git.libreoffice.org/core/commit/702b7578754344464f0b3c39abb7bf025387a29b tdf#144122, tdf#144305 Revert "sw: allow the height of a line... It will be available in 7.2.2. 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.
This is fixed in 7.2/7.2.2 via reverting, please test with the 7.2.2.2 builds that should be available shortly at: https://dev-builds.libreoffice.org/pre-releases/ In 7.3 this will be fixed differently.
Aron Budea committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/203068319e17377cafb9e298a910f42fde417a21 tdf#144122 Use signed type to avoid stealthy underflow It will be available in 7.3.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.
This can be closed, the issue should be fixed both in 7.2 and 7.3. A unit test will follow later. An additional fix by Caolán to a coverity defect introduced in the 7.3 version of the fix: https://cgit.freedesktop.org/libreoffice/core/commit/?id=4dc362917597f0e3b890ef7d8d190749b20abce4
(In reply to Aron Budea from comment #14) > This can be closed, the issue should be fixed both in 7.2 and 7.3. A unit > test will follow later. > > An additional fix by Caolán to a coverity defect introduced in the 7.3 > version of the fix: > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=4dc362917597f0e3b890ef7d8d190749b20abce4 @Aron, @Mikos, any idea how to test this issue ?
Can you do 'SW_DEBUG=1 ./soffice.bin', open the document, press F12 and inspect layout.xml before/after? Hopefully the dumped portions differ, and then you can assert this from cppunit. E.g. testLineHeight in sw/qa/core/text/text.cxx is a test that asserts the content of a layout xml dump.
Created attachment 176144 [details] layout.xmls of previous sample from various versions Thanks for the hint, Miklos! I've extracted layout.xmls from a few versions for comparion, but I'm not sure what the relevant differences are. Versions: - 7.1.4.2: pre-regression (good), - 7.2.2.2: after revert (good), - 7.3 from 10-01: state before this fix (bad), - 7.3 from 10-26: state after this fix (good). The XMLs from 7.2.2.2 and 7.3 (10-26) is quite close, except the 7.3 one has a fairly long <SwParaPortion> at the end. This also exists in the 7.3 (10-01) layout.xml, indicating it's something introduced in 7.3. The <SwParaPortion> section is also different between the 10-01 and 10-26 state, the latter has more attributes (width, height, length, type) that are missing from the 10-01 file. One might think this difference is relevant, but the layout.xml of the "original" ruby.fodt unit test document added with the fix to bug 144305, which displays the same in both the 10-01 and the 10-26 builds (the fix was added on 09-14) also exhibits this difference. I haven't attached this other layout.xml. Between 10-01 and 10-26 there's also a difference in various bounds element attributes (left, width, right). However, curiously the attributes match between 7.1.4.2 and 7.3 (10-01), just like there's a match between the other pair, 7.2.2.2 and 7.3 (10-26). Since only one of these is the bad state, there should be no matching pairs if the difference was relevant. Have I missed something?