https://bugs.documentfoundation.org/show_bug.cgi?id=108638
--- Comment #21 from V Stuart Foote <vstuart.fo...@utsa.edu> ---
(In reply to V Stuart Foote from comment #20)
> @Koehi, Eike -- the needDevAdice to you both.
>
> How bad would the performance impact on Calc be for toggling the WYSIWYG of
> the Use printer metrics enabled by default?
>
> Failing that, is there another way to hold the cell multiline text in better
> proportion to the cell size while scaling for zoom in or out that would not
> be a performance drag?
So reading through the code looks like the magic happens in docsh3.cxx in
CalcOutputFactor, comparing a "printer" output width of a test string to a
"window" output width of the same test string and calculating a ratio for
When use printer metrics is not enabled, the PrtToScreenFactor gets a fixed 1.0
-- so assume elsewhere it skips height recalculations that are forced when
printer metrics are enabled.
But, wonder if there _also_ are some the same rounding issues for cell width
when UI is scaled for zooms, like were just fixed for DirectWrite font height
on Windows.
=-ref-=
https://opengrok.libreoffice.org/xref/core/sc/source/ui/docshell/docsh3.cxx?a=true&h=361#353
https://opengrok.libreoffice.org/xref/core/sc/source/ui/docshell/docsh.cxx?a=true&h=621#2649
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
