https://bugs.documentfoundation.org/show_bug.cgi?id=96892
Bug ID: 96892
Summary: Low precision in PDF export of SVG images leads to
visible artifacts at high zoom levels
Product: LibreOffice
Version: 4.0 all versions
Hardware: All
OS: Linux (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Printing and PDF export
Assignee: [email protected]
Reporter: [email protected]
Created attachment 121717
--> https://bugs.documentfoundation.org/attachment.cgi?id=121717&action=edit
test file
The attached test.odt contains two small images, an SVG on the left and a very
similar PNG on the right. It also contains a line of 10pt size text for scale.
Steps to reproduce:
1. Open test.odt in Writer
2. File -> Export as PDF
3. View the resulting PDF at 1600% zoom or higher in LibreOffice Draw, Acrobat
Reader or Inkscape
4. Lines in the SVG image (the one on the left) are noticeably wiggly, but
should in fact all be perfectly straight
Programs affected: Writer and Draw (haven't tested Calc)
Versions affected: I have noticed similar effects in all previous versions of
LibreOffice since vector export of SVG images was first introduced. My current
version is as follows:
LibreOffice version: 5.0.3.2
Build ID: 1:5.0.3~rc2-0ubuntu1~precise2
Possible cause:
When you look at the resulting PDF in Draw or Inkscape, at zooms around 3000%
you can clearly see that all control points are placed on a grid. This is not
the case in the original SVG image.
When you look at the uncompressed PDF, which can be obtained using either
pdfunzip or via
$ pdftk test.pdf output uncomp.pdf uncompress
you will see that the data are all rounded up (truncated?) to one decimal
place. I would argue that this is insufficient - e.g. my current version of
Inkscape saves three decimal places by default. Apparently so does Adobe
Distiller - see the discussion here:
https://bugs.freedesktop.org/show_bug.cgi?id=23364
Relevant code:
I suspect that this could be due to lines 512 and 513 of
vcl/source/gdi/pdfwriter_impl.cxx in core:
static const sal_Int32 nLog10Divisor = 1;
static const double fDivisor = 10.0;
The first constant is then used in PDFWriterImpl::PDFPage::appendPixelPoint()
as the precision argument when calling appendDouble.
If this is the cause, I would argue that the constants should be increased to 3
and 1000.0, respectively.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
