https://bz.apache.org/ooo/show_bug.cgi?id=45593
--- Comment #22 from orcmid <[email protected]> --- I did some mining in the ODF 1.2 specification to see if there are any limitations there. Basically, the answer is "no." You can see the main schema definitions for length-related values at http://nfoworks.org/notes/2014/05/n140504f.htm#length The specification says the units of measure are as defined in [XSL] here: http://www.w3.org/TR/2001/REC-xsl-20011015/slice5.html#section-N8185-Definitions-of-Units-of-Measure However, the "em" unit is not defined in the ODF 1.2 schema for the various length cases. Instead, there is a separate relative length that is a no-unit integer, so that is evidently not the equivalent of an "em", which can be fractional. FIRST CHECKS It would be useful to determine whether this problem is part of the input conversion when lengths are specified, and not actually a limitation on what is acceptable in the file format itself. The format allows arbitrary decimal fixed-point values. It would be good to generate some test documents where the stored values have more decimal precision to see what happens when those documents are ingested by AOO (and other implementations of ODF). If that succeeds, it confirms that the limitation is from the input-conversion when lengths are being specified. That's the ideal case. If there is truncation when reading the format, perhaps as part of conversion to internal units, that's more serious. It is also important to check whether the conversion of 0.375 to 0.38 is simply in output conversion of the internal representation. I assume that the differences are apparent and the rounded result is what is actually used, based on the reports here. TRANSFORMATION ISSUES Because graphics allow transformation of coordinate systems, there is a requirement for greater precision in the internal processing. @alg has mentioned a concern about that in a previous comment. Whatever is done to carry more-precise length values has to carry into coordinate transformations. INTEROPERABILITY CONSIDERATIONS This defect (I agree, it is a bug in implementation-dependent behavior) is inherited in openoffice.org common code. The analysis of the defect and what the repairs are needs to be shared with other descendants of openoffice.org. It would also be interesting to see the FIRST CHECKS results produced by Microsoft Office Word when saving in ODF format. -- You are receiving this mail because: You are on the CC list for the issue. You are the assignee for the issue.
