[ODFPlugtest] writing implementation specific defaults

[Darabos Dániel]

Hi!

I am not qualified to be taken seriously, but I agree with Wouter. I
deal with users a lot, and it is obvious what they expect. They expect
the document to appear the same in all applications. If our intention
is to make products that enable users then this is what we should
strive for.

I agree that every formatting should be specified and not left up to
the application to decide. These are editable documents and the
applications are capable of editing them, so if the user receives an
ODF document that is laid out for A4 but wants to print it on Letter,
they can use their application to change the page size. Similarly
visually impaired users can transform the document to have larger font
sizes or to be read with a screen reader. Mobile users can transform
the document too. But these cases do not forbid the document having an
intended rendering, they just intentionally render differently. These
special cases are handled with special software, that will fully well
know how to perform the changes. When designing the format they should
not be given much attention other than ensuring that these special
cases are not made unnecessarily difficult to cope with.

The case is very similar to the history of HTML+CSS in my opinion.
Originally no defaults were defined. Some browsers might have wanted
to render H1 at 24pt and others at 32pt. No defaults were defined and
authors often did not explicitly express the formatting in the
stylesheets when it matched the defaults of their browser. How did it
turn out in the long run? Much browser incompatibility ensued and in
time many formatting properties became de facto standards across
browsers (e.g. I am pretty sure the default font is not bold in any
browser, but the contents of a <b> element are), the others the
authors learned to make explicit in CSS. And the result is that today
web pages usually render consistently across browsers. Unless authors
disregard some recommendations, accessibility is not hurt, and mobile
devices can either transform the web pages in their software, or have
grown capable enough to display the exact intended rendering.

I think this pretty nice state of affairs could be reached with ODF
without the long and painful evolution that the HTML spec and the
browsers went through if we take their lessons! And that is I think
that leaving formatting decisions up to the application turned out to
be a bad idea.

One more thing on defaults: When choosing a "sensible default" it is
perfectly good to choose the first thing that comes to mind. Make the
default page size A4. Then the application vendors will be completely
aware that if they save a document with a Letter page size they have
to make this explicit. Otherwise it seems that they will assume that
if their default page size matches the page size of the document they
do not have to make the page size explicit. Also what problems would a
default font size of 12 cause? There is none that I see, yet it would
make it clear how the absence of this information is to be handled and
when the authoring software has to make the font size explicit, so it
seems beneficial to me. There is no wrong default.

As for exactly matching renderings I see two issues besides the
question of defaults:

First I wish fonts could be embedded in the documents! I know there is
some work in this direction (which I did not closely follow, sorry),
and I assume it would give rise to severe copyright issues (it is
obvious to me that I would not be allowed to distribute the document
if I embedded fonts that do not have such a permissive license, but
most users would give no thought to the copyright status of the font
at all). A solution here would be breakthrough in interoperability!

And the last point: I understand that applications may use different
text layout engines, and even with perfectly matching defaults and
fonts they could give significantly differently laid out documents.
Some of you seem to accept this as a fact of life, but I am sure that
users will not! If it were up to me I would try to solve it. One
approach could be similar to what is done in spreadsheets, where
beside the formula the calculated value is also given. Why is it given
when it is redundant? Because it makes the value available even if the
application is unable to calculate it and also it speeds up loading.
Text documents could contain hints to layout in a similar way. If the
line breaks and page breaks created during layout would be saved into
the document, loading would be quicker and editors with a different
layout engine would still be able to render the document exactly as it
was created (because the layout algorithm would not be run on load).
Then when the second user changes a word in a paragraph, that
paragraph could be laid out again and would possibly change things
around a bit, but I think it would be possible to implement these
things in a very nice way (like only laying out the parts of the
paragraph after the change). Of course ODF supports structures a
thousand times more complicated than paragraphs, but I suppose 90% of
the documents do not use much of those, so if something like this
could be done at least for some basic elements like text, it would
already make a difference.

Best regards,

Daniel Darabos