kjambunathan / org-mode-ox-odt

The Authoritative fork of Org mode's ODT exporter
GNU General Public License v3.0
47 stars 9 forks source link

A simple document with a captioned image (produced in LibreOffice by hand) isn't displayed properly when uploaded to Google Docs #136

Open kjambunathan opened 2 years ago

kjambunathan commented 2 years ago

A simple document with a captioned image (produced in LibreOffice by hand) isn't displayed properly when uploaded to Google Docs

This problem exists even when uploading such documents produced with LibreOffice by hand. The Google Docs interface shows just the caption, and seems to strip the image altogether.

Version: 7.2.2.2 / LibreOffice Community
Build ID: 20(Build:2)
CPU threads: 4; OS: Linux 5.14; UI render: default; VCL: x11
Locale: en-IN (en_IN.UTF-8); UI: en-US
Debian package version: 1:7.2.2-1
Calc: threaded

I vaguely remember this feature working in the past with Google Docs. Truth be said, I don't use Google Docs frequently or heavily. May be this has been an issue all along ....

Document produced by hand with LibreOffice (i.e., this document is NOT produced by ODT exporter)

A Simple Captioned Image.odt

How it looks like in LibreOffice Editor

Screenshot from 2021-11-24 14-45-26

How it looks like when opened in Google Documents Editor

Screenshot from 2021-11-24 14-37-10

How the document looks like when downloaded from Google Docs

A Simple Captioned Image As Converted By Google Doc.odt

How it looks like in Emacs

Screenshot from 2021-11-24 14-39-45


Looks like Google, very recently made some enhancements surrounding images and captions.

Here is related links for later reference ...

How to Add Captions to Images in Google Docs

kjambunathan commented 2 years ago

How to Add Captions to Images in Google Docs

Using the procedure listed in this articles this is what I get

This is how it looks like in Google Docs

Screenshot from 2021-11-24 15-02-31

This is how the downloaded document looks

A Simple Captioned Image as produced by Google Docs.odt

The XML tells me that it is actually a draw object -- What else do you expect when doing Insert -> Drawing? -- that contains two grouped shapes.

kjambunathan commented 2 years ago

This is not a bug in the ODT exporter ... but when I badly wanted to share a ODT exported document with many captioned images to one of my friends, it backfired. It sucks to spend many hours debugging this issue, only to conclude that it is an error on Google Docs side.

I wonder why Google Docs is not preserving the fidelity of a very simple LibreOffice-produced document (in the standard way).

kjambunathan commented 2 years ago

Google Docs also doesn't seem to honour the image sequence numbers ...

kjambunathan commented 2 years ago

Filed a bug against LibreOffice bug 145987 – Writer typesets identically defined automatic and custom graphic-styles differently

File uploaded in above LibreOffice bug is

grouped.odt

Screenshot

Screenshot from 2021-12-01 19-01-12

Snippet used to create the file above.

#+ATTR_ODT: :style "OrgTitle"
LibreOffice typesets /identically defined/ automatic and custom
~grahic~-styles differently

#+odt_extra_styles: <style:style style:name="OrgShape"
#+odt_extra_styles:              style:family="graphic">
#+odt_extra_styles:   <style:graphic-properties draw:auto-grow-height="true"
#+odt_extra_styles:                             draw:textarea-horizontal-align="justify"
#+odt_extra_styles:                             draw:textarea-vertical-align="middle"
#+odt_extra_styles:                             draw:wrap-influence-on-position="once-concurrent"
#+odt_extra_styles:                             fo:min-height="0cm"
#+odt_extra_styles:                             fo:min-width="0cm"
#+odt_extra_styles:                             fo:padding-bottom="0.125cm"
#+odt_extra_styles:                             fo:padding-left="0.25cm"
#+odt_extra_styles:                             fo:padding-right="0.25cm"
#+odt_extra_styles:                             fo:padding-top="0.125cm"
#+odt_extra_styles:                             fo:wrap-option="wrap"
#+odt_extra_styles:                             style:flow-with-text="false"
#+odt_extra_styles:                             style:horizontal-pos="center"
#+odt_extra_styles:                             style:horizontal-rel="paragraph"
#+odt_extra_styles:                             style:number-wrapped-paragraphs="no-limit"
#+odt_extra_styles:                             style:run-through="foreground"
#+odt_extra_styles:                             style:vertical-pos="top"
#+odt_extra_styles:                             style:vertical-rel="paragraph"
#+odt_extra_styles:                             style:wrap="none" />
#+odt_extra_styles:   <style:paragraph-properties style:writing-mode="lr-tb" />
#+odt_extra_styles: </style:style>

