[ODFPlugtest] Outcome scenario's Dutch vendors

[Hanssens Bart]

IMHO, the issues found during the Dutch vendor track (with the exception of SDU/Lunatech's presentation
about complex legal documents) are implementation issues rather than ODF issues.

Many vendors use OOo / LO to create the template and/or to verify if they get the "correct" result.

About the fonts, it is indeed correct that font-embedding is permitted in ODF, but hardly been implemented.
IIRC, installing the liberation fonts does not always work, since the names of the liberation fonts are not the same


The test files are available on the NOiV, so I'll run them through officeshots.org to see what the results are.

Best regards

Bart

-----Original Message-----
From: plugtest-bounces at opendocsociety.org [mailto:plugtest-bounces at opendocsociety.org] On Behalf Of Jos van den Oever
Sent: dinsdag 22 november 2011 9:31
To: ODF Plugfest mailinglist
Subject: Re: [ODFPlugtest] Outcome scenario's Dutch vendors

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






_______________________________________________
Plugtest mailing list
Plugtest at opendocsociety.org
http://lists.opendocsociety.org/mailman/listinfo/plugtest