Bug 57021 - Path Rendering (of converted text) is erroneous
Summary: Path Rendering (of converted text) is erroneous
Status: RESOLVED DUPLICATE of bug 96892
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
(earliest affected) release
Hardware: x86 (IA32) Windows (All)
: medium normal
Assignee: Not Assigned
Depends on:
Reported: 2012-11-12 16:26 UTC by bugs
Modified: 2018-02-04 22:30 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Enhanced Metafile (28.65 KB, image/x-emf)
2012-11-12 16:26 UTC, bugs
PDF the rendering errors (13.11 KB, application/pdf)
2012-11-12 16:29 UTC, bugs
01 - SVG testcase (15.24 KB, image/svg+xml)
2015-01-06 04:31 UTC, Martin
02 - SVG test case in eog at 2000% zoom (70.73 KB, image/png)
2015-01-06 04:32 UTC, Martin
03 - SVG test case in chromium at 500% zoom (27.30 KB, image/png)
2015-01-06 04:34 UTC, Martin
04 - SVG test case in LO Draw at 750% zoom = FIRST TWO BUGS (34.44 KB, image/png)
2015-01-06 04:35 UTC, Martin
05 - SVG test case in LO Draw at 3000% zoom = starting point for later files (53.75 KB, image/png)
2015-01-06 04:37 UTC, Martin
06 - PDF exported by LO Draw (8.23 KB, application/pdf)
2015-01-06 04:39 UTC, Martin
07 - the exported PDF in Acrobat Reader at 3200% zoom (39.77 KB, image/png)
2015-01-06 04:40 UTC, Martin
08 - the original SVG in Inkscape at 8000% zoom (42.96 KB, image/png)
2015-01-06 04:43 UTC, Martin
09 - the exported PDF in Inkscape at 6000% zoom = MAIN BUG (66.25 KB, image/png)
2015-01-06 04:44 UTC, Martin
10 - the exported PDF, uncompressed using pdftk (16.67 KB, application/pdf)
2015-01-06 04:48 UTC, Martin

Note You need to log in before you can comment on or make changes to this bug.
Description bugs 2012-11-12 16:26:58 UTC
Created attachment 69948 [details]
Enhanced Metafile

Path Rendering (of converted text) is erroneous. 

First import the attached enhanced meta file in a fresh doc (insert->picture->from file) and save this doc as pdf. If you look closely (zoom to 1600%) at the text parts, you see some errors in path rendering. normally you don't see this on screen, but if you print this the text looks blurred.

If you do the same in MS Word, the text parts are rendered correctly.

The same happens, if you import a svg-file (only reproducible via draw see bug 42092)
Comment 1 bugs 2012-11-12 16:29:13 UTC
Created attachment 69949 [details]
PDF the rendering errors
Comment 2 Uli Schlachter 2012-11-12 16:36:41 UTC
Uhm, cairo is a C library. This boils down to "there is no insert->picture->from file" in cairo".

So what are you clicking in?

Also, I am quite sure that MS Word does not use cairo.
Comment 3 bugs 2012-11-12 17:12:57 UTC
really great, rather than proposing a better product for this bug posting a smartass-comment....

this is a libreoffice-bug, but as far as I know does libreoffice use the cairo-libs for composing pdfs....

the hint with ms word should show that the emf-file is not the problem
Comment 4 Martin 2015-01-06 04:29:27 UTC
The EMF file is a pain to open as I'm using Linux (and the only package I know of that can open EMF files is LibreOffice, which is a bit circular!), but looking at the PDF file with the rendering errors I think I know what's going on here. I would like to report what I think is the same bug/feature, discovered independently.

I've created an SVG testcase in Inkscape:

- Start with a blank A4 page
- Write "The quick brown fox" in Arial 10 pt
- Create a copy of the text below the original
- On the bottom copy, Path -> Object to Path
- Save as Plain SVG

(The "Object to Path" command replaces the text with a curve.)

I attach a few screenshots of the testcase viewed in various programs.

