Bug 123983 - Read Error if embedded images are not into the Pictures directory
Summary: Read Error if embedded images are not into the Pictures directory
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.1.0.0.beta1+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.5.0 target:7.4.0.2 target:7....
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Regressions-imageHandling
  Show dependency treegraph
 
Reported: 2019-03-10 18:31 UTC by Laurent Mignon
Modified: 2023-12-22 09:09 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
File generated with images at the root of the archive (Error) (31.13 KB, application/vnd.oasis.opendocument.text)
2019-03-10 18:31 UTC, Laurent Mignon
Details
Same file generated with images into the Pictures sub dirctory (working) (31.20 KB, application/vnd.oasis.opendocument.text)
2019-03-10 18:32 UTC, Laurent Mignon
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Laurent Mignon 2019-03-10 18:31:09 UTC
Created attachment 149864 [details]
File generated with images at the root of the archive (Error)

Prior to libroffice 6.1,  it was possible to generate documents with embedded images stored at the root of the file archive.
When these files are opened with libreoffice 6.1, images are not displayed and a "Read Error" message is displayed into the image place holder. 

If we put the images into the Pictures sub directory, everything works fine.
Comment 1 Laurent Mignon 2019-03-10 18:32:19 UTC
Created attachment 149865 [details]
Same file generated with images into the Pictures sub dirctory (working)
Comment 2 Julien Nabet 2019-03-10 19:38:30 UTC
How did you create the first file?

