Created attachment 194286 [details] Sample ODS with chart Open the attached document in gtktiledviewer in a local build, eg. using the following command: bin/run gtktiledviewer --lo-path=$PWD/instdir/program <file name with location> Note how the text in the chart (axis labels, legend) are missing, partially missing, misplaced, or a combination of these, at different zoom levels. Observed using LO 24.8.0.0.alpha1+ (551c8230b495e8c0e0502b73445f6edd1510633e) / Ubuntu. This is a regression from the following commit: https://cgit.freedesktop.org/libreoffice/core/commit/?id=cc3663bbaed4f65d64154e5f9abb51a5f622f710 author Mike Kaganski <mike.kaganski@collabora.com> 2024-04-16 10:48:06 +0500 committer Mike Kaganski <mike.kaganski@collabora.com> 2024-04-20 11:28:34 +0200 "tdf#160702: improve text positioning" Making the following conditional also dependent on !comphelper::LibreOfficeKit::isActive() fixes the issue, but I'm not sure if that's a consistent fix (in that case it should also precede declaration of nFontScalingFixY/X): https://opengrok.libreoffice.org/xref/core/drawinglayer/source/processor2d/vclprocessor2d.cxx?r=2092df2a#418
Created attachment 194287 [details] Screenshot from gtktiledviewer
I tried to debug this for some time. The problem is not an incorrect scaling, as I suspected initially; it seems that the offset of the text start point is wrong for all but the first tile, when the additional transform is applied, for unclear reason. But I still wasn't able to track down where it gets wrong. This is a sample of the data, showing my confusion. With the attachment 194286 [details], and the gtktiledviewer's scale of 75%, this is what debugging ScGridWindow::PaintTile and VclProcessor2D::RenderTextSimpleOrDecoratedPortionPrimitive2D gives for the chart's "2024-01-06" label, which happens to span over both the first and the second tiles of the first row: > Thread 10 "pool-gtktiledvi" hit Breakpoint 54, ScGridWindow::PaintTile (this=0x7f7054582970, rDevice=..., nOutputWidth=256, nOutputHeight=256, nTilePosX=0, nTilePosY=0, nTileWidth=5120, nTileHeight=5120, nTiledRenderingAreaEndCol=32, nTiledRenderingAreaEndRow=122) at /home/mk/core/sc/source/ui/view/gridwin4.cxx:1503 > 1503 Fraction origZoomX = mrViewData.GetZoomX(); > nTilePosX = 0, nTilePosY = 0 > > Thread 10 "pool-gtktiledvi" hit Breakpoint 56, drawinglayer::processor2d::VclProcessor2D::RenderTextSimpleOrDecoratedPortionPrimitive2D (this=0x7f704c112980, rTextCandidate=...) at /home/mk/core/drawinglayer/source/processor2d/vclprocessor2d.cxx:431 > 431 aPointX /= nFontScalingFixX; > aText = "2024-01-06", aPoint = [245.84768493912429, 251.22139880578754], nFontScalingFixX = 1.0005430613192137, nFontScalingFixY = 1.0005430601368466, aPointX = 245.71424703597933, aPointY = 251.08504452714649 > > Thread 10 "pool-gtktiledvi" hit Breakpoint 54, ScGridWindow::PaintTile (this=0x7f7054582970, rDevice=..., nOutputWidth=256, nOutputHeight=256, nTilePosX=5120, nTilePosY=0, nTileWidth=5120, nTileHeight=5120, nTiledRenderingAreaEndCol=32, nTiledRenderingAreaEndRow=122) at /home/mk/core/sc/source/ui/view/gridwin4.cxx:1503 > 1503 Fraction origZoomX = mrViewData.GetZoomX(); > nTilePosX = 5120, nTilePosY = 0 > > Thread 10 "pool-gtktiledvi" hit Breakpoint 56, drawinglayer::processor2d::VclProcessor2D::RenderTextSimpleOrDecoratedPortionPrimitive2D (this=0x7f704c112980, rTextCandidate=...) at /home/mk/core/drawinglayer/source/processor2d/vclprocessor2d.cxx:431 > 431 aPointX /= nFontScalingFixX; > aText = "2024-01-06", aPoint = [-10.152315060875694, 251.22139880578754], nFontScalingFixX = 1.0005430613192137, nFontScalingFixY = 1.0005430601368466, aPointX = -10.146804723716629, aPointY = 251.08504452714649 One may see, that for the second tile (nTilePosX = 5120, nTilePosY = 0), before the correction, the value of aPoint is [-10.152315060875694, 251.22139880578754]. Without the correction, aStartPoint would be built directly by rounding that value, so would be [-10, 251]. The correction applies the scaling of [1.0005430613192137, 1.0005430601368466] (changing the values only by 0.05%); and the corrected coordinates before the rounding are [-10.146804723716629, 251.08504452714649]. This gives the same resulting aStartPoint of [-10, 251]! I expect it to draw ~identically on the second tile, as without the correction (the difference would be only in *sub-pixel* positioning of the second and further characters); but in fact, the whole text somehow gets output with the shift of about 200 pixels to the left, completely outside of the second tile. I finally decided to follow the solution that Aron suggested - thank you! https://gerrit.libreoffice.org/c/core/+/168041
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c9571914b8170128a68496ec2dd299e21243d1c1 tdf#161222: LOK: do not fine-tune text scaling for tile rendering It will be available in 24.8.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.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/1d979d1e6e6d9ca128f46d99f443409ace3988b0 tdf#161222: LOK: do not fine-tune text scaling for tile rendering It will be available in 24.2.5. 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.
So, before the correction, the value of aPoint for the second tile (nTilePosX = 5120, nTilePosY = 0) is [-10.152315060875694, 251.22139880578754]. Without the adjustment, the range [-10, 251] and aStartPoint would be constructed simply by rounding off the given value. Thanks to Aron, I finally followed your solution! https://gerrit.libreoffice.org/c/core/+/168041 https://basketball-starsgame.com/
Mapquest Directions - Get lost no more! https://mapquest-directions.org is your one-stop shop for finding driving directions and easily exploring.