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

[Tomaž Vajngerl <quikee@xxxxxxxxx>]

Hi,

On Mon, Aug 21, 2023 at 10:30 PM Lodev <lodev@xxxxxxxxxxxx> wrote:
>
> In fact, when we were doing more test, we found the behavior somewhat strange.
>
> We used attachment 170646 in tdf#51510.
>
> vcl/source/gdi/vectorgraphicdata.cxx, line 77:
>
>             // get system DPI
>             Size aDPI(Application::GetDefaultDevice()->LogicToPixel(Size(1, 1), MapMode(MapUnit::MapInch)));
>             if (rTargetDPI.has_value())
>             {
>                 aDPI = *rTargetDPI;
>             }
>
>             const uno::Reference< rendering::XBitmap > xBitmap(
>                 xPrimitive2DRenderer->rasterize(
>                     comphelper::containerToSequence(rSequence),
>                     aViewParameters,
>                     aDPI.getWidth(),
>                     aDPI.getHeight(),
>                     aRealRect,
>                     nMaximumQuadraticPixels));
>
> First, Size aDPI: Application::GetDefaultDevice()->LogicToPixel(Size(1,1), MapMode(MapUnit::MapInch)), here we did get aDPI is (96, 96).
>
> However, after saving as docx, the PNG image information (in Compress Image dialog) we got is:
>
> Actual dimensions: 0.21"x0.21" (21x21 px)
>
> Apparent dimensions: 4.24" x 4.24" at 4 DPI
>
> If we set LogicToPixel(Size(4,4), ...), we got:
>
> Actual dimensions: 0.84"x0.84" (84x84 px)
>
> Apparent dimensions: 4.24" x 4.24" at 19 DPI

Ah yes - I think I know what's the issue. For example if you have a
small SVG file that has a size of 1" by 1" (you can specify that
exactly for a SVG file) and you import that into LO, you probably want
to increase its size to something bigger inside the document (for
example you increase it to 10" x 10" for simplicity), which you can
freely do as the SVG image is a vector image and it will still look
good.

However, this calculation here is not performed compared to the size
the image is taking up in the document (10" x 10"), but compared to
its original size (1" x 1"), so the Apparent DPI is smaller.

So to solve this properly you would need to actually get the size the
image takes up in the document, and calculate and set all the sizes
from the outside. The reason this doesn't and can't work as expected
here is that you can have multiple instances that all point to the
same image in the document, but the size of the image in the document
is different.

So you will need to first find the place where conversion for the
embedded PNG and properly calculate the size at that place - not
inside this method.

> Second, We then tried to directly assign 300DPI by adding
>
> aDPI.setWidth(300);
>
> aDPI.setHeight(300);
>
> before calling xBitmap(xPrimitive2DRenderer0>rasterize()).  We printed aDPI.getWidth() and aDPI.getHeight() and did got 300, 300.
>
> However the PNG image information saved in docx file
>
> Actual dimensions: 0.68 x 0.68 (66x66 px)
>
> Apparent dimensions: 4.24" x 4.24" at 15 DPI

Just to note - this is correct concerning what it did with the "Actual
dimension" ... at SIze(1,1) it was 21x21px, at Size(4,4) it was 4x
bigger (84x84) and at fixed 300 DPI the size was 66x66, which is a bit
more than 3x bigger as 300DPI is 3x bigger than the standard 96DPI.

> BTW, the rTargetDPI was a parameter of convertPrimitive2DSequenceToBitmapEx, which  was called only once and the parameter rTargetDPI was never used.
>
> That is, it is always nullptr by default, according to its declaration.  This parameter seems to be useless at all.

Right - that's useless and can be removed

> Thanks for your help.
>
> Dev