Bug 86712 - EPS figure not correctly rendered
Summary: EPS figure not correctly rendered
Status: NEEDINFO
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Presentation (show other bugs)
Version: 4.3.3.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 67464
Blocks:
  Show dependency treegraph
 
Reported: 2014-11-25 19:11 UTC by Dongliang Zhang
Modified: 2014-12-03 10:26 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


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, text/plain)
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

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


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.