Created attachment 181411 [details] Sample ODT Open the attached document in gtktiledviewer in a local build, eg. using the following command: bin/run gtktiledviewer $PWD/instdir/program <file name with location> Find the → near the end of the document, and press Enter after it. => Note how the top row of pixels in the line "123456789" disappears (visible in digits 1 and 4). This started happening after the following commit in 7.4: https://cgit.freedesktop.org/libreoffice/core/commit/?id=bb495c6a2f00346698a041bce69a5a97effc79d7 author Caolán McNamara <caolanm@redhat.com> 2022-01-17 12:48:43 +0000 committer Caolán McNamara <caolanm@redhat.com> 2022-01-17 17:23:18 +0100 "tdf#144862 set default render mode to LayoutAndMatchRender" Since this commit only sets the new glyph positioning mode as default, the bug can be checked in older builds by setting the config item 'GlyphPositioningMode' to 2 manually. This config was introduced by the first commit in this series, and has been removed since: https://cgit.freedesktop.org/libreoffice/core/commit/?id=39a57fa8c047227060915534e64c4e90affa4b1a Since the characters are shown correctly in the above "earliest" commit, the bug could be bibisected further, which pointed to the following commit: https://cgit.freedesktop.org/libreoffice/core/commit/?id=935761709fb7629c8d23aa5dc8bfcbd2988f5bbf author Caolán McNamara <caolanm@redhat.com> 2022-01-12 20:44:37 +0000 committer Caolán McNamara <caolanm@redhat.com> 2022-01-13 20:26:25 +0100 "tdf#144862 adjust positioning experimental options"
Created attachment 181412 [details] Screenshot (buggy)
Created attachment 181413 [details] Screenshot (as the numbers should look like)
https://cgit.freedesktop.org/libreoffice/core/commit/?id=496426503675c6da60c6f3cd78549c8a70a8c694 was a little similar to this, but doesn't seem to be the issue in this case
seems to be actually rendered like this, i.e. not something we're cutting off
https://gitlab.freedesktop.org/cairo/cairo/-/issues/390 is very similar sounding
In CairoTextRender::DrawTextLayout(), if we hit the case that eHintStyle is CAIRO_HINT_STYLE_DEFAULT, then we'll transition to CAIRO_HINT_STYLE_SLIGHT, and the output is bad. If default is handled like none or slight, then we don't call cairo_font_options_set_hint_style(), and the output is good. I need to read more code to understand if this would be a correct fix or not, perhaps you know. :-)
Created attachment 181418 [details] Simpler test document. With this, you don't need to do any interaction, you can just run 'bin/run gtktiledviewer --lo-path=$PWD/instdir/program /path/to/test.odt' and see the good/bad output immediately.
https://gerrit.libreoffice.org/c/core/+/137467 is a possible fix for this bug
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/59cfcd863b483a99491e6f8cd30016386bbff870 tdf#150145 text appears to have a row of pixels cropped out It will be available in 7.5.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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/d51b00f635e665c19cec078979210df9f79a3aa3 tdf#150145 text appears to have a row of pixels cropped out It will be available in 7.4.0.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.