#+odt_automatic_styles: <style:style style:name="OrgShape1"
#+odt_automatic_styles:              style:family="graphic">
#+odt_automatic_styles:   <style:graphic-properties draw:auto-grow-height="true"
#+odt_automatic_styles:                             draw:textarea-horizontal-align="justify"
#+odt_automatic_styles:                             draw:textarea-vertical-align="middle"
#+odt_automatic_styles:                             draw:wrap-influence-on-position="once-concurrent"
#+odt_automatic_styles:                             fo:min-height="0cm"
#+odt_automatic_styles:                             fo:min-width="0cm"
#+odt_automatic_styles:                             fo:padding-bottom="0.125cm"
#+odt_automatic_styles:                             fo:padding-left="0.25cm"
#+odt_automatic_styles:                             fo:padding-right="0.25cm"
#+odt_automatic_styles:                             fo:padding-top="0.125cm"
#+odt_automatic_styles:                             fo:wrap-option="wrap"
#+odt_automatic_styles:                             style:flow-with-text="false"
#+odt_automatic_styles:                             style:horizontal-pos="center"
#+odt_automatic_styles:                             style:horizontal-rel="paragraph"
#+odt_automatic_styles:                             style:number-wrapped-paragraphs="no-limit"
#+odt_automatic_styles:                             style:run-through="foreground"
#+odt_automatic_styles:                             style:vertical-pos="top"
#+odt_automatic_styles:                             style:vertical-rel="paragraph"
#+odt_automatic_styles:                             style:wrap="none" />
#+odt_automatic_styles:   <style:paragraph-properties style:writing-mode="lr-tb" />
#+odt_automatic_styles: </style:style>

Please ~unzip~ this file, and examine ~styles.xml~ and ~content.xml~
therein.

- ~OrgShape~ :: A custom style defined in ~styles.xml~
- ~OrgShape1~ :: An automatic style defined in ~content.xml~

Note that both the ~OrgShape~ and ~OrgShape1~ have /*the exact same specification*/.

The shape below uses the custom style ~OrgShape~

#+ATTR_ODT: :anchor "paragraph" :style "OrgShape" :width 3
#+begin_customshape
Laborum officia ullamco labore esse cupidatat non tempor irure magna
sint adipiscing ex qui ad ut.  Adipiscing id labore cillum sunt anim
dolor ad aliqua adipiscing sit esse tempor reprehenderit minim
pariatur.
#+end_customshape

The shape below uses the automatic style ~OrgShape1~

#+ATTR_ODT: :anchor "paragraph" :style "OrgShape1" :width 3
#+begin_customshape
Laborum officia ullamco labore esse cupidatat non tempor irure magna
sint adipiscing ex qui ad ut.  Adipiscing id labore cillum sunt anim
dolor ad aliqua adipiscing sit esse tempor reprehenderit minim
pariatur.
#+end_customshape

*Problems Obverved*

1. The ~style:wrap="none"~ is /*not*/ honored in the first shape.
2. The first shape is /*not*/ centered vertically and horizontally
   within it's parent paragraph, while the second shape is centered
   within it's parent paragraph.
2. The text within the first shape in /*not*/ padded, but that within
   the second shape is padded.

*Expected Behaviour*

The first shape should be typeset /*exactly same*/ as the second
shape. i.e., *Why does LibreOffice typeset styles that are /defined identically/ 
but /defined in different places/ very /differently/?  I expect a
/consistent/ behaviour!*

*Desired Behaviour*

When I save the file, LibreOffice removes the
~style:horizontal-pos="center"~, ~style:horizontal-rel="paragraph"~,
~style:vertical-pos="top"~ and ~style:vertical-rel="paragraph"~ and
replaces it with absolute positions ~svg:x="xxcm"~ and ~svg:y="yycm"~.
I would prefer that it retains and honors the parapraph-relative
positions.

*Context*

