Download it now!
Bug 121074 - Missing images in an XLSX on Linux and macOS (OK on Windows)
Summary: Missing images in an XLSX on Linux and macOS (OK on Windows)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:xlsx
Depends on:
Blocks: XLSX
  Show dependency treegraph
 
Reported: 2018-10-31 09:41 UTC by Mike Kaganski
Modified: 2020-01-13 22:17 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample file with images missing on import on Linux/macOS (76.72 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2018-10-31 09:41 UTC, Mike Kaganski
Details
Screenshot on Ubuntu 18.04 (195.23 KB, image/png)
2018-10-31 09:41 UTC, Mike Kaganski
Details
Screenshot on Windows 10 (266.26 KB, image/png)
2018-10-31 09:42 UTC, Mike Kaganski
Details
ms excel 2016 (42.40 KB, image/jpeg)
2018-11-01 09:55 UTC, Oliver Brinzing
Details
console logs (3.13 KB, text/plain)
2018-11-01 18:03 UTC, Julien Nabet
Details
A sketch of possible fix (2.89 KB, patch)
2020-01-13 22:17 UTC, Mike Kaganski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2018-10-31 09:41:23 UTC
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)
Comment 1 Mike Kaganski 2018-10-31 09:41:59 UTC
Created attachment 146186 [details]
Screenshot on Ubuntu 18.04
Comment 2 Mike Kaganski 2018-10-31 09:42:57 UTC
Created attachment 146187 [details]
Screenshot on Windows 10
Comment 3 Jan-Marek Glogowski 2018-10-31 12:47:16 UTC
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
Comment 4 Oliver Brinzing 2018-11-01 09:47:12 UTC
excel 2016 complains attached *.xslx is corrupted, will not open ....
seems to be created with Microsoft Excel Online/16.0300
Comment 5 Mike Kaganski 2018-11-01 09:49:28 UTC
(In reply to Oliver Brinzing from comment #4)

Just re-tested with Excel 2016 on Win10, and received no warnings/errors.
Comment 6 Oliver Brinzing 2018-11-01 09:55:52 UTC
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
Comment 7 Oliver Brinzing 2018-11-01 10:13:55 UTC
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.
Comment 8 Julien Nabet 2018-11-01 18:03:25 UTC
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
Comment 9 Xisco Faulí 2018-11-02 17:52:35 UTC
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
Comment 10 QA Administrators 2019-12-10 04:08:52 UTC Comment hidden (obsolete)
Comment 11 Roman Kuznetsov 2020-01-02 11:10:17 UTC
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
Comment 12 Julien Nabet 2020-01-12 10:20:34 UTC
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
...
Comment 13 Julien Nabet 2020-01-12 10:31:44 UTC
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}
Comment 14 Julien Nabet 2020-01-12 11:31:51 UTC
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.
Comment 15 Julien Nabet 2020-01-12 11:39:53 UTC
I gave a try with https://gerrit.libreoffice.org/c/core/+/86635
Comment 16 Regina Henschel 2020-01-13 13:31:29 UTC
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".
Comment 17 Julien Nabet 2020-01-13 16:14:23 UTC
(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.
Comment 18 Mike Kaganski 2020-01-13 17:09:36 UTC
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...
Comment 19 Julien Nabet 2020-01-13 17:51:19 UTC
(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.
Comment 20 Mike Kaganski 2020-01-13 22:17:49 UTC
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.