Open kjambunathan opened 2 years ago
Using the procedure listed in this articles this is what I get
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.
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).
Google Docs also doesn't seem to honour the image sequence numbers ...
Filed a bug against LibreOffice bug 145987 – Writer typesets identically defined automatic and custom graphic-styles differently
File uploaded in above LibreOffice bug is
Screenshot
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
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
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
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
.
I already have UpdateAll, and it doesn't solve the gap problem, the resaved file is considerably smaller.
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
org
snippetodt
fileI will take a look at it.
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.
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.
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
How it looks like when opened in Google Documents Editor
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
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