on the fragility of export to ODT

on the fragility of export to ODT

[Eric S Fraga]

Hello all,

(I hope this is not just noise...)

I use org as my main writing tool, typically for publications that I
submit using LaTeX.  So far, so excellent!

However, I do have to export to ODT (as a means to DOC) and I find the
export to be very fragile.  I keep running into some strange error in
long documents (which make it difficult to track down the source).  The
typical output to *Messages* is:

,----
| Deleting lines with ignore heading tag
| Local Ispell dictionary set to british
| org-babel-exp process latex at line 185...
| executing Latex code block...
| Code block evaluation complete.
| org-babel-exp process latex at line 244...
| executing Latex code block (radarchart)...
| result silenced
| org-babel-exp process latex at line 245...
| executing Latex code block...
| Processing LaTeX file /tmp/babel-7173ozh/latex-7173lhW.tex...
| PDF file produced.
| Code block evaluation complete.
| org-babel-exp process latex at line 460...
|  [...]
| org-babel-exp process bibtex at line 1151...
| org-babel-exp process emacs-lisp at line 1201...
| LaTeX to MathML converter not available.
| Formatting LaTeX using verbatim
| OpenDocument export failed: FIXME: Resolve (paragraph (:begin 54129 :end 54321
`----

At this point, I get very long data structures dumped to
*Messages*...  difficult to figure out what is wrong.  It's often my
mistake but tracking it down is difficult.

However, more importantly, the failure is complete and nothing is
exported which does not help me at all.  It would be great if offending
paragraphs (elements, objects, whatever) would be skipped over and the
rest of the document generated.  Is this possible?

Thanks,
eric

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-840-g451c7b

Re: on the fragility of export to ODT

[Nicolas Goaziou]

Hello,

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> At this point, I get very long data structures dumped to
> *Messages*...  difficult to figure out what is wrong.  It's often my
> mistake but tracking it down is difficult.

You're using an internal link to target a paragraph (possibly a image or
some such). This is apparently not supported yet by ox-odt (see
`org-odt-link--infer-description').

Could you try to find out the culprit and explain what you expected so
I can fix it?

> However, more importantly, the failure is complete and nothing is
> exported which does not help me at all.  It would be great if offending
> paragraphs (elements, objects, whatever) would be skipped over and the
> rest of the document generated.  Is this possible?

At the moment, I think it is better to fix the errors than to ignore
them. There are quite a few "FIXME" in ox-odt.


Regards,

-- 
Nicolas Goaziou

Re: on the fragility of export to ODT

[Eric S Fraga]

On Monday, 16 Feb 2015 at 21:20, Nicolas Goaziou wrote:
> Hello,
>
> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>
>> At this point, I get very long data structures dumped to
>> *Messages*...  difficult to figure out what is wrong.  It's often my
>> mistake but tracking it down is difficult.
>
> You're using an internal link to target a paragraph (possibly a image or
> some such). This is apparently not supported yet by ox-odt (see
> `org-odt-link--infer-description').
>
> Could you try to find out the culprit and explain what you expected so
> I can fix it?

Hi Nicolas,

I have many internal references; in this document, all are to named
tables and figures.

I have tried but haven't managed to track down which one is causing
problems in this case.

I have tried extracting various bits into smaller org files but then the
problems disappear... :(

Part of the problem, I think (but please correct me if I'm wrong), is
that the positions indicated in the error messages are in the buffer
being exported after a certain amount of processing (including, I would
imagine, babel) and so it's difficult to find the actual location of the
problem.

If this is indeed the case, is there any way to retain the buffer that
is being processed at the point the error occurs?

>> However, more importantly, the failure is complete and nothing is
>> exported which does not help me at all.  It would be great if offending
>> paragraphs (elements, objects, whatever) would be skipped over and the
>> rest of the document generated.  Is this possible?
>
> At the moment, I think it is better to fix the errors than to ignore
> them. There are quite a few "FIXME" in ox-odt.

Okay, that's fine.

In any case, I'm in no panic as I have simply sent the PDF to my
co-author and that's good enough for now.  Eventually, I may need to get
the DOC version but I can keep my fingers crossed and hope it doesn't
come to that...

thanks,
eric

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 24.4.1, Org release_8.3beta-820-gd92ef9

Re: on the fragility of export to ODT

[Nicolas Goaziou]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> I have many internal references; in this document, all are to named
> tables and figures.

The error comes from a figure, not a table, if that helps.

> I have tried but haven't managed to track down which one is causing
> problems in this case.
>
> I have tried extracting various bits into smaller org files but then the
> problems disappear... :(
>
> Part of the problem, I think (but please correct me if I'm wrong), is
> that the positions indicated in the error messages are in the buffer
> being exported after a certain amount of processing (including, I would
> imagine, babel) and so it's difficult to find the actual location of the
> problem.
>
> If this is indeed the case, is there any way to retain the buffer that
> is being processed at the point the error occurs?

You're right, buffer positions mean nothing here.

However, there's a simpler solution. In- "ox-odt.el", function
`org-odt-link--infer-description', line 2655 (but it depends on Org
version), there is

  (t (error "FIXME: Resolve %s" destination))

Replace it with

  (t (error "FIXME: Resolve %s" (org-element-interpret-data destination))))

