Bug 149043 - Writer doesn't render an image file which is in the root of zip dir (ODF Validation succeeds/Google Docs works fine)
Summary: Writer doesn't render an image file which is in the root of zip dir (ODF Vali...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.3.3.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Writer-Images
  Show dependency treegraph
 
Reported: 2022-05-12 06:18 UTC by Jambunathan K
Modified: 2023-07-19 20:03 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Writer reports `Read Error` on an image file which exists (in the root of the zip dir) (162.62 KB, image/png)
2022-05-12 06:18 UTC, Jambunathan K
Details
Test ODT file: `Read Error` for an image file at the root of zip dir (28.87 KB, application/vnd.oasis.opendocument.text)
2022-05-12 06:20 UTC, Jambunathan K
Details
Google Docs renders the document just fine (71.39 KB, image/png)
2022-05-12 06:24 UTC, Jambunathan K
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jambunathan K 2022-05-12 06:18:23 UTC
Created attachment 180069 [details]
Writer reports `Read Error` on an image file which exists (in the root of the zip dir)

#+TITLE: Writer doesn't render an image file which is in the root of zip dir

#+CAPTION:  *Why does ~Writer~ give a read error, but Google Docs doesn't?*
[[./org-mode-unicorn.png]]

This image file is at the root of the zip folder, /*instead of in
~Pictures/~*/.

1. ~LibreOffice Writer~ shows me a ~Read Error~

     - How the `zip` file looks like ::

       #+begin_src text
       M    Mode      Size        Date&time         Filename
       - ----------  ------  --------------------  ----------------
         -rw-r--r--      39  12-May-2022 11:25:32  mimetype
         -rw-r--r--  104841  12-May-2022 11:25:32  styles.xml
         -rwxr-xr-x   10527  12-May-2022 11:25:32  0001.png
         -rw-r--r--  207204  12-May-2022 11:25:32  content.xml
         -rw-r--r--     647  12-May-2022 11:25:32  meta.xml
         drwxr-xr-x       0  12-May-2022 11:25:32  META-INF/
         -rw-r--r--     649  12-May-2022 11:25:32  META-INF/manifest.xml
       - ----------  ------  --------------------  ----------------
                     323907                         7 files
       #+end_src

     - How the ~META-INF/manifest.xml~ looks like ::

       #+begin_src nxml
       <?xml version="1.0" encoding="utf-8"?>
       <manifest:manifest manifest:version="1.2"
                          xmlns:manifest="urn:oasis:names:tc:opendocument:xmlns:manifest:1.0">

         <manifest:file-entry manifest:full-path="/"
                              manifest:media-type="application/vnd.oasis.opendocument.text"
                              manifest:version="1.2" />
         <manifest:file-entry manifest:full-path="meta.xml"
                              manifest:media-type="text/xml" />
         <manifest:file-entry manifest:full-path="styles.xml"
                              manifest:media-type="text/xml" />
         <manifest:file-entry manifest:full-path="content.xml"
                              manifest:media-type="text/xml" />
         <manifest:file-entry manifest:full-path="0001.png"
                              manifest:media-type="image/png" />
       </manifest:manifest>
       #+end_src

     - How `content.xml` looks like ::

       #+begin_src nxml
        <text:p text:style-name="OrgFigureBody">
          <draw:frame draw:style-name="OrgToCharImage"
                      svg:height="4.66cm"
                      svg:width="4.29cm"
                      text:anchor-type="char">
            <draw:image xlink:actuate="onLoad"
                        xlink:href="0001.png"
                        xlink:show="embed"
                        xlink:type="simple" />
            </draw:frame>Figure 
            <text:bookmark text:name="org2ea9b5d" />
            <text:sequence text:name="Figure"
                           style:num-format="1"
                           text:formula="ooow:Figure+1"
                           text:ref-name="org2ea9b5d">1</text:sequence>: Why
            does 
            <text:span text:style-name="OrgCode">Writer</text:span>give a read
        error, but Google Docs doesn't?</text:p>
       #+end_src

2. Google Docs renders the document fine.
3. The ODF Validation[fn:1] on the file succeeds

   #+begin_src sh
   java -jar /home/kjambunathan/src/org-mode-ox-odt/testing/examples/odt/odfvalidator-0.10.0-jar-with-dependencies.jar -v imagefileatrootofzipfolder.odt
   #+end_src

[fn:1]

See https://repo1.maven.org/maven2/org/odftoolkit/odfvalidator/0.10.0/
Comment 1 Jambunathan K 2022-05-12 06:20:54 UTC
Created attachment 180070 [details]
Test ODT file: `Read Error` for an image file at the root of zip dir
Comment 2 Jambunathan K 2022-05-12 06:24:39 UTC
Created attachment 180071 [details]
Google Docs renders the document just fine
Comment 3 Jambunathan K 2022-05-12 06:26:50 UTC
(In reply to Jambunathan K from comment #2)
> Created attachment 180071 [details]
> Google Docs renders the document just fine

I uploaded the ODT file to drive and opened it in Google Docs.  It renders just fine.

https://docs.google.com/document/d/1NQk5qpKL7kBgP8MzeQqnplyNk5ags3gyxCYgvdsUk14/edit?usp=sharing
Comment 4 Jambunathan K 2022-05-12 06:27:44 UTC
Version: 7.3.3.2 / LibreOffice Community
Build ID: 30(Build:2)
CPU threads: 4; OS: Linux 5.17; UI render: default; VCL: x11
Locale: en-IN (en_IN); UI: en-US
Debian package version: 1:7.3.3~rc2-1
Calc: threaded

$ dpkg -l | grep writer | grep libreoffice
ii  libreoffice-writer                                 1:7.3.3~rc2-1                      amd64        office productivity suite -- word processor
Comment 5 Regina Henschel 2022-05-12 18:25:33 UTC
I'm not sure, that such structure is valid. Please look at second paragraph in section 3.1 General in https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part2-packages/OpenDocument-v1.3-os-part2-packages.html

The image is a document of its own with own mime-type. So it violets the rule of only one document in the root. The validator might be wrong here.

Another question is, whether LibreOffice should be error-tolerant and open such files nevertheless. I support such request because Word and TextMaker show the image too.