<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi, <span style="white-space: pre-wrap">Tomaž,</span></p>
    <div class="moz-cite-prefix">Tomaž Vajngerl 於 2023/8/11 17:31 寫道:<br>
    </div>
    <blockquote type="cite"
cite="mid:CA+Ev6_Z2cq9muJd1_qsVKb99PxFvM1ZVwpkZ3DQMAGiocoHYjA@mail.gmail.com">
      <pre class="moz-quote-pre" wrap="">Hi,

On Fri, Aug 11, 2023 at 8:06 AM Lodev <a class="moz-txt-link-rfc2396E" href="mailto:lodev@ossii.com.tw"><lodev@ossii.com.tw></a> wrote:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">
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?
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
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ž
</pre>
    </blockquote>
    <p>In fact, when we were doing more test, we found the behavior
      somewhat strange.</p>
    <p>We used attachment 170646 in tdf#51510.<br>
    </p>
    <p>vcl/source/gdi/vectorgraphicdata.cxx, line 77:<br>
    </p>
    <p><font face="monospace">            // get system DPI<br>
                    Size
        aDPI(Application::GetDefaultDevice()->LogicToPixel(Size(1,
        1), MapMode(MapUnit::MapInch)));<br>
                    if (rTargetDPI.has_value())<br>
                    {<br>
                        aDPI = *rTargetDPI;<br>
                    }<br>
        <br>
                    const uno::Reference< rendering::XBitmap >
        xBitmap(<br>
                        xPrimitive2DRenderer->rasterize(<br>
                            comphelper::containerToSequence(rSequence),<br>
                            aViewParameters,<br>
                            aDPI.getWidth(),<br>
                            aDPI.getHeight(),<br>
                            aRealRect,<br>
                            nMaximumQuadraticPixels));</font></p>
    <p>First, Size aDPI:
      Application::GetDefaultDevice()->LogicToPixel(Size(1,1),
      MapMode(MapUnit::MapInch)), here we did get aDPI is (96, 96).</p>
    <p>However, after saving as docx, the PNG image information (in
      Compress Image dialog) we got is:</p>
    <p><font face="monospace">Actual dimensions: 0.21"x0.21" (21x21 px)</font></p>
    <p><font face="monospace">Apparent dimensions: 4.24" x 4.24" at 4
        DPI</font></p>
    <p>If we set LogicToPixel(Size(4,4), ...), we got:</p>
    <p><font face="monospace">Actual dimensions: 0.84"x0.84" (84x84 px)</font></p>
    <p><font face="monospace">Apparent dimensions: 4.24" x 4.24" at 19
        DPI</font></p>
    <p>Second, We then tried to directly assign 300DPI by adding</p>
    <p><font face="monospace">aDPI.setWidth(300);</font></p>
    <p><font face="monospace">aDPI.setHeight(300);</font></p>
    <p>before calling xBitmap(xPrimitive2DRenderer0>rasterize()).  We
      printed aDPI.getWidth() and aDPI.getHeight() and did got 300,
      300.  </p>
    <p>However the PNG image information saved in docx file</p>
    <p>Actual dimensions: 0.68 x 0.68 (66x66 px)</p>
    <p>Apparent dimensions: 4.24" x 4.24" at 15 DPI</p>
    <p>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?<br>
    </p>
    <p>BTW, the <font face="monospace">rTargetDPI</font> was a
      parameter of <font face="monospace">convertPrimitive2DSequenceToBitmapEx</font>,
      which  was called only once and the parameter rTargetDPI was never
      used.  </p>
    <p>That is, it is always nullptr by default, according to its
      declaration.  This parameter seems to be useless at all.</p>
    <p><br>
    </p>
    <p>Any suggestion will be appreciated.<br>
    </p>
    <br>
    <p>Thanks for your help.</p>
    Dev
    <p></p>
    <p><br>
    </p>
    <p><br>
    </p>
  </body>
</html>