reload Org then trigger the error. The backtrace should be more interesting.


Regards,

Re: on the fragility of export to ODT

[Eric S Fraga]

On Tuesday, 17 Feb 2015 at 22:04, Nicolas Goaziou wrote:

[...]

> However, there's a simpler solution. In- "ox-odt.el", function
> `org-odt-link--infer-description', line 2655 (but it depends on Org
> version), there is
>
>   (t (error "FIXME: Resolve %s" destination))
>
> Replace it with
>
>   (t (error "FIXME: Resolve %s" (org-element-interpret-data destination))))
>
> reload Org then trigger the error. The backtrace should be more interesting.

Hi Nicolas,

thanks for taking the time to try to help me out on this.

Your suggested change does indeed yield more interesting and, I guess,
potentially more helpful information.  The output is:

,----
| OpenDocument export failed: FIXME: Resolve #("#+NAME: fig:radar-chart-urea
| #+CAPTION: Radar chart for the urea process which does not require a catalyst.
| #+RESULTS[10c1bfffde9a020d138a430992eb2f43c29c9257]: 
| [[file:radar-chart-urea.pdf]]
| 
| " 40 107 (:parent (#("Radar chart for the urea process which does not require a catalyst." 0 67 (:parent #2)))))
`----

but it unfortunately doesn't tell me how to fix the problem.

A paragraph back, I have a link [[fig:radar-chart-urea]] and this
information in *Messages* is the full content of where the link target
is defined. If I remove the link, the export fails with a similar error
to above but now due to the next link.  Obviously, removing all the
links (or any, for that matter) is not a viable solution...

Any advice?

Thanks again,
eric
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-843-ga5f1a3.dirty

Re: on the fragility of export to ODT

[Nicolas Goaziou]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> Your suggested change does indeed yield more interesting and, I guess,
> potentially more helpful information.  The output is:
>
> ,----
> | OpenDocument export failed: FIXME: Resolve #("#+NAME: fig:radar-chart-urea
> | #+CAPTION: Radar chart for the urea process which does not require a catalyst.
> | #+RESULTS[10c1bfffde9a020d138a430992eb2f43c29c9257]: 
> | [[file:radar-chart-urea.pdf]]
> | 
> | " 40 107 (:parent (#("Radar chart for the urea process which does not require a catalyst." 0 67 (:parent #2)))))
> `----
>
> but it unfortunately doesn't tell me how to fix the problem.

Apparently `org-odt-inline-image-rules' dismisses pdf files as images.
What happens if you add PDF extension to the list?


Regards,

Re: on the fragility of export to ODT

[Eric S Fraga]

On Wednesday, 18 Feb 2015 at 14:55, Nicolas Goaziou wrote:

[...]

> Apparently `org-odt-inline-image-rules' dismisses pdf files as images.
> What happens if you add PDF extension to the list?

Ah ha!

Adding pdf to the list of extensions (using customize, not editing the
code at this point) enables the exporter to run to completion.  This is
a great step forward as I can now get a document that I can do something
with.

The exporter seems to be collecting the images: they end up in the
actual ODT file.  However, viewing the file in libreoffice shows
placeholders where the images should be but with a "Read-Error"
message.  The captions are there but the images are empty.  I guess that
libreoffice cannot handle PDF images, which probably shouldn't surprise
me...

Now that I know what the problem is, I can see a way forward: all of my
images are created within the org document using babel and I can have an
alternate target of PNG for odt export.

I would imagine that the easiest change in org would be to simply have
an error message telling the user that PDF files cannot be used as
images?

Alternatively, would it be possible to invoke imagemagick to convert PDF
images to PNG as we do with LaTeX snippets?

Thanks for all your help on this,
eric
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-843-ga5f1a3.dirty