Bug 83662 - Unnamed Writer images, inserted with a script, not visible in Navigator
Summary: Unnamed Writer images, inserted with a script, not visible in Navigator
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium normal
Assignee: Not Assigned
: 127573 (view as bug list)
Depends on:
Blocks: Navigator
  Show dependency treegraph
Reported: 2014-09-09 11:17 UTC by Matthew Francis
Modified: 2022-01-20 03:34 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

Sample document (29.77 KB, application/vnd.oasis.opendocument.text)
2014-09-09 11:18 UTC, Matthew Francis

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Francis 2014-09-09 11:17:36 UTC
Observed on OSX 10.9.4 / LO and 4.4 master

It is possible to create an ODT which contains an image that does not display under "Images" within Navigator. An example is attached which contains two images, only one of which can be seen in Navigator.

(Note: Due to bug 83493, this document may load very slowly due to the presence of externally linked images)

Within the content.xml of the document, the problem appears to relate to the fact that the first <draw:frame> doesn't have a "draw:name" attribute:

            <text:p text:style-name="Standard">
                <draw:frame text:anchor-type="as-char" svg:y="0cm" draw:z-index="0" draw:style-name="gr1" draw:text-style-name="P4" svg:width="3.372cm" svg:height="1.371cm">
                    <draw:image xlink:href="http://ask.libreoffice.org/m/tdf/media/images/tdf-logo.png?v=7" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad">
            <text:p text:style-name="P3">
                <draw:frame draw:style-name="fr1" draw:name="Image1" text:anchor-type="as-char" svg:width="7.853cm" svg:height="3.193cm" draw:z-index="1">
                    <draw:image xlink:href="http://ask.libreoffice.org/m/tdf/media/images/tdf-logo.png?v=7" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/>

The problematic image was inserted using a Python script, and it seems likely there's no way of creating such a document using the Writer interface alone.

Possibly the solution is to always generate a name on insertion / file load if it is missing?
Comment 1 Matthew Francis 2014-09-09 11:18:19 UTC
Created attachment 105972 [details]
Sample document
Comment 2 Yousuf Philips (jay) (retired) 2014-09-09 22:00:56 UTC
Hi Matthew,

Here are the files that i mentioned that had image problems in navigator.

attachment 96366 [details] - images having no labels
attachment 105410 [details] [GB_2013.docx] - images not being listed
Comment 3 retired 2014-09-10 05:15:38 UTC

Navigator shows only one image (the 2nd) instead of two.
-> NEW
Comment 4 Matthew Francis 2014-09-10 12:49:41 UTC
The two .docx mentioned above have a problem in the same category; when an image isn't named within the OOXML of the .docx, the image isn't shown correctly in Navigator.

In the case of import from .docx, it seems that the symptom is slightly different for some images - the image shows as a blank entry in Navigator rather than being missing altogether. Clicking on such broken entries does not select the correct image in the document, but always and only the last such image. In addition, (some?) unnamed images of this sort appear to be automatically assigned a name when saved as ODT (they become images "1", "2", "3", ...), which doesn't happen with the originally attached document.

So, currently:
- Unnamed images can be inserted by macro
- Unnamed images can pass through import filters (which?) without being named
- Some but not all unnamed images get named when they are saved
- Navigator shows some unnamed images as non-functional blank entries, and others not at all

In terms of solutions;

Option 1: Fully allow unnamed images
- Word appears able to have unnamed images in a .docx, so it might be considered reasonable to allow saving them back the same way.
- In this case, Navigator should be made to show all such images in a form that allows them to be interacted with properly.
- At present, you can't create an unnamed image in Writer - deleting the name causes a new one to be inserted automatically when the properties dialog is closed. If they are to be allowed, then this should probably be made possible (the images would have to be given some other placeholder under Navigator).

Option 2: Fully forbid unnamed images
- Macro interactions and all import filters would have to be audited to ensure that all images that are inserted/loaded are named and properly visible in Navigator from birth.
Comment 5 QA Administrators 2017-01-03 19:40:00 UTC Comment hidden (obsolete, spam)
Comment 6 QA Administrators 2019-12-03 14:20:36 UTC Comment hidden (obsolete)
Comment 7 Cor Nouws 2019-12-05 20:05:43 UTC
issue still present in Version:
Build ID: a81489978cb96d819044be054f7ceabc4f8eccb2
CPU threads: 8; OS: Linux 5.3; UI render: default; VCL: gtk3; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-11-24_02:51:20
Locale: nl-NL (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 8 Heiko Tietze 2020-01-20 14:26:56 UTC
*** Bug 127573 has been marked as a duplicate of this bug. ***
Comment 9 QA Administrators 2022-01-20 03:34:36 UTC
Dear Matthew Francis,

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 https://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://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team