Created attachment 103203 [details]
CUPS PDF printer output of from 4.1 Vs 4.2

Hello Colin,

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".

Hi Colin,

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 ***

https://bugs.freedesktop.org/attachment.cgi?id=106328
Zip archive with sample ODT and three PDF renderings done in 4.4.0alpha+

On Windows 7 sp1, 64-bit with
Version: 4.4.0.0.alpha0+
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.

https://bugs.freedesktop.org/attachment.cgi?id=106336

This zip file contains PDF renderings of the sample .ODT done with LibreOffice 4.1.5.3 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.

@Caolán, Björgvin

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

http://cgit.freedesktop.org/libreoffice/core/commit/?id=3db00c554b38ee6c1b6e969768da53db4dc2f92a

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 4.2.5.1 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???)

@Tom2, *,
(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
> document.

Should be OK with a LibreOffice 4.1.6.2 build. Or if no EPS, then through 4.2.4.2--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.

Thanks!

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

@ 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

https://joelmadero.wordpress.com/2014/10/11/user-expectations-and-the-reality-of-our-community/

Adding Cc: to Caolán McNamara

I can confirm this for all v5 and v6 alpha. The last version, which was able to export a EPS stream correctly to a PS interpreter (via printing) was v4.2.4.2.

This patch seems to create the issue:
https://gerrit.libreoffice.org/plugins/gitiles/core/+/3bedb85460b028500ff450eeeb80acf8278df39e

6.2.0.3: The bug is still present

The bug is still present.

Tested with LibreOffice 7.5.0
OS: Windows 10