This bug is identified while trying to produce a ~Google
Documents~-compatible ODT file using LibreOffice.  See
[[https://github.com/kjambunathan/org-mode-ox-odt/issues/136][A simple
document with a captioned image (produced in LibreOffice by hand)
isn't displayed properly when uploaded to Google Docs]] for a detailed
report.

*LibreOffice Used*

#+begin_example
$ uname -a
Linux debian 5.14.0-4-amd64 #1 SMP Debian 5.14.16-1 (2021-11-03) x86_64 GNU/Linux
#+end_example

#+begin_example
$ dpkg -l | grep writer
ii  libreoffice-writer 1:7.2.2-1 amd64 office productivity suite -- word processor
#+end_example

#+begin_example
Version: 7.2.2.2 / LibreOffice Community
Build ID: 20(Build:2)
CPU threads: 4; OS: Linux 5.14; UI render: default; VCL: x11
Locale: en-IN (en_IN.UTF-8); UI: en-US
Debian package version: 1:7.2.2-1
Calc: threaded
#+end_example
kjambunathan commented 2 years ago

Here is a simple snippet "closer" to what I am shooting for ....

#+odt_automatic_styles: <style:style style:name="OrgShape"
#+odt_automatic_styles:              style:family="graphic">
#+odt_automatic_styles:   <style:graphic-properties draw:auto-grow-height="true"
#+odt_automatic_styles:                             draw:textarea-horizontal-align="justify"
#+odt_automatic_styles:                             draw:textarea-vertical-align="middle"
#+odt_automatic_styles:                             draw:wrap-influence-on-position="once-concurrent"
#+odt_automatic_styles:                             fo:min-height="0cm"
#+odt_automatic_styles:                             fo:min-width="0cm"
#+odt_automatic_styles:                             fo:padding-bottom="0.125cm"
#+odt_automatic_styles:                             fo:padding-left="0.25cm"
#+odt_automatic_styles:                             fo:padding-right="0.25cm"
#+odt_automatic_styles:                             fo:padding-top="0.125cm"
#+odt_automatic_styles:                             fo:wrap-option="wrap"
#+odt_automatic_styles:                             style:flow-with-text="false"
#+odt_automatic_styles:                             style:horizontal-pos="center"
#+odt_automatic_styles:                             style:horizontal-rel="paragraph"
#+odt_automatic_styles:                             style:number-wrapped-paragraphs="no-limit"
#+odt_automatic_styles:                             style:run-through="foreground"
#+odt_automatic_styles:                             style:vertical-pos="top"
#+odt_automatic_styles:                             style:vertical-rel="paragraph"
#+odt_automatic_styles:                             style:wrap="none" />
#+odt_automatic_styles:   <style:paragraph-properties style:writing-mode="lr-tb" />
#+odt_automatic_styles: </style:style>

[[./org-mode-unicorn.png]]

#+ATTR_ODT: :anchor "paragraph" :style "OrgShape" :width 5
#+begin_customshape
  Aliqua esse aute non lorem ullamco sint consequat in incididunt
  qui excepteur reprehenderit
#+end_customshape
QiangF commented 2 years ago

The odt document may be fragile on its own. I find the exported document is displayed incorrectly sometimes, but if I resave the exported document using libreoffice (save as in file menu), the problem is gone. Can the resave or tidying process be automated?

https://forum.openoffice.org/en/forum/viewtopic.php?f=7&t=106686&p=518882#p518882

kjambunathan commented 2 years ago

The odt document may be fragile on its own. I find the exported document is displayed incorrectly sometimes, but if I resave the exported document using libreoffice (save as in file menu), the problem is gone.

UpdateAll not only updates the indices, it also saves the document.

So, the response to your suggestion is to add UpdateAll to org-odt-transform-processes.

QiangF commented 2 years ago

I already have UpdateAll, and it doesn't solve the gap problem, the resaved file is considerably smaller.

kjambunathan commented 2 years ago

https://forum.openoffice.org/en/forum/viewtopic.php?f=7&t=106686&p=518882#p518882

I already have UpdateAll, and it doesn't solve the gap problem, the resaved file is considerably smaller.

So, you are reporting a new problem.

Could you please

  1. open a new issue
  2. share the org snippet
  3. share the odt file
  4. if possible, share a screenshot

I will take a look at it.

kjambunathan commented 2 years ago

https://forum.openoffice.org/en/forum/viewtopic.php?f=7&t=106686&p=518882#p518882 2.odt

(Let us move the discussion in to a new github issue)

Notes for myself ...

The document has three pages and you have a mix of 2-column sections / table.

You are saying "unnecessary" gap. Could you please use gimp or some other software to mark on the screenshot where the problem lies. It is easier to understand screenshot (than the XML code). Also a single image is worth thousand words.