Created attachment 103177 [details]
EPS-test-file.eps

Just did testing insertion in Writer with attached eps with Ubuntu 12.04 x86, confirm same result as attached screenshot.

Bad result: LO 4.2.0.0.beta1, 4.2.6.1, 4.3.0.3

Good result : LO 4.1.6.2

Per fdo bug 64161#23 the issue is with the pstoedit which handles the emf conversion to emf for preview and image output to PDF.

Alternative to this internal conversion via pstoedit, is conversion external to LO to emf or svg format.

And of course on Windows and OS X most systems will not have pstoedit installed and configured.

Caolan, any comment on improving the pstoedit conversion? Should folks look to conversion exterior to LO?

If you call pstoedit with one set of command line options you solve one subset of problems, if you use it with another you solve a different subset. So we never render eps, we either use the preview in the image, or call pstoedit to generate one in emf format. Generating eps previews for eps that don't provide one was always a hack (and I wish I never implemented it). The generator in this case is "strata", I suggest using the "preview on" feature to get it to generate a tiff preview in the eps to see if strata previews are better than pstoedits.

With the above attachment the thing to check here is to use pstoedit manually to generate the emf

pstoedit -usebbfrominput -f emf:-OO -drawbb input.eps output.emf

and see if the rendering of that emf is different in different versions of LibreOffice, i.e. is there a regression in emf rendering.

Thanks a lot Caolan for looking into the bug.

(1) Yes, the statistical package Stata is the generator. With the option "preview on", I got much worse results on LO 4.1.x (you could see pixels and images not sharp) than using "EPS without preview". That's why I deactivated it for the graphics in all my documents using LO 4.0.x and 4.1.x. (My different documents contain about 200 eps graphics altogether, hence it is difficult to change that for existing documents).
-> Please find attached two sample eps files, one with preview and one without preview. I just loaded them in 4.1.4 and the one with preview looked terrible.

(2) BTW, my tests with LO 4.2.5 and 4.1.4 are on exactly the same system (=the pstoedit version was the same)

(3) Running the pstoedit command, I get following error message:

$pstoedit -usebbfrominput -f emf:-OO -drawbb EPS-test-file.eps EPS-test-file.emf
unknown option -drawbb
pstoedit: version 3.60 / DLL interface 108 (built: Jul 13 2012 - release build - g++ 4.7.1 - 64-bit) : Copyright (C) 1993 - 2011 Wolfgang Glunz
Unsupported output format emf

What is the next step? If I shall do/test something, please tell. Thanks

Created attachment 103284 [details]
Another-EPS-test-file-without-preview.eps

Created attachment 103285 [details]
Another-EPS-test-file-with-preview.eps

reading comment #5 i wonder what this means: "Unsupported output format emf"

does installing a newer version of pdftoedit improve anything?
Fedora 20 has 2.62 apparently...

@Michael Stahl: Good question, I really don't know. The repository does not offer a newer version of pstoedit (probably the same with the LTS 12.04 as per comment 2). But, if this is an issue, why did the EPS rendering correctly work in LO version 4.1? Did the architecture to handle EPS completely change between 4.2 and 4.1?

Created attachment 103322 [details]
Test-document-with-graphics-from-comment-6-7-inLO41.odt

For completeness, the attachment illustrates that the "EPS with preview" leads to quite bad results in LO 4.1, while "EPS without preview" shows good quality. see the example .odt and .pdf with the two test files from comment 6 and comment 7. 

Hence, that the quality of "EPS without preview" graphics heavily regresses in LO 4.2/4.3 is a real problem.

Created attachment 103323 [details]
Test-document-with-graphics-from-comment-6-7-inLO41.pdf

Another EPS bad rendering issue when exporting to PDF can be found in bug 81497.

Ubuntu 14.04 x64 - Confirmed regression

