Chat notes for ODF Teleconference March 13, 2017

[Patrick Durusau <patrick@durusau.net>]

Greetings!

Our adventures today on the whitespace handling rules for text-input fields!

anonymous morphed into Jos van den Oever
anonymous morphed into Thorsten
Thorsten: hi there
Jos van den Oever: good afternoon
Svante Schubert: Hejda!
Patrick: Svante, joining the call?
Svante Schubert: I still hear the music.. I redial in
Patrick: Yes, we have quorum -
Patrick: Word recognizes <text:s> and <text:tab> and <text:line-break>
manually into an input field, even though invalid under the current schema.
Svante Schubert: Tested and experienced the above behavior with Word
2016 as well.
Svante Schubert: Although not allowed by ODF schema, the whitespace ODF
elements are handled correctly by Word 2016
Svante Schubert: Regina tested it with Word 2010
Svante Schubert: ^^there would be no problem - actions to do - for
Microsoft if we would add the whitespace elements to the schema
Patrick: But if exported, the elements are not preserved by MS Word.
Patrick: spaces still exist but only as spaces, tab is completely gone,
line break is there
Patrick: line break element is gone along with the line break
Svante Schubert: ^^export done with MS Office 2016
Svante Schubert: It was added to the ODF import filter, but not to the
ODF export filter
Andreas J Guelzow: Hi,
Patrick: preserved for docx on saving
Svante Schubert: Regina states it makes sense to have the whitespace
tags for interoperability with docx
Svante Schubert: Shall we support line breaks, tabs and multiple spaces
in fields and if, shall this feature be compatible with DOCX?
Svante Schubert: let me fix my question^^
Svante Schubert: How can we support line breaks, tabs and multiple
spaces in fields and if, shall this feature be compatible with DOCX?
Svante Schubert: How can we support line breaks, tabs and multiple
spaces in fields and how shall this feature be compatible with DOCX?
Svante Schubert: LibreOffice is able to handle ASCII whitespaces to save
and load them via a roundtrip.
Svante Schubert: To me it seems the only reason for whitespace handling
is the prevention of additional whitespaces added by pretty-printing
when using a text edit
Svante Schubert: It seems the input field editing in a text editor is
quite an edge case.
Michael Stahl: phone trouble, dropped out of the call
Svante Schubert: The only problem I can see, if we leave ASCII
whitespaces in the fields oppose to the whitespace TAGS, is that
additional whitespace is being inserted into the document (corrupted),
when pretty-printing is being used
Svante Schubert: We have to balance this with the additional
implementation efforts of the ODF applications
Patrick: https://issues.oasis-open.org/browse/OFFICE-2102
Svante Schubert: On the contrary, using whitepace tags for ODF 1.3 will
allow indent with additional implementation efforts, but no side effects
as far I can see
Patrick: The element <text:text-input> has "character data content",
same as other fields. But the term "character data" is not specified.
(At least I do not find it.)

A specification is needed, to say which characters are valid as
"character data", especially whether control characters are allowed in
"character data", and how invalid characters have to be treated in
"character data". Therefore I support, that this issue should be handled
for ODF1.3.

I do not think, that new child elements are needed. Authors/applications
can use the unicode 2028  LINE SEPARATOR and 2029  PARAGRAPH SEPARATOR,
which are not control characters, to indicate, that the text should be
displayed with line break or paragraph break. For more complex content
authors can use a <form:textarea> element.
Patrick: Regina's comment.
Svante Schubert: Yes, we have to fix the specification in any way, but
only in one way we have to fix the schema and LibreOffice ;)
Svante Schubert: Because text-input is a child of text:p/text:h, which
by specification should use whitespace handling using the TAGS, which
are forbidden by schema
Svante Schubert: as children in text-input
Patrick: Regina: need a way to express tab in input field - easiest way
for Libre Office - no whitespace collapsing in input field
Svante Schubert: So if Michael is agreeing to implemnt whitespace tags
for LibreOffice I would vote for them, otherwise I will not vote for any
solution :)
Patrick: Michael: do you have any strong objection to removing input
fields from white space collapsing rules?
Svante Schubert: As I sait it is only an edge case. XML editing & pretty
printing with XML containing fields might add additional space content
Svante Schubert: if we do not use whitespace tags within fields
Andreas J Guelzow: How will white space before an input filed and white
space after an input field be collapsed. Are they adjacent if the input
field is empty?
Svante Schubert: before and after the field the usual whitespace
handling for text:p/h is taken place
Svante Schubert: Andreas: Things get more complicated, if not all
content of the text:p/h is being handled consistently
Svante Schubert: The algorithm of 6.1.2 would be changed:
http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#White-space_Characters
Svante Schubert: 2) is stating:
Svante Schubert: "The character data of the paragraph element and of all
descendant elements for which the OpenDocument schema permits the
inclusion of character data for the element itself and all its ancestor
elements up to the paragraph element, is concatenated in document order. "
Svante Schubert: I agree with Andreas, we should make it consistent
Svante Schubert: In this rule we talk about descendant while earlier we
talked only of children of text:p/h
Svante Schubert: Andreas: Handles intput-field text, like normal text
that would come from a paragraph
Patrick: in their descendant elements, if the OpenDocument schema
permits the inclusion of
character data for the element itself and all its ancestor elements up
to the paragraph
element.

*********

I hope everyone is at the start of a great week!

Patrick



-- 
Patrick Durusau
patrick@durusau.net
Technical Advisory Board, OASIS (TAB)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau

Attachment: signature.asc
Description: OpenPGP digital signature