What astonishes me is it could work before.
Indeed, when inserting images, it seems to me it's always in a subdirectory Pictures.
Comment 3 Julien Nabet 2019-03-10 19:41:07 UTC
Also, files are not ok according to https://odfvalidator.org/
Comment 4 Dieter 2019-03-10 20:14:12 UTC
(In reply to Julien Nabet from comment #2)
> How did you create the first file?

=> NEEDINFO
Comment 5 Laurent Mignon 2019-03-11 08:38:11 UTC
The file has been created by the py3o.template library. https://bitbucket.org/faide/py3o.template/src/default/
Comment 6 Laurent Mignon 2019-03-11 08:38:38 UTC
(In reply to Julien Nabet from comment #3)
> Also, files are not ok according to https://odfvalidator.org/

The file has been created by the py3o.template library. https://bitbucket.org/faide/py3o.template/src/default/
Comment 7 Julien Nabet 2019-03-11 08:43:56 UTC
Thank you for your feedback.

So please contact authors https://bitbucket.org/faide/py3o.template/src/default/ about this bug but since the file hasn't been generated by LO and is not a valid file according to https://odfvalidator.org/, I'll close this.
Comment 8 Laurent Mignon 2019-03-11 08:44:53 UTC
(In reply to Julien Nabet from comment #7)
> Thank you for your feedback.
> 
> So please contact authors
> https://bitbucket.org/faide/py3o.template/src/default/ about this bug but
> since the file hasn't been generated by LO and is not a valid file according
> to https://odfvalidator.org/, I'll close this.

We have the same validation error with both files (The working one ant the failing one) The problem is therefore unrelated.
Comment 9 Julien Nabet 2019-03-11 08:50:14 UTC
Let's put back to UNCONFIRMED.
I never saw pictures generated at root level from a version of LO and thought odf validator would complain but it's not the case.
Anyway I can't help here so uncc myself.
Comment 10 Laurent Mignon 2019-03-11 08:58:12 UTC
(In reply to Julien Nabet from comment #9)
> Let's put back to UNCONFIRMED.
> I never saw pictures generated at root level from a version of LO and
> thought odf validator would complain but it's not the case.
> Anyway I can't help here so uncc myself.

Even if I fix the validation error, the pictures are not properly displayed. could you point me where it's specified that pictures must be in a sub directory?
As I understand, there is no rule saying where to place the pictures. The only rules are.

* The "href" attribute of the "<dram:image/>" tag must be the path to the file into the archive.
* The file must be declared into the file META-INF/manifest.xml

In the working case we have:
----------------------------

content.xml
...
<draw:image xlink:href="Pictures/6dcfbae1284da95d6bcf990e3b9bfd4d7ab9f6d034ba057327a436c19f77277e" ...

META-INF/manifest.xml

....
<manifest:file-entry manifest:full-path="Pictures/6dcfbae1284da95d6bcf990e3b9bfd4d7ab9f6d034ba057327a436c19f77277e" ...

And the image is into the Pictures subdirectory


Into the failing case we have:
------------------------------

content.xml
...
<draw:image xlink:href="Pictures/6dcfbae1284da95d6bcf990e3b9bfd4d7ab9f6d034ba057327a436c19f77277e" ...

META-INF/manifest.xml

....
<manifest:file-entry manifest:full-path="Pictures/6dcfbae1284da95d6bcf990e3b9bfd4d7ab9f6d034ba057327a436c19f77277e" ...

And the image is a the root of the archive.



In both cases the "href" has the right path to the image. Therefore that should work. Do I miss something? If a rule exists saying that the pictures must be into a sub directory, we can close this issue otherwise we must fix it.
Comment 11 Dieter 2019-03-11 09:09:26 UTC
Perhaps a developer can help => Keyword needsDevEval
Comment 12 Oliver Brinzing 2019-03-11 18:36:10 UTC
this seems to have started with the rework of the image handling, e.g.
http://document-foundation-mail-archive.969070.n3.nabble.com/API-CHANGE-dropping-string-properties-which-use-vnd-sun-star-GraphicObject-URL-td4235349.html

i remember, there was an issue some month ago about the same problem:
a file generated via webservice with images in root instead of images folder.
unfortunately i cannot find the issue at the moment ...

IMHO a picture in root (or any other folder) should work if href/path in content.xml/manifest.xml is correct.
Comment 13 Xisco Faulí 2019-04-16 09:54:22 UTC
Regression introduced by:

author	Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>	2018-03-05 20:44:08 +0900
committer	Tomaž Vajngerl <quikee@gmail.com>	2018-03-07 02:38:28 +0100
commit 27008aa028cde8d270e898c5743a9fe5c7701dab (patch)
tree d3c8bbd6c1607122dc8009beeba68f7d0b89d256
parent 5a4d6162f643050faf00ccf08d58feed00dcd781 (diff)
xmloff: convert XMLTextParagraphExport to get rid of "GraphicURL"

Bisected with: bibisect-linux64-6.1

Adding Cc: to Tomaž Vajngerl
Comment 14 Justin L 2022-03-05 15:12:19 UTC
repro 7.4+
Comment 15 Commit Notification 2022-07-21 07:02:24 UTC
Tomaž Vajngerl committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/d449da36086409e3cc440036193c4fc8a10a37a1

tdf#123983 fix loading graphic that is in root folder + test

It will be available in 7.5.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.
Comment 16 Commit Notification 2022-07-26 12:56:35 UTC
Tomaž Vajngerl committed a patch related to this issue.
It has been pushed to "libreoffice-7-4":

https://git.libreoffice.org/core/commit/5cea89cb8c805ded5b571fca295158c462e30303

tdf#123983 fix loading graphic that is in root folder + test

It will be available in 7.4.0.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.
Comment 17 Commit Notification 2022-07-27 14:48:53 UTC
Tomaž Vajngerl committed a patch related to this issue.
It has been pushed to "libreoffice-7-3":

https://git.libreoffice.org/core/commit/2bfad80805c248b47d099c1707ce4f1926867b82

tdf#123983 fix loading graphic that is in root folder + test

It will be available in 7.3.6.

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.
Comment 18 Commit Notification 2023-10-05 07:59:39 UTC
Thorsten Behrens committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/ae533151bcc16de22fb90b42be1cf7432b0fddc3

related tdf#123983: don't open test file read/write from src tree

It will be available in 24.2.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.
Comment 19 Commit Notification 2023-10-10 08:11:43 UTC
Thorsten Behrens committed a patch related to this issue.
It has been pushed to "libreoffice-7-6":

https://git.libreoffice.org/core/commit/d1c50e62d7682df5893d17884c24dceacbbe9c8c

related tdf#123983: don't open test file read/write from src tree

It will be available in 7.6.3.

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.