Bug 81497 - PRINTING: to PDF with Adobe Distiller or GS based PDF printer, EPS images not rendered to PS vector for PDF, instead print uses the preview of EPS image
Summary: PRINTING: to PDF with Adobe Distiller or GS based PDF printer, EPS images not...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.2.5.1 rc
Hardware: Other Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Images-EPS
  Show dependency treegraph
 
Reported: 2014-07-18 14:13 UTC by Colin Dill
Modified: 2017-10-21 22:52 UTC (History)
13 users (show)

See Also:
Crash report or crash signature:


Attachments
Zip file containing source ODT file, PDFs generated from LO versions 4.1.6.2 and 4.2.5.2, enlarged screenshots of the relevant area for each file. (434.89 KB, application/x-zip-compressed)
2014-07-18 14:13 UTC, Colin Dill
Details
CUPS PDF printer output of from 4.1 Vs 4.2 (126.87 KB, image/png)
2014-07-21 17:52 UTC, Yousuf Philips (jay) (retired)
Details
Source EPS file used in bug document (78.59 KB, application/postscript)
2014-07-21 18:33 UTC, Colin Dill
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Colin Dill 2014-07-18 14:13:35 UTC
Created attachment 103043 [details]
Zip file containing source ODT file, PDFs generated from LO versions 4.1.6.2 and 4.2.5.2, enlarged screenshots of the relevant area for each file.

Problem description:
After updating to LibreOffice 4.2.5.2, 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 4.1.6.2
3. Print attached ODT file using File>Print and select Adobe PDF as the printer
4. Install LibreOffice 4.2.5.2
5. Print the same file again
6. Compare the graphic on page 5

Current behavior:
File printed to PDF from LibreOffice 4.1.6.2 contains a high-quality vector graphic on page 5. Same file printed from LibreOffice 4.2.5.2 contains low-quality raster graphic. (See attached PDFs and screenshots.)

Expected behavior:
Both versions should output identical PDF documents with high quality vector graphic.

              
Operating System: Windows 7
Version: 4.2.5.2 release
Comment 1 Yousuf Philips (jay) (retired) 2014-07-21 17:52:56 UTC
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?
Comment 2 Colin Dill 2014-07-21 18:31:51 UTC
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.
Comment 3 Colin Dill 2014-07-21 18:33:29 UTC
Created attachment 103209 [details]
Source EPS file used in bug document
Comment 4 Jörn Schwarz 2014-08-02 09:54:07 UTC
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.
Comment 5 Jochen 2014-08-02 18:22:21 UTC
@Jay: do you still have any questions? If not I would set status to "NEW".
Comment 6 Yousuf Philips (jay) (retired) 2014-08-02 21:38:11 UTC
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 ***
Comment 7 V Stuart Foote 2014-09-15 22:34:15 UTC
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.
Comment 8 V Stuart Foote 2014-09-15 23:03:56 UTC
@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).
Comment 9 Michael Meeks 2014-09-16 09:04:45 UTC
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.
Comment 10 Caolán McNamara 2014-09-16 09:15:25 UTC
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
Comment 11 V Stuart Foote 2014-09-16 13:40:34 UTC
(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.
Comment 12 Gerry 2014-09-23 07:16:41 UTC
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"
Comment 13 Michael Meeks 2014-09-23 09:06:07 UTC
> 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 =)
Comment 14 Gerry 2014-09-23 11:03:00 UTC
(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.
Comment 15 V Stuart Foote 2014-09-24 04:17:11 UTC
@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.
Comment 16 V Stuart Foote 2014-09-24 04:53:20 UTC
Noted on master wef 30 April, and with 4.2.5.1 build. Adjusting version.
Comment 17 V Stuart Foote 2014-09-24 05:11:01 UTC
(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.
Comment 18 Gerry 2014-09-24 07:59:25 UTC
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.
Comment 19 Michael Meeks 2014-09-24 08:18:18 UTC
A query on your patch Caolan ? =)
Comment 20 Tom2 2014-10-03 13:19:30 UTC
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???)
Comment 21 V Stuart Foote 2014-10-03 13:46:49 UTC
@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/
Comment 22 Björgvin Ragnarsson 2014-10-12 01:29:40 UTC
I confirmed that the problem is gone when I revert 3db00c554b38ee6c1b6e969768da53db4dc2f92a (suggested in comment #15)
Comment 23 Matthew Francis 2014-12-08 03:33:06 UTC
Removing Whiteboard:bibisectRequest from this and adding Keywords:bisected, as a specific commit has already been identified
Comment 24 Joel Madero 2015-01-05 17:15:47 UTC
Adding bibisected to whiteboard as bisected keyword is a subset of bibisected whiteboard.

Thanks!
Comment 25 Jörn Schwarz 2015-08-05 13:02:41 UTC
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
Comment 26 Joel Madero 2015-08-05 14:58:11 UTC
@ 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/
Comment 27 Robinson Tryon (qubit) 2015-12-13 11:16:14 UTC Comment hidden (obsolete)
Comment 28 Xisco Faulí 2016-09-26 14:53:45 UTC
Adding Cc: to Caolán McNamara
Comment 29 Xisco Faulí 2017-09-29 08:49:40 UTC Comment hidden (obsolete)
Comment 30 Jörn Schwarz 2017-09-29 09:33:42 UTC
The bug is still present.

Tested with LibreOffice 5.4.1
OS: Windows 10