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

[sos]

Sorry to come back to this: every document has a property called "Image 
Preferred DPI" that can be used to represent the printing intentions of 
that document.

Apparent dimensions are a result of deviding the available pixels in the 
Image by the print intentions .
if the user like to send the document to a professional printing house 
then all  images need to have a DPI of minimal 254, laser printers need 
150 DPI  and on screen presentations 96 DPI

Tomaz has this implemented a feature called "Image Preferred DPI" so  
the dimensions of an image in the document can been checked/controled  
by the number of pixels in the image and the print intentions off a 
document.

With a Preferred DPI of 254 and 2450 pixels in the image, the image can 
be displayed at a maximum size of 10 inches. If the image is smaller, 
then fewer than 2450 pixels are needed.
So the "Image Preferred DPI" can be used to determine the "Print 
Intentions" for a Document, and it can easily calculate how many DPI or 
pixels an image needs.
grtz
Fernand

On 31/08/2023 5:05, Lodev wrote:
>
> 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/ff3d237f/attachment.htm>