Form feed characters break odt export

Form feed characters break odt export

[Joseph Turner via General discussions about Org-mode.]

Tested on
GNU Emacs 29.4 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.41, cairo version 1.18.0)
Org mode version 9.7.6 (9.7.6-7a4527 @ /home/joseph/.emacs.d/elpa/org-9.7.6/)

I can export the following Org content to a .odt file, but the exported
file cannot be opened ("Read Error. Format error discovered in the file
in sub-document content.xml at 368,2(row,col).")

--8<---------------cut here---------------start------------->8---
#+TITLE: Foo
* Bar
Baz
\f
--8<---------------cut here---------------end--------------->8---

First reported by bohonghuang:
https://github.com/bohonghuang/org-srs/pull/10#issuecomment-2557417871

Thanks!

Joseph

Re: Form feed characters break odt export

[Max Nikulin]

On 21/12/2024 08:48, Joseph Turner wrote:
> 
> I can export the following Org content to a .odt file, but the exported
> file cannot be opened ("Read Error. Format error discovered in the file
> in sub-document content.xml at 368,2(row,col).")
[...]
> First reported by bohonghuang:
> https://github.com/bohonghuang/org-srs/pull/10#issuecomment-2557417871

In this specific context a workaround should be

#+begin_comment
^L
#+end_comment

Or a commented out empty local variables block above.

I have wrote already that I do not like non-printable characters in Org 
files.

I admit that special characters either should cause `org-lint' warnings 
or should be filtered out by exporters.

Specifically to ^L, there was a request to treat it as a page break by 
all exporters (I would prefer some entity or macro instead to not 
deviate from plain text markup).

Marvin Gülker. Feature request: export form feed as page break. Sat, 21 
Oct 2023 09:42:33 +0200.
<https://list.orgmode.org/87zg0ce6yi.fsf@guelker.eu>

I have not had a close look at another proposed feature, but I suspect 
that it might make filtering special characters more tricky. (I would be 
happy to hear that I am wrong.)

Nathaniel Nicandro. [PATCH] ANSI color on example blocks and fixed width 
elements. Wed, 05 Apr 2023 07:03:43 -0500.
<https://list.orgmode.org/874jpuijpc.fsf@gmail.com>

Re: Form feed characters break odt export

[Joseph Turner]

Max Nikulin <manikulin@gmail.com> writes:

> On 21/12/2024 08:48, Joseph Turner wrote:
>> I can export the following Org content to a .odt file, but the
>> exported
>> file cannot be opened ("Read Error. Format error discovered in the file
>> in sub-document content.xml at 368,2(row,col).")
> [...]
>> First reported by bohonghuang:
>> https://github.com/bohonghuang/org-srs/pull/10#issuecomment-2557417871
>
> In this specific context a workaround should be
>
> #+begin_comment
> ^L
> #+end_comment

Thank you!  Or even simpler:

# ^L

> Or a commented out empty local variables block above.
>
> I have wrote already that I do not like non-printable characters in
> Org files.

I agree that they make Org files less portable outside Emacs, and they
complicate org-export.

> I admit that special characters either should cause `org-lint'
> warnings or should be filtered out by exporters.
>
> Specifically to ^L, there was a request to treat it as a page break by
> all exporters (I would prefer some entity or macro instead to not
> deviate from plain text markup).
>
> Marvin Gülker. Feature request: export form feed as page break. Sat,
> 21 Oct 2023 09:42:33 +0200.
> <https://list.orgmode.org/87zg0ce6yi.fsf@guelker.eu>
>
> I have not had a close look at another proposed feature, but I suspect
> that it might make filtering special characters more tricky. (I would
> be happy to hear that I am wrong.)

Yes.  Without digging into it, my gut feeling is also that handling one
non-printable character specially would open Pandora's box.

> Nathaniel Nicandro. [PATCH] ANSI color on example blocks and fixed
> width elements. Wed, 05 Apr 2023 07:03:43 -0500.
> <https://list.orgmode.org/874jpuijpc.fsf@gmail.com>

Gratefully,

Joseph

Re: Form feed characters break odt export

[Max Nikulin]

On 21/12/2024 13:52, Joseph Turner wrote:
> Max Nikulin writes:
>>
>> #+begin_comment
>> ^L
>> #+end_comment

> Thank you!  Or even simpler:
> 
> # ^L

It was first I tried, but Emacs-28.2 demands to decide if Local 
Variables should be applied.

You may ask Emacs developers for a *plain text* spell to stop processing 
of local variables (or to take *last* found block).

Notice that commit diff looks confusing.