When I open the SVG file in LibreOffice Draw (, straight away there are two bugs compared to the other programs:

- The top text is not shown
- The fill in the bottom text is white rather than black

However those are *not* the bugs I want to report today! Instead let's look at what happens when you export the drawing as PDF.

When you look at the exported PDF in Acrobat Reader at a high enough resolution, the "r" and "n" start to look rather wiggly. When you compare the original SVG and the exported PDF in Inkscape and look at the control points, you begin to see what's going on.

The explanation can be found via Edit -> XML Editor in Inkscape. For the exported PDF the numbers are given to a single decimal place, whereas in the original SVG they have six decimal places.

Now I'm not an expert on PDFs, but I've tried the following:

$ pdftk "PDF export.pdf" output "PDF export - uncompressed.pdf" uncompress

When I look inside the uncompressed PDF file, I see things like:

22.5 1028.4 l 22.4 1027.9 22.1 1027.5 21.7 1027.2 c 21.3 1026.9 20.8 1026.8 20.2 1026.8 c
19.4 1026.8 18.8 1027 18.4 1027.5 c 17.9 1027.9 17.7 1028.6 17.7 1029.4 c
17.7 1030.3 17.9 1031 18.4 1031.5 c 18.9 1032 19.4 1032.2 20.2 1032.2 c
20.9 1032.2 21.4 1032 21.9 1031.5 c 22.3 1031 22.5 1030.4 22.5 1029.5 c
22.5 1029.4 22.5 1029.4 22.5 1029.3 c 18.6 1029.3 l 18.7 1028.7 18.8 1028.2 19.1 1028 c
19.4 1027.7 19.8 1027.5 20.2 1027.5 c 20.5 1027.5 20.8 1027.6 21 1027.7 c
21.3 1027.9 21.5 1028.2 21.6 1028.6 c h

... all to one decimal place. So this looks like it's coming from the PDF exported by LibreOffice Draw and isn't an artifact of Adobe Reader or Inkscape.

When you include the SVG in a Writer document as an image, you get the same behaviour.

Now this seems to be related to bug#23364 for Cairo. Except the person there was complaining that six digits after the decimal point are too much!

And I basically agree, the current setting in LibreOffice is probably good enough for 99% of users while producing a very compact output.

HOWEVER, in my case it causes problems when I try to include a technical drawing in a report produced in Writer. It's basically fine at "normal resolutions", but when you start to zoom in a bit, it get rather ugly very quickly.

Now the whole point of vector graphics, for me, is razor sharp images for high quality documents. But what's the point of vector graphics when you get rasterization artifacts the minute you zoom beyond 100%? The wiggliness in the testcase is very clear at 1200% zoom in Acrobat Reader, but if you know where to look, it is certainly noticeable at 500% zoom.

So what's the benefit of this?

I did a little experiment on testcase.svg. First off, the file size is 15610 B uncompressed, or 4878 B compressed with gzip (default settings). I count 891 numbers given to six decimal places (matching \d\.\d{6} in Perl). When I truncate them to a single decimal place, the file size is reduced to 11155 B (-28.5%), or 2714 B compressed with gzip (-44.4%). The gzipped numbers are probably the more relevant ones for PDFs produced by LibreOffice. So we've basically halved the file size.

From what I can see, two digits instead of one should be OK for viewing at up to 6400% zoom, which is where Adobe Reader currently stops. This is also what was proposed in the Cairo bug report.

But it would also be nice to let the user control this. Ideally this would be done by allowing the user to set the maximum number of decimal places, but at the very least there should be an option to respect the information provided by the original image.

Program versions: 

LO draw = LibreOffice Draw

acroread = Adobe Reader 9.5.5
chromium = Version 37.0.2062.120 Built on Ubuntu 12.04
eog = Gnome Image Viewer 3.4.2
inkscape = Inkscape version 0.48

All running on Linux Mint 13 Maya.
Comment 5 Martin 2015-01-06 04:31:55 UTC
Created attachment 111812 [details]
01 - SVG testcase
Comment 6 Martin 2015-01-06 04:32:50 UTC
Created attachment 111813 [details]
02 - SVG test case in eog at 2000% zoom
Comment 7 Martin 2015-01-06 04:34:40 UTC
Created attachment 111814 [details]
03 - SVG test case in chromium at 500% zoom
Comment 8 Martin 2015-01-06 04:35:54 UTC
Created attachment 111815 [details]
04 - SVG test case in LO Draw at 750% zoom = FIRST TWO BUGS
Comment 9 Martin 2015-01-06 04:37:20 UTC
Created attachment 111816 [details]
05 - SVG test case in LO Draw at 3000% zoom = starting point for later files
Comment 10 Martin 2015-01-06 04:39:27 UTC
Created attachment 111817 [details]
06 - PDF exported by LO Draw
Comment 11 Martin 2015-01-06 04:40:57 UTC
Created attachment 111818 [details]
07 - the exported PDF in Acrobat Reader at 3200% zoom
Comment 12 Martin 2015-01-06 04:43:21 UTC
Created attachment 111819 [details]
08 - the original SVG in Inkscape at 8000% zoom
Comment 13 Martin 2015-01-06 04:44:37 UTC
Created attachment 111820 [details]
09 - the exported PDF in Inkscape at 6000% zoom = MAIN BUG
Comment 14 Martin 2015-01-06 04:48:47 UTC
Created attachment 111821 [details]
10 - the exported PDF, uncompressed using pdftk
Comment 15 Martin 2015-01-06 05:08:33 UTC
P.S. As far as I can see, this is a general issue that affects every single vector image included in a LibreOffice file (tested for Draw and Writer) the minute the file is exported as PDF.

I first noticed it on junctions marks in an electrical schematic.
Comment 16 QA Administrators 2016-01-17 20:04:36 UTC Comment hidden (obsolete)
Comment 17 Kai Struck 2017-01-02 12:47:06 UTC
I can confirm this behavior in LO4.4.7.2  and LO5.2.3.3 32bit portable win7.

This bug destroys little details of SVG path because of cutoff decimal values or rounding.
The smaller the svg is scaled the greater are the artifacts.

I believe Martin is right with his findings in uncompressed PDFs.
In a PDF exported by Inkscape the values look like this:
65.938 779.023 m 66.219 777.64 l 66.234 777.558 66.242 777.484 66.242 777.409
 c 66.242 776.675 65.496 776.062 64.688 776.062 c 64.441 776.062 64.199 

In a PDF with the same SVG exported by LO they are cut (or rounded too extreme):
66.6 777 m
66.6 776.9 66.6 776.9 66.6 776.8 c 66.6 776.1 65.8 775.5 65 775.5 c
64.8 775.5 64.5 775.5 64.3 775.6 c 64.9 775.7 65.3 776 65.3 776.5 c

(the numbers are a bit different because of scaling)
Comment 18 Kai Struck 2017-01-03 12:00:21 UTC
Seems like Martin was already trying to find a solution there:
Comment 19 QA Administrators 2018-01-04 03:34:34 UTC Comment hidden (obsolete)
Comment 20 V Stuart Foote 2018-02-04 22:30:47 UTC

*** This bug has been marked as a duplicate of bug 96892 ***