https://bugs.freedesktop.org/show_bug.cgi?id=57021
--- Comment #4 from Martin <[email protected]> --- 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 (4.3.5.2), 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 4.3.5.2 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. -- 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
