[ODFPlugtest] Outcome scenario's Dutch vendors

[Jos van den Oever]

Thank you for the summary. Here are some additions. Important information for 
fixing some of the issues is currently missing: which application shows which 
errors? I did not take notes of this relation and I hope someone did.

On Tuesday, November 22, 2011 00:20:04 AM Joris Dirks wrote:
> For those who attended the plugfest in Gouda: thanks for your involvement.
> In the Dutch track, we tested two scenario's, where vendors used real-world
> templates to generate documents.
> 
> We concluded (but Bart will probably have to fill me in here):
> - proprietary fonts like Times New Roman cause problems with rendering on
> linux systems (we'll try and see if the handbook on certain documents can
> be changed to include open fonts)
In ODF, while font-embedding is in it's infancy in the implementations, the 
ODF standard clearly documents it since version 1.0. It is worthwhile to start 
embedding fonts right now. I would love to write an article on a best practice 
for doing so. What would be a good place to put this?
Without font embedding, rendering issues can be minimized by using fonts that 
are very likely to be present on the user side. Most systems have the fonts of 
Monotype Corporation: Arial, Arial Narrow, Times New Roman, and Courier New. 
For these fonts there are metric-compatable fonts that can be used without 
restriction. These are Liberation Sans, Liberation Sans Narrow, Liberation 
Serif and Liberation Mono. The user software (usually the office suite) should 
use these as replacement for the Monotype fonts. Because of the metric 
compatibility, the line-breaking and line heights should be identical.
Users of Microsoft Office are unlikely to have the Liberation  fonts available. 
So it is best to use only Arial, Arial Narrow, Times New Roman, and Courier 
New or the free versions from Liberation. 
http://en.wikipedia.org/wiki/Liberation_fonts
Note that this is theory and a simple set of test documents to verify this 
theory would help.

> - tabs cause problems in rendering, especially for the web. Tables are more
> suited, for instance for aligning left - middle - right texts (preventing
> the 'right' text to continue on a new line)
Tabs can indeed be a problem. Currently no HTML representation known to me can 
faithfully represent them. This problem is no impossible to overcome though. 
The tabs could be emulated by an element for which a custom with is 
calculated.

> - horizontal lines sometimes get thicker or even doubled.
This is a problem in the implementations that should result in bug reports to 
the faulty applications. Details on which applications are buggy in this 
respect are welcome. Filing bug reports to the relevant applications would be 
much appreciated. If in doubt whether this is an issue in the specification or 
in an implementation, one can start a discussion on the public ODF Techinical 
Committe mailing list. (see below).

> - numbering of one letter generated for multiple (24) addressees: the page
> numbering for page two should be '2/2' , not '2/48' (but probably due to
> error on the generating side).
Some implementations do not regenerate the automatic field values when loading 
a file. This might be the cause for the issue. Which file shows this problem in 
which application?

> For "akte van geboorte" (Birth certificate), I've included:
> Aia I-2 akte van geboorte v2.odt (11Kb)
> Centric I-2 akte van geboorte v2.odt (7Kb)
> On behalf of Aia and Centric respectively.

Starting a discussion about ODF issues can be done by subscribing to the ODF 
public comment mailing list at OASIS. To subscribe, send a blank email message 
to:
  office-comment-subscribe at lists.oasis-open.org
When subscribed, you may post comments to:
  office-comment at lists.oasis-open.org


Best regards,
Jos van den Oever