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.
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)
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.
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 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
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
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.
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
(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.
(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.
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
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
(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.
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?
(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.
(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!