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)
Created attachment 69949 [details] PDF the rendering errors
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.
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
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.
Created attachment 111812 [details] 01 - SVG testcase
Created attachment 111813 [details] 02 - SVG test case in eog at 2000% zoom
Created attachment 111814 [details] 03 - SVG test case in chromium at 500% zoom
Created attachment 111815 [details] 04 - SVG test case in LO Draw at 750% zoom = FIRST TWO BUGS
Created attachment 111816 [details] 05 - SVG test case in LO Draw at 3000% zoom = starting point for later files
Created attachment 111817 [details] 06 - PDF exported by LO Draw
Created attachment 111818 [details] 07 - the exported PDF in Acrobat Reader at 3200% zoom
Created attachment 111819 [details] 08 - the original SVG in Inkscape at 8000% zoom
Created attachment 111820 [details] 09 - the exported PDF in Inkscape at 6000% zoom = MAIN BUG
Created attachment 111821 [details] 10 - the exported PDF, uncompressed using pdftk
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.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.4 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT: - Update the version field - Reply via email (please reply directly on the bug tracker) - Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-01-17
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)
Seems like Martin was already trying to find a solution there: https://bugs.documentfoundation.org/show_bug.cgi?id=96892
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
*** This bug has been marked as a duplicate of bug 96892 ***