Created attachment 182885 [details] slide with eps image Open attached file in LibreOffice 7.1, e.g. in Version: 7.1.5.2 (x64) / LibreOffice Community Build ID: 85f04e9f809797b8199d13c421bd8a2b025d52b5 CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: de-DE (en_US); UI: en-US Calc: threaded You see an image. Open the file in current daily, e.g. in Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: c3b5eea4304ad6815b491f549fce008a9630c213 CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: de-DE (en_US); UI: en-US Calc: CL threaded You see only a rectangle. In case it is intended, that an eps is not handled, the placeholder should show an info about the embedded eps image and the reason for not showing it. (According https://en.wikipedia.org/wiki/Encapsulated_PostScript, Microsoft has removed support for eps for security reason, so doing the same in LO is fine for me. But I do not find an information whether the current behavior is intended.)
Just for the record, on pc Debian x86-64 with master sources updated today + gen rendering, I see a graphic with 7 bars.
Not reproducible for me with Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: fe51aa0a8d796b456a3c6966c47afc98e4532cd0 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Ubuntu_20.04_x86-64 Calc: threaded Best regards. JBF
Created attachment 182889 [details] Screenshot with 7.2.7.2 Nothing to view with Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: cc038c471e96d766db404388b140364614898bf2 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Version: 7.4.2.1 (x64) / LibreOffice Community Build ID: 681d65acd9ede00dd724d6716f21cabfdcc95bd2 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 9940a5dce79fe9dc3e6ff0302c9be8c7d1648f67 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Bars graphic with Version: 7.2.7.2 (x64) / LibreOffice Community Build ID: 8d71d29d553c0f7dcbfa38fbfda25ee34cce99a2 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: es-ES Calc: CL
Created attachment 182890 [details] On Win10 in Dark mode with both ghostscript and ImageMagick helpers on os PATH Can not confirm. The EPS images are visible on Windows builds but still require functional "helper" ImageMagick, ghostscript--and possibly pstoedit for EPS as vector image. =-testing-= Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: cc038c471e96d766db404388b140364614898bf2 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded GPL Ghostscript 9.56.1 (2022-04-04) Copyright (C) 2022 Artifex Software, Inc. All rights reserved. Version: ImageMagick 7.0.7-28 Q16 x64 2018-03-25 http://www.imagemagick.org Copyright: Copyright (C) 1999-2015 ImageMagick Studio LLC License: http://www.imagemagick.org/script/license.php Visual C++: 180040629 Features: Cipher DPC HDRI Modules OpenMP Delegates (built-in): bzlib cairo flif freetype gslib heic jng jp2 jpeg lcms lqr openexr pangocairo png ps raw rsvg tiff webp xml zlib
Reproduced this Windows-only issue like Regina and Miguel Angel, no image displayed in: Version: 7.5.0.1 (X86_64) / LibreOffice Community Build ID: 77cd3d7ad4445740a0c6cf977992dafd8ebad8df CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: threaded Version: 7.4.3.2 (x64) / LibreOffice Community Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: threaded But EPS rendered in: Version: 7.3.0.0.alpha1 (x64) / LibreOffice Community Build ID: a3c29ae3d906f4692090bd4e5dab29623c66014a CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: threaded
Created attachment 184544 [details] Win10 Dark theme mode with ghostscript and imagemagik *on path* Again, can not confirm on a properly configured system, i.e. ghostscript and imagemagick helper programs *on path*! Attached from 7.5.0.1 release build shows the eps on canvas.
Thanks Stuart! Sorry I missed that important bit. Installing ImageMagick (ImageMagick-7.1.0-57-Q16-HDRI-x64-dll), making sure it is added to the path by ticking the option during install, made no difference. With Ghostscript version 10.0.0 (2022-08-21) installed (and _without_ ImageMagick), the image is rendered on Windows 10 in LO 7.6 alpha0+, 7.5.0.1 and 7.4.3.2. Do you know what change since 7.4 branching made it so users need an extra library to be installed alongside LO for it to render EPS? Most users would see this as a regression, given that it used to work without that extra step, and given that inserting an image is perceived as a simple feature (even though EPS is much more than a raster). I couldn't find any documentation about it, and Regina is right in that if built-in support was dropped, the users should be informed somehow (via message, banner or visual on the element itself).
If I remember correctly, OOo and LibreOffice have never been able to interpret PS/EPS files. What you see is the preview that is embedded in the EPS file. So I guess that the change was about the support of the format of the preview. Best regards. JBF
(In reply to Jean-Baptiste Faure from comment #8) > If I remember correctly, OOo and LibreOffice have never been able to > interpret PS/EPS files. What you see is the preview that is embedded in the > EPS file. So I guess that the change was about the support of the format of > the preview. > Not the whole case, when one of three helper programs is available: pstoedit, ghostscript or Imagemagick (all ghostscript dependent) we can parse EPS [1] to EMF using pstoedit. Or to BMP using ghostscript script, or to BMP using Convert from Imagemagick. If none are present *AND* the EPS has a preview embedded, we'll read that preview image. And if it does not, we get a place holder frame. =-ref-= [1] https://opengrok.libreoffice.org/xref/core/vcl/source/filter/ieps/ieps.cxx?r=4b95451f RenderAsEMF RenderAsBMPThroughGS RenerAsBMPThroughConvert CreateMtfReplacementAction
bisected to 468664d8d9ca2f290d691b927b31a0fbd0365bb6 is the first bad commit commit 468664d8d9ca2f290d691b927b31a0fbd0365bb6 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Sat May 21 03:07:20 2022 -0700 source 22b50f1937de67e4ad9e692d6964aa5b8d33af7a https://gerrit.libreoffice.org/c/core/+/134647 CC to Caolán McNamara
message in command line: TIFFFetchDirectory: Sanity check on directory count failed, this is probably not a valid IFD offset. TIFFReadDirectory: Failed to read directory at offset 342152.
Just for the record, on pc Debian x86-64 with master sources updated today + gen rendering, I don't reproduce this. I've just noticed: warn:sal.osl:27457:27457:sal/osl/unx/file.cxx:304: FileHandle_Impl::readAt(): not seekable
(In reply to Julien Nabet from comment #12) > Just for the record, on pc Debian x86-64 with master sources updated today + > gen rendering, I don't reproduce this. > > I've just noticed: > warn:sal.osl:27457:27457:sal/osl/unx/file.cxx:304: > FileHandle_Impl::readAt(): not seekable Here's part of bt from this log: #0 (anonymous namespace)::FileHandle_Impl::readAt(long, void*, unsigned long, unsigned long*) (this=0x7f0de0048090, nOffset=0, pBuffer=0x7f0de0022560, nBytesRequested=4096, pBytesRead=0x7fffed346490) at sal/osl/unx/file.cxx:304 #1 0x00007f0e202d42ea in (anonymous namespace)::FileHandle_Impl::readLineAt(long, _sal_Sequence**, unsigned long*) (this=0x7f0de0048090, nOffset=0, ppSequence=0x7fffed3465f8, pBytesRead=0x7fffed346500) at sal/osl/unx/file.cxx:553 #2 0x00007f0e202d41bd in osl_readLine(oslFileHandle, sal_Sequence**) (Handle=0x7f0de0048090, ppSequence=0x7fffed3465f8) at sal/osl/unx/file.cxx:1365 #3 0x00007f0e178fa8ad in RenderAsEMF(unsigned char const*, unsigned int, Graphic&) (pBuf=0x560a9b295320 "%!PS-Adobe-2.0 EPSF-2.0\n%% This is a Stata generated postscript file\n%%BoundingBox: 0 0 396 288\n%%HiResBoundingBox: 0.000 0.000 396.000 288.000\n%%DocumentNeededResources: font Helvetica\n/xratio 0.0123"..., nBytesRead=16467, rGraphic=...) at vcl/source/filter/ieps/ieps.cxx:256 #4 0x00007f0e178f9711 in ImportEpsGraphic(SvStream&, Graphic&) (rStream=..., rGraphic=...) at vcl/source/filter/ieps/ieps.cxx:794 #5 0x00007f0e178b63ea in GraphicFilter::readEPS(SvStream&, Graphic&) (rStream=..., rGraphic=...) at vcl/source/filter/graphicfilter.cxx:1269 #6 0x00007f0e178b0995 in GraphicFilter::ImportGraphic(Graphic&, std::basic_string_view<char16_t, std::char_traits<char16_t> >, SvStream&, unsigned short, unsigned short*, GraphicFilterImportFlags) (this=0x7f0e18295680 <GraphicFilter::GetGraphicFilter()::gStandardFilter>, rGraphic=..., rPath=u"", rIStream=..., nFormat=4, pDeterminedFormat=0x0, nImportFlags=GraphicFilterImportFlags::NONE) at vcl/source/filter/graphicfilter.cxx:1456 #7 0x00007f0e1ac89e0a in SvXMLGraphicHelper::ImplReadGraphic(rtl::OUString const&, rtl::OUString const&) (this=0x560a9aee9c00, rPictureStorageName="Pictures", rPictureStreamName="200000020000018D00000121F85E95738BE78197.eps") at svx/source/xml/xmlgrhlp.cxx:507 #8 0x00007f0e1ac8a4f1 in SvXMLGraphicHelper::loadGraphic(rtl::OUString const&) (this=0x560a9aee9c00, rURL="Pictures/200000020000018D00000121F85E95738BE78197.eps") at svx/source/xml/xmlgrhlp.cxx:588 #9 0x00007f0e1ac8a83f in non-virtual thunk to SvXMLGraphicHelper::loadGraphic(rtl::OUString const&) () at /home/julien/lo/libreoffice/instdir/program/libsvxcorelo.so #10 0x00007f0e1347805f in SvXMLImport::loadGraphicByURL(rtl::OUString const&) (this=0x560a9b2fd000, rURL="Pictures/200000020000018D00000121F85E95738BE78197.eps") at xmloff/source/core/xmlimp.cxx:1284 #11 0x00007f0e136541b4 in SdXMLGraphicObjectShapeContext::startFastElement(int, com::sun::star::uno::Reference<com::sun::star::xml::sax::XFastAttributeList> const&) (this=0x560a9ac35900, nElement=328666, xAttrList=uno::Reference to (sax_fastparser::FastAttributeList *) 0x7f0de0022058) at xmloff/source/draw/ximpshap.cxx:2361
When I extract the EPS image 200000020000018D00000121F85E95738BE78197.eps from the attachment 182885 [details] ODF archive and use the ImageMagick utility "identify" it errors with: C:\Users\vsfoote\Downloads>identify -verbose 200000020000018D00000121F85E95738BE78197.eps identify: improper image header `200000020000018D00000121F85E95738BE78197.eps' @ error/ept.c/ReadEPTImage/235. If I manually edit the EPS and remove the initial apparent bitmap preview down to the EPS header: %!PS-Adobe-2.0 EPSF-2.0 %% This is a Stata generated postscript file ImageMagick's identify is happy, and the EPS opens cleanly. So is this just a one-off corrupt EPS, with a corrupted preview image?
IIRC our ghostscript and Imagemagick based "render as BMP" paths for the ieps.cxx filter simply ignore any preview in the EPS.
I think the issue is that the tiff is at an offset within the stream so some adjustment is needed
https://gerrit.libreoffice.org/c/core/+/147162 is my thinking here
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/55a5e9baa5a707b04aeda7b1ea4dc983483d5ce3 Resolves: tdf#151395 need to track tiff offset from start of stream It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
done in trunk, backport to 7-5 in gerrit
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/07858f9fb48776ca4d5e380490d008640185db47 Resolves: tdf#151395 need to track tiff offset from start of stream It will be available in 7.5.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.