Created attachment 103043 [details]
Zip file containing source ODT file, PDFs generated from LO versions 188.8.131.52 and 184.108.40.206, enlarged screenshots of the relevant area for each file.
After updating to LibreOffice 220.127.116.11, when printing to PDF using Adobe Acrobat Printer (via File>Print, not File>Export) the .eps file's low quality raster preview image is output rather than the properly rendered vector graphic. No other software updates occurred.
Steps to reproduce:
1. Install Adobe Acrobat Pro Verson 9.5.5 (other versions not tested)
2. Install LibreOffice 18.104.22.168
3. Print attached ODT file using File>Print and select Adobe PDF as the printer
4. Install LibreOffice 22.214.171.124
5. Print the same file again
6. Compare the graphic on page 5
File printed to PDF from LibreOffice 126.96.36.199 contains a high-quality vector graphic on page 5. Same file printed from LibreOffice 188.8.131.52 contains low-quality raster graphic. (See attached PDFs and screenshots.)
Both versions should output identical PDF documents with high quality vector graphic.
Operating System: Windows 7
Version: 184.108.40.206 release
Created attachment 103203 [details]
CUPS PDF printer output of from 4.1 Vs 4.2
Thank you for filing the bug. I've tested the EPS rendering on Linux Mint in 4.1.6 and 4.2.5 by both exporting it as a PDF and printing it to a PDF printer (CUPS) and there wasnt a difference in their output. I will test it on my Windows 7 system the next chance i get, as i have installed 3 pdf printers.
Do you see in the Writer 4.1.6 that the EPS is rendered smoothly, similar to the output of Adobe Acrobat?
Opening the source EPS file directly in Adobe Acrobat (automatically converting to PDF) produces a smoothly rendered vector graphic that scales with zooming, as does the document printed to PDF from Writer 4.1.6 using the Adobe PDF printer on Windows. Similar results should be gotten using any PostScript printer driver.
Using "Export to PDF" produces results as you show in your attachment in both versions, as does printing using Adobe PDF printer on Windows from Writer version 4.2.5.
I will attach the original EPS file.
Created attachment 103209 [details]
Source EPS file used in bug document
Hello Colin and Jay,
thanks for the bugreport. – I can confirm the bug for Windows XP and 7.
It also occures in LO 4.3.0 if using Ghostscript with FreePDF.
And it occures in LO 4.3.0 (and all other pre-versions) if using the internal pdf generator.
It is a regression, because it worked well with Acrobat and Ghostscript since OOo 1.x.
I produce hundreds of complex diagramms with Calc, copy it to Draw, add some text, somtimes combine 2 or more calc diagramms and then export it to *.eps. Finally I import the eps-files in Writer documents, which at last are printed as pdf-files. – The quality allways was excellent.
Now the quality is poor.
@Jay: do you still have any questions? If not I would set status to "NEW".
Thank you for the feedback. I'm going to close this bug as a duplicate of another one, as more work/testing has been done on the other one. Please follow the other bug for updates on this issue.
*** This bug has been marked as a duplicate of bug 81592 ***
Zip archive with sample ODT and three PDF renderings done in 4.4.0alpha+
On Windows 7 sp1, 64-bit with
Build ID: 9195fd3819197c14f6fc018483075c4be5bf85fd
TinderBox: Win-x86@39, Branch:master, Time: 2014-09-09_05:00:16
GPL Ghostscript 9.14 (2014-03-26)
pstoedit: version 3.62 / DLL interface 108 (built: Apr 28 2013 - release build - MS VC++ 1600 - 32-bit) : Copyright (C) 1993 - 2013 Wolfgang Glunz
ImageMagick 6.8.9-0 Q16 x86 2014-04-06
Features: DPC OpenMP
Delegates: bzlib cairo freetype jbig jng jp2 jpeg lcms lqr pangocairo png ps rsvg tiff webp xml zlib
Noticeable kerning issues with both print filter and export filter. Also pstoedit/GS continues to do a poor job with density of converting curves to segments--both with vector preview, but also on Export to PDF.
This zip file contains PDF renderings of the sample .ODT done with LibreOffice 220.127.116.11 build.
Note the Export to PDF uses a raster rendering of the EPS.
But at that point of development the LibreOffice print filters are using the EPS (or is it an EMF/WMF based vector image), either case all vectors are properly positioned and rendered in the result.
And that at this point LibreOffice had full vector resolution when printing out to PS based PDF printer--Adobe Distiller 9, or GS based CutePDF.
So as implemented at 4.1.x, we were able to zoom in with full fidelity or send for publication. No longer the case at 4.2, 4.3 and current master.
At 4.2.0 we switched from ImageMagick convert/GS rendering to pstoedit/GS rendering of EPS, both with and without preview.
pstoedit has really poor fidelity in rendering EPS for a preview, and its resulting vector preview is of much lower quality than what convert/GS had provided through the 4.1.x builds.
Can we roll back (resume use of convert rather than pstoedit--revert of the f5c3f5601a3739dead635f9abc446951b385018f commit for bug 41407 to clear the regression) and at least generate a clean raster preview of EPS?
But would still need to figure out where we have clobbered use of EPS when printing to PS, and in export to PDF.
The alternative might be to purge EPS from the equation and with a suitable GS-poppler-cairo input filter and always convert to SVG. We seem to retain SVG at all steps (preview, printing, and export to PDF).
IMNSHO all of these duplicate "EPS rendering sucks" bugs should be turned into a single one: "integrate xpost / another suitably licensed PS renderer into LibreOffice" =) I thought there was already a bug for that.
Without being able to interpret the PS / EPS internally we can't do a whole lot here, particularly cross-platform.
re, "flip from one to another", then a different set of bugs will appear. It was probably a mistake in retrospect to generate a preview at all. It if "just didn't work" to use eps then it would be simple, this "sort of working" has waster so much of everyones time
(In reply to comment #9)
> ... I thought there was already a bug for that.
On the See also list, bug 67464
(In reply to comment #10)
> re, "flip from one to another", then a different set of bugs will appear. It
> was probably a mistake in retrospect to generate a preview at all. It if
> "just didn't work" to use eps then it would be simple, this "sort of
> working" has waster so much of everyones time
Yes but we need the preview for use in all modules--or would have to deal with performance hits of repeatedly rendering the EPS vector image. pstoedit preview gets us an EMF/WMF vector based preview--but the EMF/WMF filter in Wolfgang Glunz's s standard drivers seems dysfunctional (any feedback from him--Caolán), Imagemagick convert used GS and gave us a PNG, and then a BMP based raster preview of the EPS image.
At the moment pstoedit preview is not optimal, but it works across the components, reverting back to convert would improve *only* the previews.
And what has gone missing seems to be the print and export filter handling of the original EPS vector image--the original is still in the ODF archive, but we somehow started sending the preview image during PS print or PDF export. That needs help.
What is actually the difference of this bug to bug 81592? Both refer to the severe regressions in EPS handling since the 4.2.x line.
Is there still hope that these bugs will be fixed for the last revision 4.2.7 of the "still" line, which has its freeze date on the 29th of September?
These EPS regressions are the worst I encountered so far on LibreOffice. It makes professional use of LibreOffice impossible, (1) since documents with EPS graphis that worked for long time do not work anymore, (2) exchange of documents with other users is getting impossible, (3) vector graphics exchange with certain software packages is impossible and (4) one has to hear the sentence "LibreOffice is really crap, we should have used MS Word"
> These EPS regressions are the worst I encountered so far on LibreOffice. ...
> (4) one has to hear the sentence "LibreOffice is really crap, we should
> have used MS Word"
Its news to me that MS Word can render EPS any better than using the embedded bitmap preview.
The ultimate solution here - to give crisp and beautiful EPS rendering is to implement the EPS language / state-machine / renderer inside LibreOffice - the best candidate there (so far) is xpost - patches most welcome to add integration there =)
(In reply to comment #13)
> > (4) one has to hear the sentence "LibreOffice is really crap, we should
> > have used MS Word"
@Michael: This statement by colleagues is not really related to technical capabilities of MS Office. The problem is that the use of LO in work groups is still a "deviation from the standard" (i.e. MS Office). Hence, anything bad and particularly regressions in LO fire back to the acceptance of LO.
Anyways, I tested EPS handling in Word 2010 and there .eps files are awfully displayed on screen, but well rendered (vectors) on PDF export. However, if one zooms closer, one sees that MS Word constructs lines and characters in eps graphics from many many tiny straight lines only.
@Caolán, @Björgvin, *,
I am pretty certain this is the commit that breaks EPS use during PS printing. Put in at the 4.2.4 build. But I am not sure that it has anything to do with use of raster preview for the export filter to PDF--which predates this considerably.
Have a look, affecting the DrawEPS in the vclprocessor2d.cxx code
Bit of "whack-a-mole" in that this change was made to fix bug 62038 -- lack of EPS preview for Impress slide show.
Noted on master wef 30 April, and with 18.104.22.168 build. Adjusting version.
(In reply to comment #12)
> What is actually the difference of this bug to bug 81592? Both refer to the
> severe regressions in EPS handling since the 4.2.x line.
81592 isolated the issue of bitmap depth for raster preview images, or poor vector fidelity in pstoedit WMF/EMF generated preview image of an EPS image.
While this issue 81497 is for loss of the EPS images vector detail when the document is being rendered on a PS device. The EPS vector image is being replaced by its lower quality preview.
Two completely separate issues in the code.
If my comment 12 sounded rude, I sincerely want to apologize. This was not my intention and I also didn't want to upset anyone. People (including myself) are just getting anxious to lose completed work/documents due to these EPS regressions.
A query on your patch Caolan ? =)
I just stumbled over this with a document that used to print OK (using PDFCreator), and I have to say it is very annoying!
It took me half the day to find a working solution: I still have an old OpenOffice version (3.4.0) installed, and could finally print a PDF from my document.
Please make this a high priority!
(LO 4.3.2 on Win7x64. Printing worked about a year ago with then current LO v???)
(In reply to Tom2 from comment #20)
> It took me half the day to find a working solution: I still have an old
> OpenOffice version (3.4.0) installed, and could finally print a PDF from my
Should be OK with a LibreOffice 22.214.171.124 build. Or if no EPS, then through 126.96.36.199--pull either from the Archive here: http://downloadarchive.documentfoundation.org/libreoffice/old/
I confirmed that the problem is gone when I revert 3db00c554b38ee6c1b6e969768da53db4dc2f92a (suggested in comment #15)
Removing Whiteboard:bibisectRequest from this and adding Keywords:bisected, as a specific commit has already been identified
Adding bibisected to whiteboard as bisected keyword is a subset of bibisected whiteboard.
Today LO 5.0 has been released and nothing has happened with bug 81497.
And Italo Vignoli told us that LO has beern deployed for over 80 million users.
And LO 5.0 is still not able to be used for scientific publications.
Am I the only one, who needs vector graphics in high quality?
Can I still hope?
@ Jörn Schwarz - please read this blog post. No need to comment about it, it simply says how the project works and why comments like yours are not useful on the bug tracker
Migrating Whiteboard tags to Keywords: (bibisected)
Adding Cc: to Caolán McNamara
** 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.4.1 or 5.3.6 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)
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 helping us make LibreOffice even better for everyone!
The bug is still present.
Tested with LibreOffice 5.4.1
OS: Windows 10