Bug 86712 - EPS figure not correctly rendered
Summary: EPS figure not correctly rendered
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
4.3.3.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Images-EPS
  Show dependency treegraph
 
Reported: 2014-11-25 19:11 UTC by Dongliang Zhang
Modified: 2017-10-21 22:52 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
The eps figure used in test: test.eps.eps; the odp docuemnt: test.odp and the pdf file genearted from it: test.pdf (130.00 KB, application/x-compressed-tar)
2014-11-25 19:11 UTC, Dongliang Zhang
Details
screenClip test.odp open in LO 4351 (101.00 KB, image/png)
2014-11-29 16:14 UTC, V Stuart Foote
Details
EPS vector image from test kit rendered directly into PDF with ghostscript ps2pdf (4.41 KB, application/pdf)
2014-11-29 16:30 UTC, V Stuart Foote
Details
imported and orignal figure (108.36 KB, image/png)
2015-03-20 19:26 UTC, Dongliang Zhang
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dongliang Zhang 2014-11-25 19:11:41 UTC
Created attachment 110011 [details]
The eps figure used in test: test.eps.eps; the odp docuemnt: test.odp and the pdf file genearted from it: test.pdf

An example is attached. You can see clearly the eps figure in the odp document and the pdf document generated from it that the label of the y axis is not correctly rendered as the original figure.
Comment 1 V Stuart Foote 2014-11-29 16:14:46 UTC
Created attachment 110229 [details]
screenClip test.odp open in LO 4351

@Dongliang, *,

Can not reproduce.

Looking at the meta.xml for the .odp in the tar test kit, you are using 64-bit LO 4.3.3.2 on a Linux. Have set The EPS provided in your test kit matches the 2000000200000238000001816A594820.eps embedded in .ODP 

Available helper programs on a system will make a difference in handling of EPS and other vector/bitmap image formats. Also, LibreOffice's "export to PDF" uses different output filters than the "print to PS"--so results will differ depending on the method used to generate the PDF.

But, to completely replicate for testing, we will need to know version of ghostscript, pstoedit and imagemagick installed on your system.

We need your system configuration, and your exact steps in generating the PDF.

-=note=-
In general EPS handling remains an issue, but there have been some improvements, with additional work needed, refs below.

-=ref=-
bug 81592 (use 24-bit vs 8-bit color depth for internal BMP raster)
with additional work as in
bug 67464 (a native EPS handler)
Comment 2 V Stuart Foote 2014-11-29 16:30:15 UTC
Created attachment 110230 [details]
EPS vector image from test kit rendered directly into PDF with ghostscript ps2pdf

Reference PDF directly rendered from EPS using ghostscript ps2pdf command

ps2pdf -dEPSCrop <imagename>.eps

There are filter differences in an export to PDF and print PS to PDF. See bug 81497 regards issues when printing PS to PDF.
Comment 3 Dongliang Zhang 2014-12-03 10:26:36 UTC
Hi V Stuart Foote,
Thanks for looking into this report.
I can get the same good pdf figure as you attached using ps2pdf, but as you can see in my first attachment, the pdf file converted form odp file is different.

The pdf is produced by "Export to PDF" icon, but I get the same results when I tried "print" to file. The figure already looks like the one shown in pdf file when I insert it into the odp file.

I'm using Scientific Linux 6.6:
----------------------
dzhang@Linqi:~ 1009$uname -srvmpio
Linux 2.6.32-504.1.3.el6.x86_64 #1 SMP Tue Nov 11 14:19:04 CST 2014 x86_64 x86_64 x86_64 GNU/Linux
---------------------

and here is the information of the packages:
-----------
Name : ghostscript
Arch : x86_64
Version : 8.70
Release : 19.el6

Name : pstoedit
Arch : x86_64
Version : 3.45
Release : 10.el6

Name : ImageMagick
Arch : x86_64
Version : 6.5.4.7
Release : 7.el6_5
-----------

Let me know if you need any more information. Thanks.

Dongliang
Comment 4 V Stuart Foote 2015-03-20 15:52:11 UTC
Comment on attachment 110011 [details]
The eps figure used in test: test.eps.eps; the odp docuemnt: test.odp and the pdf file genearted from it: test.pdf

adjusted mime type
Comment 5 V Stuart Foote 2015-03-20 16:10:12 UTC
Can not reproduce,  as with 4.3.5, get a correct PDF export (image as bitmap not vector) with current 4.5.0alpha0+

Version: 4.5.0.0.alpha0+
Build ID: 181feb38d95e25980b96c2f6802cc906410abb13
TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-03-19_23:38:28
Locale: en_US

