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

[Tomaž Vajngerl]

Hi,

On Tue, Sep 12, 2023 at 6:23 AM Lodev  wrote:
>
> Hi,
>
> Following sos' suggestion, we tried to get Image Preferred DPI from file 
> properties.  We thought to use this value directly to draw bitmap.  After 
> asking the last question we found a sample in sfx2/source/dialog/dinfdlg.cxx 
> to get this property value.  So we added the following code to get the DPI:
>
>
>/* get Image Preferred DPI from File/Properties.  User can specify 
> DPI they wanted
> * to exported. */
>SfxObjectShell* pDocSh = SfxObjectShell::Current();
>sal_Int32 nImagePreferredDPI = 0;
>if (pDocSh)
>{
>try
>{
>uno::Reference< lang::XMultiServiceFactory > xFac( 
> pDocSh->GetModel(), uno::
> UNO_QUERY_THROW );
>uno::Reference< beans::XPropertySet > xProps( 
> xFac->createInstance("com.sun.
> star.document.Settings"), uno::UNO_QUERY_THROW );
>xProps->getPropertyValue("ImagePreferredDPI") >>= 
> nImagePreferredDPI;
>}
>catch( uno::Exception& )
>{
>}
>}
>
> then sent the nImagePreferredDPI to generate the bitmap.  It worked!  At 
> least we can use designated DPI to get a better bitmap quality.
>
> Then when we tried to patch it to latest libreoffice.core and compile it, it 
> failed to link:
>
> /usr/bin/ld: 
> /home/lodev/git/libreoffice.core/workdir/CxxObject/vcl/source/gdi/vectorgraphicdata.o:
>  in function 
> `convertPrimitive2DSequenceToBitmapEx(std::deque,
>  
> std::allocator
>  > > const&, basegfx::B2DRange const&, unsigned int, o3tl::Length, 
> std::optional const&)':
> vectorgraphicdata.cxx:(.text+0x226d): undefined reference to 
> `SfxObjectShell::Current()'
> /usr/bin/ld: vectorgraphicdata.cxx:(.text+0x228f): undefined reference to 
> `SfxObjectShell::GetModel() const'
> collect2: error: ld returned 1 exit status
> make[1]: *** 
> [/home/lodev/git/libreoffice.core/vcl/Library_vcl.mk:20：/home/lodev/git/libreoffice.core/instdir/program/libvcllo.so]
>  錯誤 1
>
> We thought that the time we succeeded should be because the related objects 
> (sfx2) had been there when we tried, so it could compiled and linked 
> successfully.  This time we did it from starting so it failed because the 
> object files were no longer there, and we have no idea how to make sfx 
> objects compile first.
>
> So again we're stuck.  We did prove the idea, using Image Preferred DPI to 
> generate better bitmap, works.  User can specify a bigger DPI there to get 
> better bitmap resolutions after exporting to OOXML.  Just that maybe we 
> shouldn't use sfx object to get the property.  But we have no idea how to get 
> the property value since we're not very familiar with the reference things.
>
> Would anyone please give a little help and hints here?

You're looking at the wrong place. Forget "ImagePreferredDPI" for now
- this will get relevant once you already have a working solution. The
place that is relevant for this is in oox module - more specifically
in the drawingml export [1]. The GraphicExport::writeToStorage is very
relevant as this is where the call to convert the graphic is made. So
this needs changing and you need to find where the document dimensions
for the image are and transport that all the way to
GraphicExport::writeToStorage. For writer also
DocxAttributeOutput::FlyFrameGraphic is relevant (in sw module) and
maybe some other cases also, for Impress and Calc something else might
be relevant too.

[1] oox/source/export/drawingml.cxx

> Thanks, Dev

Tomaž

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

[Lodev]

Hi,

Following sos' suggestion, we tried to get Image Preferred DPI from file 
properties.  We thought to use this value directly to draw bitmap.  
After asking the last question we found a sample in 
sfx2/source/dialog/dinfdlg.cxx to get this property value.  So we added 
the following code to get the DPI:



/* get Image Preferred DPI from File/Properties.  User can specify DPI 
they wanted

* to exported. */
   SfxObjectShell* pDocSh = SfxObjectShell::Current();
   sal_Int32 nImagePreferredDPI = 0;
if(pDocSh)
   {
try
   {
   uno::Reference< lang::XMultiServiceFactory > 
xFac( pDocSh->GetModel(), uno::

UNO_QUERY_THROW );
   uno::Reference< beans::XPropertySet > 
xProps( xFac->createInstance("com.sun.

star.document.Settings"), uno::UNO_QUERY_THROW );
   xProps->getPropertyValue("ImagePreferredDPI") >>= 
nImagePreferredDPI;
   }
catch( uno::Exception& )
   {
   }
   }

then sent the nImagePreferredDPI to generate the bitmap.  It worked!  At 
least we can use designated DPI to get a better bitmap quality.


Then when we tried to patch it to latest libreoffice.core and compile 
it, it failed to link:


/usr/bin/ld: 
/home/lodev/git/libreoffice.core/workdir/CxxObject/vcl/source/gdi/vectorgraphicdata.o: 
in function 
`convertPrimitive2DSequenceToBitmapEx(std::deque, 
std::allocator 
> > const&, basegfx::B2DRange const&, unsigned int, o3tl::Length, 
std::optional const&)':
vectorgraphicdata.cxx:(.text+0x226d): undefined reference to 
`SfxObjectShell::Current()'
/usr/bin/ld: vectorgraphicdata.cxx:(.text+0x228f): undefined reference 
to `SfxObjectShell::GetModel() const'

collect2: error: ld returned 1 exit status
make[1]: *** 
[/home/lodev/git/libreoffice.core/vcl/Library_vcl.mk:20：/home/lodev/git/libreoffice.core/instdir/program/libvcllo.so] 
錯誤 1


We thought that the time we succeeded should be because the related 
objects (sfx2) had been there when we tried, so it could compiled and 
linked successfully.  This time we did it from starting so it failed 
because the object files were no longer there, and we have no idea how 
to make sfx objects compile first.


So again we're stuck.  We did prove the idea, using Image Preferred DPI 
to generate better bitmap, works.  User can specify a bigger DPI there 
to get better bitmap resolutions after exporting to OOXML.  Just that 
maybe we shouldn't use sfx object to get the property.  But we have no 
idea how to get the property value since we're not very familiar with 
the reference things.


Would anyone please give a little help and hints here?


Thanks, Dev


Lodev 於 2023/9/11 21:32 寫道:

Hi,

sos 於 2023/8/31 17:53 寫道:


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



Sorry for disturbing again, but we're not experienced enough.

Following your instruction, we thought about getting the "Image 
Preferred DPI" property and used it as aDPI when creating bitmaps.  
That way, at least user could try to assign a large DPI to get better 
resolution.  However we failed to find out how to get it.  We know it 
is in File-Properties and we know it is set in 
sfx2/source/dialog/dinfdlg.cxx,


    xProps->setPropertyValue("ImagePreferredDPI", 
uno::Any(nImagePreferredDPI));


But we couldn't find out how to get this "ImagePreferredDPI" property 
value and use it in vcl/source/gdi/vectorgraphicdata.cxx.  A little 
more help here please?



Dev

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

[Lodev]

Hi,

sos 於 2023/8/31 17:53 寫道:


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



Sorry for disturbing again, but we're not experienced enough.

Following your instruction, we thought about getting the "Image 
Preferred DPI" property and used it as aDPI when creating bitmaps.  That 
way, at least user could try to assign a large DPI to get better 
resolution.  However we failed to find out how to get it.  We know it is 
in File-Properties and we know it is set in sfx2/source/dialog/dinfdlg.cxx,


    xProps->setPropertyValue("ImagePreferredDPI", 
uno::Any(nImagePreferredDPI));


But we couldn't find out how to get this "ImagePreferredDPI" property 
value and use it in vcl/source/gdi/vectorgraphicdata.cxx.  A little more 
help here please?



Dev

Re: #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  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

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

[Lodev]

Hi,

Tomaž Vajngerl 於 2023/8/31 03:13 寫道:

Hi,

On Tue, Aug 29, 2023 at 9:09 AM Lodev  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

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

[Tomaž Vajngerl]

Hi,

On Tue, Aug 29, 2023 at 9:09 AM Lodev  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.

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

> Thanks for your reply,

Tomaž

Re: #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  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

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

[Tomaž Vajngerl]

Hi Fernand,

On Tue, Aug 22, 2023 at 3:15 PM sos  wrote:
>
> Yes,
>
> but when using this settings you can avoid to have SVG's with a resolution 
> who is not adapted to the print-intentsions off the docment.
> 254-300 Pixels par Inch for commercial printing
> 150 Pixels par Inch for Laser printing
> 96 Pixels par Inch for screen viewing only.

Well, SVG is vector graphic so it will be rendered in maximum quality
to the output device just like fonts and other vector based objects
like shapes in the document. So this is not a problem (in SVG case)
for printing and viewing. The issue that is discussed here is when we
convert the SVG vector graphic to a PNG bitmap, which is used in
document formats that don't support SVG natively. In those cases we
convert to a bitmap and need to decide on the resolution used.

> Do you mean also that the SVG's are  not included in the  "Graphic SIze 
> Check.."?

I checked and they are, but I don't think they should've been (at
least not in the same way as bitmaps). However, as I talked in the
previous mail - to determine the size of the pixels of the SVG image
(which doesn't have a specific pixel size by it own), the SVG image is
rendered to a bitmap, and for that it uses the DPI resolution of the
default screen output device, and the size taken is the size of the
SVG (width and height). So the pixel size of a SVG does not make much
sense.

> grtz
>
> Fernand

Tomaž

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

[sos]

Yes,

but when using this settings you can avoid to have SVG's with a 
resolution who is not adapted to the print-intentsions off the docment.

254-300 Pixels par Inch for commercial printing
150 Pixels par Inch for Laser printing
96 Pixels par Inch for screen viewing only.

Do you mean also that the SVG's are  not included in the "Graphic SIze 
Check.."?


grtz

Fernand




On 22/08/2023 14:22, Tomaž Vajngerl wrote:

Hi,

On Tue, Aug 22, 2023 at 11:43 AM sos  wrote:

Hi, Tomaž,

maybe you over looked that there is now a user defined property
'*Image Preferred DPI*" for the document, so the resolution off
any image must depend on this settings, who are standard 96 DPI.

I know - I added that :) However that setting is currently only used 
for "Graphic SIze Check.." to warn if the document has an image that 
is too big or too small in resolution (not exactly what is set but 
there are margins around that value that are still allowed).


greetz

Fernand


Regards, Tomaž

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

[Tomaž Vajngerl]

Hi,

On Tue, Aug 22, 2023 at 11:43 AM sos  wrote:

> Hi, Tomaž,
>
> maybe you over looked that there is now a user defined property '*Image
> Preferred DPI*" for the document, so the resolution off any image must
> depend on this settings, who are standard 96 DPI.
>
I know - I added that :) However that setting is currently only used for
"Graphic SIze Check.." to warn if the document has an image that is too big
or too small in resolution (not exactly what is set but there are margins
around that value that are still allowed).

> greetz
>
> Fernand
>

Regards, Tomaž

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

[Tomaž Vajngerl]

Hi,

On Mon, Aug 21, 2023 at 10:30 PM Lodev  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

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

[sos]

Hi, Tomaž,

maybe you over looked that there is now a user defined property '*Image 
Preferred DPI*" for the document, so the resolution off any image must 
depend on this settings, who are standard 96 DPI.


greetz

Fernand

On 18/08/2023 16:01, Lodev wrote:



U ontvangt niet vaak e-mail van lo...@ossii.com.tw. Meer informatie 
over waarom dit belangrijk is 




Hi, Tomaž,

Tomaž Vajngerl 於 2023/8/11 17:31 寫道:

Hi,

On Fri, Aug 11, 2023 at 8:06 AM Lodev  wrote:

Hi,


We're trying to fix #tdf51510: "Exporting documents with embedded SVG to
doc or docx converts the image to low-resolution pixel graphics" since
it bothers us and it seems more and more bugs duplicated or related to
this one.  We changed in vcl/source/gdi/vectorgraphicdata.cxx:78

-Size
aDPI(Application::GetDefaultDevice()->LogicToPixel(Size(1, 1),
MapMode(MapUnit::MapInch)));
+Size
aDPI(Application::GetDefaultDevice()->LogicToPixel(Size(50, 50),
MapMode(MapUnit::MapInch)));

To get better resolutions.  It worked.  Exported docx file with embedded
png now gets better resolution.

However this change couldn't pass unit test :
sw/qa/extras/ooxmlexport/ooxmlexport16.cxx:762, tdf136841.docx . It
seems to be fixed, expecting low resolution converted images.

Since it didn't pass the unit test, we didn't commit the patch to
gerrit.  So here, first we'd like to know if this solution, changing
size(1,1) to size(50,50) is acceptable or not?

I wouldn't do it like that. The purpose of that LogicToPixel
conversion is to figure out the DPI (number of pixels/inch) of the
output device - changing that to 50 doesn't make sense considering
what that call tries to achieve (you ask what's the number of pixels
per 50inches).
The next issue is that this will result in a 50x bigger size - that's
a lot! Typically the device DPI is 96 - this makes it 50*96 = 4800,
which means a 3 x 3 inch image (not that A4 paper size is 8.3 x 11.7
inch, so 3x3 inch image is typical) will have the resolution of
14400x14400 pixels!
Note also that in ODF we store a PNG bitmap for vector images in
addition the the vector image, which serves as a fall-back. For that
we go through the same code path, so the file size would increase
significantly.

What I suggest is to not depend on the output device DPI (which causes
us a lot of trouble because the result then depends on the system and
OS) and set a constant but high enough DPI, that will be good enough
in most cases. 300DPI is usually good enough for printing so I think
that would be a good constant to use here (it's 3x bigger than typical
96DPI of an output device).

Tomaž


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

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

Is the above way to correctly "set a constant but high enough DPI"?  
But even if I assigned 300DPI the result DPI is still very low.  So, 
what is the exactly way to set constant 300DPI?


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.



Any suggestion will be appreciated.


Thanks for your help.

Dev

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

[Lodev]

Hi, Tomaž,

Tomaž Vajngerl 於 2023/8/11 17:31 寫道:

Hi,

On Fri, Aug 11, 2023 at 8:06 AM Lodev  wrote:

Hi,


We're trying to fix #tdf51510: "Exporting documents with embedded SVG to
doc or docx converts the image to low-resolution pixel graphics" since
it bothers us and it seems more and more bugs duplicated or related to
this one.  We changed in vcl/source/gdi/vectorgraphicdata.cxx:78

-Size
aDPI(Application::GetDefaultDevice()->LogicToPixel(Size(1, 1),
MapMode(MapUnit::MapInch)));
+Size
aDPI(Application::GetDefaultDevice()->LogicToPixel(Size(50, 50),
MapMode(MapUnit::MapInch)));

To get better resolutions.  It worked.  Exported docx file with embedded
png now gets better resolution.

However this change couldn't pass unit test :
sw/qa/extras/ooxmlexport/ooxmlexport16.cxx:762, tdf136841.docx . It
seems to be fixed, expecting low resolution converted images.

Since it didn't pass the unit test, we didn't commit the patch to
gerrit.  So here, first we'd like to know if this solution, changing
size(1,1) to size(50,50) is acceptable or not?

I wouldn't do it like that. The purpose of that LogicToPixel
conversion is to figure out the DPI (number of pixels/inch) of the
output device - changing that to 50 doesn't make sense considering
what that call tries to achieve (you ask what's the number of pixels
per 50inches).
The next issue is that this will result in a 50x bigger size - that's
a lot! Typically the device DPI is 96 - this makes it 50*96 = 4800,
which means a 3 x 3 inch image (not that A4 paper size is 8.3 x 11.7
inch, so 3x3 inch image is typical) will have the resolution of
14400x14400 pixels!
Note also that in ODF we store a PNG bitmap for vector images in
addition the the vector image, which serves as a fall-back. For that
we go through the same code path, so the file size would increase
significantly.

What I suggest is to not depend on the output device DPI (which causes
us a lot of trouble because the result then depends on the system and
OS) and set a constant but high enough DPI, that will be good enough
in most cases. 300DPI is usually good enough for printing so I think
that would be a good constant to use here (it's 3x bigger than typical
96DPI of an output device).

Tomaž


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

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

Is the above way to correctly "set a constant but high enough DPI"?  But 
even if I assigned 300DPI the result DPI is still very low.  So, what is 
the exactly way to set constant 300DPI?


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.



Any suggestion will be appreciated.


Thanks for your help.

Dev

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

[Tomaž Vajngerl]

Hi,

On Fri, Aug 11, 2023 at 8:06 AM Lodev  wrote:
>
> Hi,
>
>
> We're trying to fix #tdf51510: "Exporting documents with embedded SVG to
> doc or docx converts the image to low-resolution pixel graphics" since
> it bothers us and it seems more and more bugs duplicated or related to
> this one.  We changed in vcl/source/gdi/vectorgraphicdata.cxx:78
>
> -Size
> aDPI(Application::GetDefaultDevice()->LogicToPixel(Size(1, 1),
> MapMode(MapUnit::MapInch)));
> +Size
> aDPI(Application::GetDefaultDevice()->LogicToPixel(Size(50, 50),
> MapMode(MapUnit::MapInch)));
>
> To get better resolutions.  It worked.  Exported docx file with embedded
> png now gets better resolution.
>
> However this change couldn't pass unit test :
> sw/qa/extras/ooxmlexport/ooxmlexport16.cxx:762, tdf136841.docx . It
> seems to be fixed, expecting low resolution converted images.
>
> Since it didn't pass the unit test, we didn't commit the patch to
> gerrit.  So here, first we'd like to know if this solution, changing
> size(1,1) to size(50,50) is acceptable or not?

I wouldn't do it like that. The purpose of that LogicToPixel
conversion is to figure out the DPI (number of pixels/inch) of the
output device - changing that to 50 doesn't make sense considering
what that call tries to achieve (you ask what's the number of pixels
per 50inches).
The next issue is that this will result in a 50x bigger size - that's
a lot! Typically the device DPI is 96 - this makes it 50*96 = 4800,
which means a 3 x 3 inch image (not that A4 paper size is 8.3 x 11.7
inch, so 3x3 inch image is typical) will have the resolution of
14400x14400 pixels!
Note also that in ODF we store a PNG bitmap for vector images in
addition the the vector image, which serves as a fall-back. For that
we go through the same code path, so the file size would increase
significantly.

What I suggest is to not depend on the output device DPI (which causes
us a lot of trouble because the result then depends on the system and
OS) and set a constant but high enough DPI, that will be good enough
in most cases. 300DPI is usually good enough for printing so I think
that would be a good constant to use here (it's 3x bigger than typical
96DPI of an output device).

> If yes, how can we pass the unit test given that patch?

As for the test - the purpose of that test is to check that the vector
image (WMF in the document) is rendered after the import-export cycle,
by checking that the pixel in the middle of the bitmap is set to
something visible that could be part of the image. As the pixel size
of the bitmap changes, because of the increase of DPI, this test needs
to be adapted for the new size.

> Thanks for your suggestion.
>
>
> Dev

Tomaž