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

[Lodev]

Tomaž Vajngerl 於 2023/8/22 20:17 寫道:
> Hi,
>
> On Mon, Aug 21, 2023 at 10:30 PM Lodev <lodev at ossii.com.tw> 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.

Sorry if I'm asking a stupid question here.  First, I've never seen or 
used a document with "multiple instances that all point to the same 
image in the document".  And I take "the image in the document" or "The 
size the image takes up in the document" seems to be the "Apparent 
dimensions", 4.24" in this case.  Is it?  That is, even if there are 
multiple images in this document which the source is the same one (I 
still don't know how to do that), shouldn't it be calculated regarding 
to the "Apparent dimensions" here?  I mean, after all, that is what user 
set in the document. Since the image shown in the document is actually 
4.24"x4.24", while the original svg file is 0.21"x0.21, shouldn't it be 
20 times (4.24/0.21 ~= 20) DPI, that is, 96*20 = 1920 sent to xBitmap()?

We tried to set Size(20,20) to get aDPI, or directly set aDPI to 
(1920,1920), they both ended up 4.24"x4.24" with 99DPI, which is good 
enough.  Do you think it a reasonable thought?


> 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.

The size should be the Apparent dimensions, since in the document it was 
set to that size.  That's what we thought.

BTW, if so, how can we get the Apparent dimensions in this method?



Thanks for your reply,

Dev