On a system with ghostscript, pstoedit and Imagemagick's conver--except for bitmap rather than vector (bug 81497) PS print to PDF, or Export to PDF layout matches the direct conversion of EPS to PDF using ghostscript's ps2pdf
Comment 6 Dongliang Zhang 2015-03-20 19:26:36 UTC
Created attachment 114219 [details]
imported and orignal figure

top left is the original figure, and the center is the figure imported to LO, and it's different with the original one.
Comment 7 Dongliang Zhang 2015-03-20 19:31:18 UTC
Hi V Stuart Foote,
Maybe I didn't make it clear. The figure already looks weird when it's imported to LO, as you can see in the screenshot I just attached. It probably is not the problem of PDF converting, but how LO manipulate the imported figure to show it and pass it to the PDF printer.

Thanks,
Dongliang
Comment 8 V Stuart Foote 2015-03-20 22:35:17 UTC
(In reply to Dongliang Zhang from comment #7)
OK, setting this the more polite Resolved Worksforme...

The test.eps.eps does not contain a preview. So, LibreOffice must first use one of the helper programs--either pstoedit & ghostscript, or ghostscript, or convert to generate a preview.  That preview is then used inside the open ODF document.

I've seen some of these issues with vector previews from pstoedit, but never with bitmap previews, and not with current pstoedit renderings. 

The build versions you list are rather out of date, as is your 4.3.3 build of LibreOffice

Current release of the key helpers are

ghostscript -- 9.15
ImageMagick -- 6.9.0-10
pstoedit -- 3.70

Please if you could go ahead and update LibreOffice as well as your set of helper programs. If you are still having the issue of incorrect label placement in the preview image go ahead and reopen.
Comment 9 Dongliang Zhang 2015-03-20 23:30:39 UTC
(In reply to V Stuart Foote from comment #8)
> (In reply to Dongliang Zhang from comment #7)
> OK, setting this the more polite Resolved Worksforme...
> 
> The test.eps.eps does not contain a preview. So, LibreOffice must first use
> one of the helper programs--either pstoedit & ghostscript, or ghostscript,
> or convert to generate a preview.  That preview is then used inside the open
> ODF document.
> 
> I've seen some of these issues with vector previews from pstoedit, but never
> with bitmap previews, and not with current pstoedit renderings. 
> 
> The build versions you list are rather out of date, as is your 4.3.3 build
> of LibreOffice
Thanks for the quick reply.
I tested it using 4.4 today, the problem is still there.

> 
> Current release of the key helpers are
> 
> ghostscript -- 9.15
> ImageMagick -- 6.9.0-10
> pstoedit -- 3.70
I'm using the default packages on my system, my OS is a bit old, but it's still supported. I'm not going to compile the new version of these packages by myself.
Can you tell me what's the exact command used to produce the bitmap? Or maybe the related code? I can try to dig more when I'm free.

Sorry for insisting on this. Actually, nowadays I usually use latex and MS web apps. But I still feel better if I had a working LO on my laptop... 

> 
> Please if you could go ahead and update LibreOffice as well as your set of
> helper programs. If you are still having the issue of incorrect label
> placement in the preview image go ahead and reopen.
Comment 10 V Stuart Foote 2015-03-20 23:58:43 UTC
If pstoedit and convert are on path you can issue these commands to see where you are at with your versions of pstoedit, Imagemagick and ghostscript.

$pstoedit -usebbfrominput -f emf:-OO -drawbb test.eps.eps test.out.emf

$convert -density 300x300 eps:test.eps.eps png:test.out.png

$convert -density 300x300 eps:test.eps.eps bmp:test.out.bmp
Comment 11 V Stuart Foote 2015-03-21 00:20:33 UTC
Or here is the one that I always have to hunt down syntax for, using ghostscript to generate PDF, or PNG, from EPS.

gs -o test.gs.out.pdf -sDEVICE=pdfwrite -dEPSCrop test.eps.eps

gs -o test.gs.out.png -sDEVICE=png16m -dEPSCrop test.eps.eps
Comment 12 V Stuart Foote 2015-03-21 00:26:04 UTC
(In reply to V Stuart Foote from comment #11)
> gs -o test.gs.out.png -sDEVICE=png16m -dEPSCrop test.eps.eps

Sorry, for generating the PNG with Ghostscript, should add an -r300 to match the resolution of the convert.

So:

gs -o test.gs.out.png -sDEVICE=png16m -dEPSCrop -r300 test.eps.eps


Run those sets of command line renderings and you should be able to tell which, if any, of your helper apps are corrupting the preview rendering in LibreOffice. Then maybe update that first.
Comment 13 Dongliang Zhang 2015-03-21 00:33:21 UTC
Thanks for the commands.
I tested them. The problem one is:
---------
$pstoedit -usebbfrominput -f emf:"-drawbb -OO" test.eps.eps bad_test.out.emf
pstoedit: version 3.45 / DLL interface 108 (build Nov 23 2010 - release build - g++ 4.4.4 20100726 (Red Hat 4.4.4-13)) : Copyright (C) 1993 - 2007 Wolfgang Glunz
Warning: Inter letter spacing is approximated by pstoedit because of problems in libemf. Use -pta option if results are not OK.
--------
When I import the output bad_test.out.emf, I see the problematic figure.

And if I add the option "-pta" as suggested I can get a nice figure and correctly import it.

All other generated figures looks good from the command `display`.

Can I tell the LO to use other commands instead of the problematic one? Or maybe the developer can add a "fix" (I mean maybe backward compatibility) to the code in the next version?
Comment 14 V Stuart Foote 2015-03-22 17:01:04 UTC
(In reply to Dongliang Zhang from comment #13)
...
> I tested them. The problem one is:
> ---------
> $pstoedit -usebbfrominput -f emf:"-drawbb -OO" test.eps.eps bad_test.out.emf
> pstoedit: version 3.45 / DLL interface 108 (build Nov 23 2010 - release
> build - g++ 4.4.4 20100726 (Red Hat 4.4.4-13)) : Copyright (C) 1993 - 2007
> Wolfgang Glunz
> Warning: Inter letter spacing is approximated by pstoedit because of
> problems in libemf. Use -pta option if results are not OK.
> --------
> When I import the output bad_test.out.emf, I see the problematic figure.
...
> Can I tell the LO to use other commands instead of the problematic one? 

At a command prompt run: "$which pstoedit" and note its path, and "cd" to that directory. Then suppress it by renaming the command, e.g.  $sudo mv pstoedit pstoedit_keep

The simple change of its name will force it to be avoided, then either Imagemagick "convert" or ghostscript "gs" will be used and previews/rendering will be raster rather than vector. The default helpers and file formats have been tweaked between LO version 4.2 -> 4.4

> Or maybe the developer can add a "fix" (I mean maybe backward compatibility)
> to the code in the next version?

Rather unlikely. You as a user are responsible for resolving these sorts of external dependencies. You might solicit your Linux distribution to update and post more current RPMs for SL 6.6, or even consider moving to SL 7, or RHEL/Centos 7.
Comment 15 Dongliang Zhang 2015-03-23 08:42:46 UTC
(In reply to V Stuart Foote from comment #14)
> (In reply to Dongliang Zhang from comment #13)
> ...
> > I tested them. The problem one is:
> > ---------
> > $pstoedit -usebbfrominput -f emf:"-drawbb -OO" test.eps.eps bad_test.out.emf
> > pstoedit: version 3.45 / DLL interface 108 (build Nov 23 2010 - release
> > build - g++ 4.4.4 20100726 (Red Hat 4.4.4-13)) : Copyright (C) 1993 - 2007
> > Wolfgang Glunz
> > Warning: Inter letter spacing is approximated by pstoedit because of
> > problems in libemf. Use -pta option if results are not OK.
> > --------
> > When I import the output bad_test.out.emf, I see the problematic figure.
> ...
> > Can I tell the LO to use other commands instead of the problematic one? 
> 
> At a command prompt run: "$which pstoedit" and note its path, and "cd" to
> that directory. Then suppress it by renaming the command, e.g.  $sudo mv
> pstoedit pstoedit_keep

I'm not sure this is a good idea. I need root privilege, and it may broke other packages that depend on it (maybe, at least yum?). Actually I tried removing the package and found it works, but the resolution became too poor.

> 
> The simple change of its name will force it to be avoided, then either
> Imagemagick "convert" or ghostscript "gs" will be used and
> previews/rendering will be raster rather than vector. The default helpers
> and file formats have been tweaked between LO version 4.2 -> 4.4
> 
> > Or maybe the developer can add a "fix" (I mean maybe backward compatibility)
> > to the code in the next version?
> 
> Rather unlikely. You as a user are responsible for resolving these sorts of
> external dependencies. You might solicit your Linux distribution to update
> and post more current RPMs for SL 6.6, or even consider moving to SL 7, or
> RHEL/Centos 7.
OK. I simply understand that LO is not supporting SL6 now. I'm quite happy with the current OS, which will be supported by the vendor to at least 2020. And even MS is still providing a working Skype for it...

When I really need to use LO Impress (actually Writer does not have this problem..), I might try converting the figure by hand using the -pta option.
Thank you very much for the helps!