Unfortunately not bibisectable :( I do indeed see a regression though. Don't think it has anything to do with pstoedit as the only thing changing during bibisect is libreoffice and you can see the regression.

Setting priority:
Normal - can prevent high quality/professional work
High - regression

Hello,

please have a look at bug 81497, dated 2014-08-18.
It also occures in 4.3.0 under Windows XP and 7.
And the eps-files are generated with Calc and Draw.

*** Bug 81497 has been marked as a duplicate of this bug. ***

This is a bad regression.
With LO 4.2.x and 4.3.x it is not possible to create publications with high quality grafics anymore.
And it worked without problems for many years.

As far as I know this only affects EPS files, so if you convert these using any number of software to jpeg or png then you should still be able to get high quality/professional work.

@Joel: Thanks for your comment. However, your advice in comment 17 is highly problematic for some reasons:
- EPS is the only vector graphics format which is supported on export from many applications (e.g. statistical software). Inserting them in Libreffice was always possible without problems.
-All documents which were created with embedded EPS files are useless in LO 4.2 and 4.3. I mean, no one can ask the users to rip off dozens of EPS graphics in nicely formatted theses/books/articles, somehow export them from LO, convert them in another piece of software to another format, insert them again in LO and do all the formatting again.
- Pixel graphics formats like jpg or png are just a quite bad workaround. EPS as vector format was just perfect for the same document to self-publish(using LO) and to a publisher (who usually requests EPS for graphics exchange). Hence, there is currently no real alternative to EPS for many user scenarios (at least in academia).

Honestly, I don't know what to do, if the last version of the LO 4.2-line (upcoming 4.2.7) doesn't fix this bug. Currently, I am locked to the EOL LibreOffice 4.1.x-line, but I cannot always keep an old version of LibreOffice on the system to properly access my documents...

(This is an automated message.)

Setting priority to highest as this is a MAB. This is part of an effort to make the importance of MAB reflected in priority too.

Will this EPS rendering regression be fixed for LO 4.2.7 ?

I am asking because I am stuck between the versions: On my 200+ pages document, LO 4.2.x is significantly more stable and performant than 4.1.x and has a few new features I need, but it fails outputting EPS graphics. Hence, I am stuck with 4.1.x. with aforementioned drawbacks.

Thanks in advance!

Gerry asked in comment 20 whether the rendering regression will be fixed for LO 4.2.7.

I can't use the 4.2.x line because of bug 74333 which is already fixed – but only for LO 4.3.x.
Therefore from my point of view it would be better to implement the fixing in LO 4.3.x.

Thanks in advance!

Björgvin Ragnarsson committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=247f87bc08e2f71e44d8f7f9af791e9288714985

fdo#81592 Use 24-bit color depth, not 256 colors when converting an EPS-file.



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

@Björgvin, *,

Cool! That was obscure, so the work on bug 41407 to speed up EPS processing by switching from ImageMagick's convert to ghostscript based rendering of a PNG preview--done just at release for the 4.2.0 branch--caused the long running regression.

So now with a 24-bit PNG preview, fidelity of rendered EPS should return. So that's great.

But what about retaining the EPS structure as vector? We keep the EPS around for printing to a PS printer, but we do everything else with bitmap previews.  Is there any chance of working internally in a vector format?  EPS -> SVG perhaps as an import filter? And further refine handling of SVG.

Already have ghostscript, poppler and cairo in the mix--doesn't that get us most of the way to a "built-in" filter handling of EPS as in bug 67464

>But what about retaining the EPS structure as vector? We keep the EPS around for printing to a PS printer, but we do everything else with bitmap previews.

Oops, adjust that... but other than the pstoedit conversion to emf/wmf, which has become unreliable if remaining in vector, we do everything else with bitmap previews.

Hi Björgvin Ragnarsson,

Thank you very for this fix. Works well on the master (Build ID: 114f3b83b9f850abf57f86836bbc579c4d41aaca) build at home under Ubuntu 14.04 x86-64.
Do you plan to backport the fix to 4.3 and 4.2 branches ?

Best regards. JBF

Does this fix also fix the poor rendering of images mentioned my bug 82870, which also is a 4.2 regression.

(In reply to comment #26)
> Does this fix also fix the poor rendering of images mentioned my bug 82870,
> which also is a 4.2 regression.

No. Unless I am mistaken, this bug is about color while your bug 82870 is about aliasing.

Best regards. JBF

@Michael Stahl, Gerry:

The message "Unsupported output format emf" is there in pstoedit because it is not compiled with libemf support in Ubuntu/Debian --> it doesn't work.

@V Stuart Foote:
I wouldn't say it's that obscure, the most likely suspects would have been the only two commits on the 4.2 branch mentioning EPS in the message: http://cgit.freedesktop.org/libreoffice/core/log/?h=libreoffice-4-2-0&qt=grep&q=+EPS

Improving import as a vector with an external tool (perhaps finding an alternative to pstoedit) should be discussed in its own bug report. In my opinion that could very well provide shorter term improvements over the long term 67464.

@Jean-Baptiste Faure:

Yes, I was planning on backporting the fixes, perhaps after a bit more feedback. Is the duplicate issue 81497 fixed as well with this change?

(In reply to comment #28)

>... Is the duplicate issue 81497 fixed as well with this change?

Believe that has been, and remains a different but related issue. For some reason between 4.1 and 4.2 builds. As reported in bug 81497--we appear to be losing track of the EPS--and are no longer passing it back during PS printing. Made worse when we use a low resolution preview included with the EPS.

Looking at attachment from OP for issue 81497 (attachment 103043 [details]), the PDF printed to PS with 4.1.6.2 has very crisp vector rendering of the EPS. But the PDF printed to PS from 4.2.5.2 has poor rendering and looks to be using either the included preview image, or the gs (or convert) BMP preview image at 300dpi.

This continues through 4.3 and is still present in master with the 24-bit vs. 256 bit gs rendering in the http://cgit.freedesktop.org/libreoffice/core/commit/?id=247f87bc08e2f71e44d8f7f9af791e9288714985 so not yet correct.

Created attachment 105870 [details]
eps pdf svg of S154_HURD Fraction Anthem

A test file to work with to generate your own sample documents, exports prints

EPS w/~100dpi preview (from bug 81497)
PDF (ghostscript ps2pdf -EPSCrop conversion)
SVG (pdf2svg conversion -- D. Barton's)

@Björgvin: Thanks for the fix in commment 22. I have not yet tried it out, but I was surprised that the change comprises only "bmp256" -> "bmp16m". Very nice. 

For my better understanding: Was this bug actually a 'real regression'? Or in other words, how could this "bmp256" originally slip into the LibreOffice 4.2-line (as the bug was not present in LO 4.1.x)?

Is the "Unsupported output format emf" on Ubuntu a problem regarding the fix of this bug or will it just work after your fix like it was in the 4.1.-line?
Thanks a lot!

In comment 22, dated 2014-09-05, Bjørgvin Ragnarsson wrote that the patch should be included in the daily builds in the next 24-48 hours.
I tried LO 4.4.0.0 – 2014-09-09_23.33.59 and had to realize, that the bug is not fixed. The quality is as bad as it is since LO 4.2.x. 
Wheras LO 4.1.6.2 delivers best quality.

@Gerry: 256 color rendering with 'gv' has been for ages in the codebase but it was only used when the program 'convert' wasn't available. Apparently that is a very uncommon setup so bugs weren't reported on that.


@Jörn Schwarz: I just tested adding EPS-test-file.eps to a Writer document in build

Version: 4.4.0.0.alpha0+
Build ID: e2723d00b77dc1044e2ba599ba93517af34e1ea5
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-09-09_23:17:41

and it gave me similar quality as is seen on the right in this screenshot https://bugs.freedesktop.org/attachment.cgi?id=103176 . Is that not the case for you?

In comment # 33 Björgvin Ragnarsson wrote that he added an EPS-test-file to a Writer document and that the printout via 4.4.0.0.alpha0+ gave him a 'similar quality on a screenshot'.

But a screenshot is always a bitmap – not a vector graphic. Therefore the difference in printouts via GhostScript or Adobe Acrobat cannot be seen.

In "Test-document-with-graphics-from-comment-6-7-inLO41.pdf" (see above) you can see the difference: In the first case the bitmap (incorporated in the eps-file)is printed. In the second case the eps-file itself is printed, and that's the way it was since OOo 1.0 up to LO 4.1.6.2.

Created attachment 106328 [details]
Zip archive with sample ODT and three PDF renderings

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.

Something is still not correct.

(In reply to comment #35)
> 
> pstoedit: version 3.62 / DLL interface 108 (built: Apr 28 2013 - release
> build - MS VC++ 1600 - 32-bit) : Copyright (C) 1993 - 2013 Wolfgang Glunz
> ...
> Something is still not correct.

Went back and tried with earlier builds of pstoedit--3.61, 3.60, 3.50--all having similar issues in LibreOffice (ieps.cxx) with rendering curves (postscript--circle arc or bezier curveto?) with too few or mispositioned vertices/segments.

Created attachment 106336 [details]
Zip archive with same three PDF renderings but from LO 4.1.5.3

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. 

Able to zoom in with full fidelity or send for publication.  No longer the case.

@Jörn: I looked at a screenshot yes, the screenshot provided by the original bug reported to distinguish between a buggy and a working version and found that the build looked like the working version 4.1.4.

Also, "Test-document-with-graphics-from-comment-6-7-inLO41.pdf" does not show the difference between a vector and a bitmap. both images are bitmaps while the lower one has resolution decent enough for printing.


@V Stuart Foote: I think the regression you describe should get its own bug report and tackled there, since the problem as described by the original bug reporter has already been fixed.



--

I went ahead and submitted the fix for inclusion in the 4.2 and 4.3 branches.

@Björgvin, *,
(In reply to comment #38)
> 
> @V Stuart Foote: I think the regression you describe should get its own bug
> report and tackled there, since the problem as described by the original bug
> reporter has already been fixed.

Reopened bug 81497 and set new for loss of EPS vector detail when printing/exporting to PDF.

Björgvin Ragnarsson committed a patch related to this issue.
It has been pushed to "libreoffice-4-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7493c458780cce40f1b564b719c4445b8920f259&h=libreoffice-4-3

fdo#81592 Use 24-bit color depth, not 256 colors when converting an EPS-file.


It will be available in LibreOffice 4.3.3.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

@Björgvin: Would it be possible to release the patch also for LO 4.2.7? This is the last version of the 4.2.x-line and its freeze date is in a few days. Thanks!

Created attachment 106686 [details]
printout via LO 4.1.6.2 and newer versions

Today I tested the daily build LO 4.3.3.0.0-2014-09-22.
But it still doesn't print correctly (see "printout via LO 4.1.6.2 and newer versions")

@Jörn, *,
(In reply to comment #43)
> Today I tested the daily build LO 4.3.3.0.0-2014-09-22.
> But it still doesn't print correctly (see "printout via LO 4.1.6.2 and newer
> versions")

At this point, a Ghostscript only based conversion to bitmap (as BMP) is rendering EPS at 300dpi.  That is as good as it gets for 4.2 and 4.3 and master. Not clear in your script sample how far zoom'd into the image you were.

Bug 81497 is open for issues of EPS vector not being retained and used for printing to PS (or for Export to PDF), at present the pstoedit rendering of EPS as EMF/WMF is very rough with too few vertices being generated and poor use of arcs, cords and splines. Use of EPS vector images for PS printing was correct through the 4.1 builds, but has gone missing.  To get functional output, rename or uninstall pstoedit.

I must admit that I am getting really nervous about this bug and the EPS regressions since LO 4.2.x. I use LibreOffice everyday in a professional environment, so you can count me to the "conservative users". The fresh line has too many problems, so I need to use the "still" line. However, these have severe EPS regressions.

The 4.2.7 freeze is on the 29th of September and there is no fix for this bug 81592 and not for bug 81497. Also, Jörn showed in comment 42 and comment 43 that this fix is incomplete and does not fix the problem.

Conclusion: I *cannot do my work* on any fairly new LibreOffice version (4.2.x and 4.3.x line). I am bound to 4.1.x, which is EOL. Many have switched to 4.2.x or 4.3.x, but we cannot exchange documents containing EPS graphics. IMHO this is a disaster for LibreOffice!

Björgvin Ragnarsson committed a patch related to this issue.
It has been pushed to "libreoffice-4-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=bdefc56961919499cc6fda5a39c791ac6c67ca5f&h=libreoffice-4-2

fdo#81592 Use 24-bit color depth, not 256 colors when converting an EPS-file.


It will be available in LibreOffice 4.2.7.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

OK, so while Björgvin's commit has gotten us back to a proper bit depth BMP raster rendering of the EPS, mis-handling of vector WMF/EMF with pstoedit leaves 4.2 and 4.3 branches with a rather low resolution 300dpi preview.

Pending any useful response from Wolfgang Glunz on pstoedit, it should probably be removed (commented out) as it is providing no desirable vector rendering functions when present on the system path, leaving only ghostscript or Imagemagick convert as functional helpers and leaving us with bitmap only previews.

Until we can identify where we have clobbered the PS vector printing using the raw EPS (bug 81497) what would be the effect of upping the ghostscript to BMP conversion resolution? Rather than current 300dpi, would a 450dpi or even 600dpi conversion be too resource intensive? Could we insert that for the 4.2.7 final bugfix build?

@Gerry - we prefer if people "do" instead of using words that honestly give us NOTHING (literally absolute nothing) to help move us towards a solution.

So the options:
1. Fix it yourself;
2. Pay for a fix;
3. Find a friend/family/etc... who knows code to fix it;
4. Wait for a developer to fix it (volunteers).

Adding all that extra language doesn't encourage volunteers to help, doesn't show that you're being part of the community, nor add a thing to the bug report so it just clogs it.

Remember Libre is not limited to "free" - we have a community who tries to support each other. If this is such a blocker for you - please sponsor a developer to fix it (or of course fix it yourself)...or again, wait patiently for a fix.

I would like to add:

5. Help out in the hunt for the code that caused the remaining regression: https://wiki.documentfoundation.org/QA/HowToBibisect

(In reply to comment #49)
> I would like to add:
> 
> 5. Help out in the hunt for the code that caused the remaining regression:
> https://wiki.documentfoundation.org/QA/HowToBibisect

See bug 81497 c#15

@Björgvin @Joel: I sincerely apologize if my previous comment sounded rude. This was not my intention. You know that I am myself active in bug reporting and testing, and on the documentfoundation wiki. I am not a programmer and I have already donated money for enhancements. I really do not want to upset volunteers.

Why did I write my previous comment? Because these EPS regressions have the negative capability to drive users away from LibreOffice, because it makes completed work unusable. I makes users angry and they feel unsafe using LibreOffice (because something is not working anymore which did work for years). This is particularly the case with LO users that are not technically very capable.

For example, we have several documents with EPS graphics which different people collaborate on. No one is using LO 4.1.x anymore (but myself due to these regressions), so there was enormous confusion whether it is necessary to rework the graphics in the documents (which is a lot of work). I am also anxious to lose quite some of my work if these regressions remain.

I hope you now understand the intention of my previous comment. Sorry again.

@Gerry - perfectly understood but you being active (I thought you were the same Gerry by the way:) ) should understand that there are literally thousands of open bugs and it's hard to say "this one is soooooo bad" compared to the other ones. That being said - the patch hasn't resolved things? Why is there a "target . . . " if the bug still exists with the patches.

@Joel, *,
(In reply to comment #52)
> ... That being said - the patch hasn't resolved
> things? Why is there a "target . . . " if the bug still exists with the
> patches.
Right you are...

Patch for the primary BMP bit-depth issue was pushed down to 4.2,
https://gerrit.libreoffice.org/gitweb?p=core.git;a=commit;h=bdefc56961919499cc6fda5a39c791ac6c67ca5f

It will be picked up during the final builds for 4.2.7 

Setting resolved fixed.  Bug 81497 remains open for the other issue of PS printing of EPS.

Migrating Whiteboard tags to Keywords: (notBibisectable)
[NinjaEdit]