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.
Hi,
Tomaž Vajngerl 於 2023/8/31 03:13 寫道:
Hi, On Tue, Aug 29, 2023 at 9:09 AM Lodev <lodev@xxxxxxxxxxxx> 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 "Thesize 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
