https://bugs.documentfoundation.org/show_bug.cgi?id=161222

Mike Kaganski <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|[email protected] |[email protected]
                   |desktop.org                 |
             Status|NEW                         |ASSIGNED

--- Comment #2 from Mike Kaganski <[email protected]> ---
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,
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

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to