Re: #tdf51510: Change the DPI to get better resolution, but failed the unit test

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Fri, Aug 11, 2023 at 8:06 AM Lodev <lodev@xxxxxxxxxxxx> wrote:
>
> Hi,
>
>
> We're trying to fix #tdf51510: "Exporting documents with embedded SVG to
> doc or docx converts the image to low-resolution pixel graphics" since
> it bothers us and it seems more and more bugs duplicated or related to
> this one.  We changed in vcl/source/gdi/vectorgraphicdata.cxx:78
>
> -            Size
> aDPI(Application::GetDefaultDevice()->LogicToPixel(Size(1, 1),
> MapMode(MapUnit::MapInch)));
> +            Size
> aDPI(Application::GetDefaultDevice()->LogicToPixel(Size(50, 50),
> MapMode(MapUnit::MapInch)));
>
> To get better resolutions.  It worked.  Exported docx file with embedded
> png now gets better resolution.
>
> However this change couldn't pass unit test :
> sw/qa/extras/ooxmlexport/ooxmlexport16.cxx:762, tdf136841.docx . It
> seems to be fixed, expecting low resolution converted images.
>
> Since it didn't pass the unit test, we didn't commit the patch to
> gerrit.  So here, first we'd like to know if this solution, changing
> size(1,1) to size(50,50) is acceptable or not?

I wouldn't do it like that. The purpose of that LogicToPixel
conversion is to figure out the DPI (number of pixels/inch) of the
output device - changing that to 50 doesn't make sense considering
what that call tries to achieve (you ask what's the number of pixels
per 50inches).
The next issue is that this will result in a 50x bigger size - that's
a lot! Typically the device DPI is 96 - this makes it 50*96 = 4800,
which means a 3 x 3 inch image (not that A4 paper size is 8.3 x 11.7
inch, so 3x3 inch image is typical) will have the resolution of
14400x14400 pixels!
Note also that in ODF we store a PNG bitmap for vector images in
addition the the vector image, which serves as a fall-back. For that
we go through the same code path, so the file size would increase
significantly.

What I suggest is to not depend on the output device DPI (which causes
us a lot of trouble because the result then depends on the system and
OS) and set a constant but high enough DPI, that will be good enough
in most cases. 300DPI is usually good enough for printing so I think
that would be a good constant to use here (it's 3x bigger than typical
96DPI of an output device).

> If yes, how can we pass the unit test given that patch?

As for the test - the purpose of that test is to check that the vector
image (WMF in the document) is rendered after the import-export cycle,
by checking that the pixel in the middle of the bitmap is set to
something visible that could be part of the image. As the pixel size
of the bitmap changes, because of the increase of DPI, this test needs
to be adapted for the new size.

> Thanks for your suggestion.
>
>
> Dev

Tomaž




[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux