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

Lodev lodev at ossii.com.tw
Thu Aug 31 03:05:34 UTC 2023


Hi,

Tomaž Vajngerl 於 2023/8/31 03:13 寫道:
> Hi,
>
> On Tue, Aug 29, 2023 at 9:09 AM Lodev<lodev at ossii.com.tw>  wrote:
>> 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".
> That's easy - drag the image while holding ctrl and drop. It will make
> a copy of the Graphic, but it still references the same instance and
> you can resize each one independently. If you save the document there
> will be only one image saved.

Thanks.

> 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?
> Yes - the document has a size and combined with the size of the image
> (in the document, not what it is set in SVG) you can calculate the
> actual needed DPI relative to the document.
>
>> 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.
> That's the point - what is important is the size of the image in the
> document, not what the size is the SVG image.
>
>>   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()?
> Yes, that seems correct. But this is only for this case - another case
> would need another factor. For example if you resize the image in the
> document to 0.42 x 0.42, you would use the factor 2.
>
>> 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?
> That's only for this image where 20 is correct - you would need
> another number calculated per image. Also use a constant DPI factor as
> I already said at the beginning, not the size of the output device.
>>> 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.
> Yes - it needs to be the size in the document, not the size of SVG.
>
>> BTW, if so, how can we get the Apparent dimensions in this method?
> You will have to set it from the outside as a parameter - as it
> depends on the image and here you don't have the information.

So, that's what we thought - to calculate the necessary DPI by Apparent 
dimensions every time we export to docx.

Could you please give us some hint about where to get the Apparent 
dimensions?  It's not very trivial to us.  We'd like to give it a try to 
provide a patch for this issue.


Thanks for your help,

Dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20230831/ed8b4ae8/attachment.htm>


More information about the LibreOffice mailing list