Created attachment 146185 [details] Sample file with images missing on import on Linux/macOS The attached sample has 3 images over cells A5, A6, and A7. They are visible in MS Excel, and in LO on Windows; but when open in LO on Ubuntu 16.04, 18.04, or on macOS, the images are missing [1]. Tested myself with Version: 6.1.2.1 Build ID: 1:6.1.2~rc1-0ubuntu0.18.04.1 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); Calc: Also tested on Windows to confirm that it shows images there with Version: 6.1.3.2 (x64) Build ID: 86daf60bf00efa86ad547e59e09d6bb77c699acb CPU threads: 12; OS: Windows 10.0; UI render: GL; Locale: ru-RU (ru_RU); Calc: CL [1] Original report: http://forumooo.ru/index.php/topic,7353 (Russian)
Created attachment 146186 [details] Screenshot on Ubuntu 18.04
Created attachment 146187 [details] Screenshot on Windows 10
First bugreport I see, where something is broken on all platforms _except_ Windows :-) And I can confirm I don't see the included images on todays master, neither in the document, nor in the navigator. Version: 6.2.0.0.alpha1+ Build-ID: d72c915794eb4453dc580fc0dcdfbe3503a4879b CPU-Threads: 64; BS: Linux 3.16; UI-Render: Standard; VCL: x11; Gebietsschema: de-DE (de_DE.UTF-8); Calc: threaded In the terminal I see: warn:legacy.osl:19680:19680:oox/source/helper/graphichelper.cxx:119: GraphicHelper::GraphicHelper - cannot get target frame
excel 2016 complains attached *.xslx is corrupted, will not open .... seems to be created with Microsoft Excel Online/16.0300
(In reply to Oliver Brinzing from comment #4) Just re-tested with Excel 2016 on Win10, and received no warnings/errors.
Created attachment 146216 [details] ms excel 2016 tried again, same result ... opens fine with lo 6.1.3.1 ... D:\>md5sum price_bitiy_obrazets-1.xlsx 10fdef01e4a87eb25fcc344917d5d9de *price_bitiy_obrazets-1.xlsx
excel tried top open file in protected view (https://support.office.com/en-us/article/what-is-protected-view-d6f09ac7-e6b9-4495-8e43-2bbcdbcb6653) and fails. after changing file properties, it will open.
Created attachment 146230 [details] console logs On pc Debian x86-64 with master sources updated yesterday, I could reproduce this. I attached console logs: warn:legacy.osl:3913:3913:oox/source/helper/graphichelper.cxx:119: GraphicHelper::GraphicHelper - cannot get target frame warn:oox:3913:3913:oox/source/drawingml/shapecontext.cxx:129: ShapeContext::onCreateContext: unhandled element: 2146 warn:oox:3913:3913:oox/source/drawingml/shapecontext.cxx:129: ShapeContext::onCreateContext: unhandled element: 2144 warn:legacy.osl:3913:3913:sc/source/filter/oox/worksheethelper.cxx:533: WorksheetGlobals::getDrawPageSize - called too early, size invalid
Seems to be inherit from OOo. I see the images in LibreOffice 3.3.0 Win OOO330m19 (Build:6) tag libreoffice-3.3.0.4 but not in LibreOffice 3.3.0 Linux OOO330m19 (Build:6) tag libreoffice-3.3.0.4
Dear Mike Kaganski, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
still repro in Version: 6.5.0.0.alpha0+ Build ID: e22a3f596ce50b5166063e217d96ef674a54d380 CPU threads: 4; OS: Mac OS X 10.15.2; UI render: GL; VCL: osx; Locale: ru-RU (ru_RU.UTF-8); UI-Language: en-US Calc: threaded
On pc Debian x86-64 with master sources updated today, same results with same logs: warn:legacy.osl:99391:99391:oox/source/helper/graphichelper.cxx:120: GraphicHelper::GraphicHelper - cannot get target frame warn:oox:99391:99391:oox/source/drawingml/shapecontext.cxx:130: ShapeContext::onCreateContext: unhandled element: 2146 warn:oox:99391:99391:oox/source/drawingml/shapecontext.cxx:130: ShapeContext::onCreateContext: unhandled element: 2144 warn:legacy.osl:99391:99391:sc/source/filter/oox/worksheethelper.cxx:530: WorksheetGlobals::getDrawPageSize - called too early, size invalid warn:oox:99391:99391:oox/source/drawingml/shapecontext.cxx:130: ShapeContext::onCreateContext: unhandled element: 2146 warn:oox:99391:99391:oox/source/drawingml/shapecontext.cxx:130: ShapeContext::onCreateContext: unhandled element: 2144 warn:legacy.osl:99391:99391:sc/source/filter/oox/worksheethelper.cxx:530: WorksheetGlobals::getDrawPageSize - called too early, size invalid ...
I also noticed this on gdb: Thread 1 "soffice.bin" hit Breakpoint 3, oox::xls::WorksheetGlobals::getDrawPageSize (this=0x55555c5e3470) at /home/julien/lo/libreoffice/sc/source/filter/oox/worksheethelper.cxx:530 530 OSL_ENSURE( (maDrawPageSize.Width > 0) && (maDrawPageSize.Height > 0), "WorksheetGlobals::getDrawPageSize - called too early, size invalid" ); (gdb) p maDrawPageSize $5 = {Width = 1852758, Height = -1077093842}
Keeping on digging, I found this: (gdb) p aAwtSize $13 = {Width = 1852758, Height = -1077093842} (gdb) bt #0 0x00007fffda954b38 in ScCellRangeObj::GetOnePropertyValue(SfxItemPropertySimpleEntry const*, com::sun::star::uno::Any&) (this=0x55555895e9a0, pEntry=0x555558605670, rAny=uno::Any(void)) at /home/julien/lo/libreoffice/sc/source/ui/unoobj/cellsuno.cxx:5752 #1 0x00007fffda941cbd in ScCellRangesBase::getPropertyValue(rtl::OUString const&) (this=0x55555895e9a0, aPropertyName="Size") at /home/julien/lo/libreoffice/sc/source/ui/unoobj/cellsuno.cxx:2383 #2 0x00007fffdcc5d18d in oox::PropertySet::implGetPropertyValue(com::sun::star::uno::Any&, rtl::OUString const&) const (this=0x7ffffffef420, orValue=uno::Any(void), rPropName="Size") at /home/julien/lo/libreoffice/oox/source/helper/propertyset.cxx:116 #3 0x00007fffdcc5cd47 in oox::PropertySet::getAnyProperty(int) const (this=0x7ffffffef420, nPropId=473) at /home/julien/lo/libreoffice/oox/source/helper/propertyset.cxx:66 #4 0x00007fffd86f292b in oox::PropertySet::getProperty<com::sun::star::awt::Size>(com::sun::star::awt::Size&, int) const (this=0x7ffffffef420, orValue=..., nPropId=473) at /home/julien/lo/libreoffice/include/oox/helper/propertyset.hxx:95 #5 0x00007fffd872889b in oox::xls::WorksheetGlobals::finalizeDrawings() (this=0x5555589563f0) at /home/julien/lo/libreoffice/sc/source/filter/oox/worksheethelper.cxx:1316 #6 0x00007fffd87268a6 in oox::xls::WorksheetGlobals::finalizeDrawingImport() (this=0x5555589563f0) at /home/julien/lo/libreoffice/sc/source/filter/oox/worksheethelper.cxx:956 #7 0x00007fffd8729504 in oox::xls::WorksheetHelper::finalizeDrawingImport() (this=0x555558acfdc8) at /home/julien/lo/libreoffice/sc/source/filter/oox/worksheethelper.cxx:1569 #8 0x00007fffd86ff6a1 in oox::xls::WorkbookFragment::finalizeImport() (this=0x55555891ae00) at /home/julien/lo/libreoffice/sc/source/filter/oox/workbookfragment.cxx:488 #9 0x00007fffdc9406c1 in oox::core::FragmentHandler2::endDocument() (this=0x55555891ae00) at /home/julien/lo/libreoffice/oox/source/core/fragmenthandler2.cxx:54 #10 0x00007fffddae76b5 in sax_fastparser::FastSaxParserImpl::parseStream(com::sun::star::xml::sax::InputSource const&) (this=0x55555891b0e0, rStructSource=...) at /home/julien/lo/libreoffice/sax/source/fastparser/fastparser.cxx:875 #11 0x00007fffddaea786 in sax_fastparser::FastSaxParser::parseStream(com::sun::star::xml::sax::InputSource const&) (this=0x55555891b5e0, aInputSource=...) at /home/julien/lo/libreoffice/sax/source/fastparser/fastparser.cxx:1367 #12 0x00007fffdc923c07 in oox::core::FastParser::parseStream(com::sun::star::xml::sax::InputSource const&, bool) (this=0x7ffffffefa40, rInputSource=..., bCloseStream=false) at /home/julien/lo/libreoffice/oox/source/core/fastparser.cxx:124 #13 0x00007fffdc923cd0 in oox::core::FastParser::parseStream(com::sun::star::uno::Reference<com::sun::star::io::XInputStream> const&, rtl::OUString const&) (this=0x7ffffffefa40, rxInStream= uno::Reference to (OInputCompStream *) 0x55555891bc68, rStreamName="xl/workbook.xml") at /home/julien/lo/libreoffice/oox/source/core/fastparser.cxx:132 #14 0x00007fffdc956a18 in oox::core::XmlFilterBase::importFragment(rtl::Reference<oox::core::FragmentHandler> const&, oox::core::FastParser&) (this=0x5555585905c0, rxHandler=rtl::Reference to 0x55555891ae00, rParser=...) at /home/julien/lo/libreoffice/oox/source/core/xmlfilterbase.cxx:407 So conversion between Size and awt::Size seems wrong here.
I gave a try with https://gerrit.libreoffice.org/c/core/+/86635
On Windows that line is only called once for to get the drawing page size (call from WorksheetGlobals::finalizeDrawings() line 1316). It is not called for the cells of the images. On Windows the images have the wrong anchor type "To cell (resize with cell)". It should be "To cell" because in Excel it is "Move but don't size with cell".
(In reply to Julien Nabet from comment #13) > I also noticed this on gdb: > Thread 1 "soffice.bin" hit Breakpoint 3, > oox::xls::WorksheetGlobals::getDrawPageSize (this=0x55555c5e3470) at > /home/julien/lo/libreoffice/sc/source/filter/oox/worksheethelper.cxx:530 > 530 OSL_ENSURE( (maDrawPageSize.Width > 0) && (maDrawPageSize.Height > > 0), "WorksheetGlobals::getDrawPageSize - called too early, size invalid" ); > (gdb) p maDrawPageSize > $5 = {Width = 1852758, Height = -1077093842} Mike: on Win10 with master sources updated today + Visual Studio 2019 (16.4.2), I added a trace and got this: aSize.Width()=1852758 aSize.Height()=2147483647 So here Height is positive => no pb to display images.
So yes, the problem is different size of long in used in generic Size (*not* awt::Size): long is 4-byte on all architectures on Windows (or rather MSVC), while it's 8 byte on 64-bit gcc/clang. Note that "long" in IDL is always 4-byte, so awt::Size is consistently uses sal_Int32 on all platforms. On Windows, ScDocument::GetMMRect overflows aRect's 32-bit height when multiplying 1824306210 by HMM_PER_TWIPS (~1.7), resulting in -2147483648 (SAL_MIN_INT32). Later, calculating resulting height, and subtracting 1 from that, positive 2147483647 (SAL_MAX_INT32) appears, which successfully goes into awt:Size. On other platforms, ScDocument::GetMMRect produces correct 64-bit height, which overflows only when copying to awt::Size, resulting in negative value there. Converting the result of ScDocument::GetMMRect (already in MM100) from twips to MM100 is incorrect; it could only succeed here because that would become more than 0xFFFFFFFF, and owerflowing when writing to awt::Size would again give positive fake result...
(In reply to Mike Kaganski from comment #18) >... > Converting the result of ScDocument::GetMMRect (already in MM100) from twips > to MM100 is incorrect; it could only succeed here because that would become > more than 0xFFFFFFFF, and owerflowing when writing to awt::Size would again > give positive fake result... As you may have seen, I abandoned the patch since it's wrong.
Created attachment 157133 [details] A sketch of possible fix Something like this could be a starting point for a fix; it would keep Win behaviour unchanged, and everything using 64-bit integers in Size would be clamped. The templated functions could get it to o3tl/safeint.hxx or something... Whoever wants to continue workind on it: please take it if you like. I can't work on this task ATM.
Seems resolved today. *** This bug has been marked as a duplicate of bug 147014 ***