ESC meeting minutes: 2020-09-03

[Jan-Marek Glogowski]

Am 04.09.20 um 20:10 schrieb khagaroth> On Thu, Sep 3, 2020 at 11:06 PM
Jan-Marek Glogowski
> <glogow at fbihome.de <mailto:glogow at fbihome.de>> wrote:
> 
>> But coming back to the original bug / suggestion to retire the PNGs: 
>> *the quality of the SVG renderings of the icons at 100% isn't good*.
>> They look "washed out" in comparison with the unscaled, alternative
>> PNG icons
> 
> ^^ That's an understatement. SVG icons are currently absolutely
> atrocious. The first problem is that LO uses odd icon resolution
> (25x25), so the lines are not pixel aligned on export and are
> blurred/aliased.
I did a quick Bugzilla search, which came up with
https://bugs.documentfoundation.org/show_bug.cgi?id=126446, where you
also commented.

At least my impression is, that the people are much more happy with the
scaled SVGs, then with the scaled PNGs in HiDPI setups on Linux and the
result is not "atrocious"; but then I don't use Windows and this is just
my personal impression, having no background in design whatsoever.

So I tested the SVG icons at 100% and the cached PNG version of
breeze_svg/sw/res/emptypage_10x14.svg has the size 11x15 - yikes.

The SVG starts with: <svg viewBox="0 0 14 10" … which means x, y, width,
height. That is not pixel, but AFAIK the stretch related to the output size.

Looking into the problem, still hoping for a simple off-by-one error, I
ended in loadFromSvg

Somewhere in the bowels of XSvgParser::getDecomposition,
Primitive2DReference::getRange and XPrimitive2DRenderer::rasterize, all
the double precision handling eventually results in a rounding error, on
the basis of the bug report, which claims the 24px become 62px at 250%,
instead of 60px :-(

Jan-Marek

P.S. "Fun" fact: all the dumped icon ranges / rectangles at 100% scale
start at -13.2292 -13.2292, while none of the values in the SVG are
negative. If you invert that (13.2292 13.2292), you get exactly the one
additional pixel: 13.2292 * 2 * 0.03937 (100th_mmToInch) * 96 (DPI) =
99.99936
So actually I'm not that sure about the rounding error, but suspect some
signed error in XSvgParser::getDecomposition for the viewport. But that
might also be a red hering…