Issue 45593

Chnaged to enhancement.

This limitation is especially apparent in tables.  If you right click on a table
and select row > height and try to enter 0.375" (3/8") it changes to 0.38"  When
you are trying to create an electronic form to print over a pre-printed form, it
is is either too small, or too large.  (Think of something like this:
http://www.adkad.com/blizzardbuster/preprintedpaper.htm )

This is also in the label creator.

*** Issue 45593 has been confirmed by votes. ***

*** Issue 30277 has been marked as a duplicate of this issue. ***

This problem also applies to units other than inches.

For imperial measurement users, fractions beyond the first level fractions (1/2,
1/4, 3/4) are rounded. While the rounding is small it produces two main
irritations for me
1. it reduces the accuracy of positioning items on a page (in my case
photographs from post-production issued in inch measurements) 
2 it over-simplifies (potential errors) our inventory in Calc and Base involving
equipment in the workshop that are in imperial measure such as screw-threads,
bolts and nuts etc.
While we work around this at present, it nontheless makes me ask why it has to be.

I reported this problem on Oct. 27 to the gmane.comp.openoffice.questions
newsgroup with mixed responses. Some people agreed about the problem, others
worried about "code bloat", etc.

I also posted a message to the developers mailing list on Oct.27 with no
response as of Nov. 3.

I downloaded the OpenOffice.org Developers Guide 2.0 "DevelopersGuide.pdf" (1047
pages) and found that all variables such as margins, line spacing, tabs, etc.,
are described as having a resolution of [1/100 mm]. The word "inch" only appears
once in the document, referring to characters per inch.

So, in my opinion, OO is metric-centric, and none of the developers gave
anything but a last-minute reluctant (they had to be dragged kicking and
screaming) consideration to the use of Inches. I think this is a huge mistake on
their part, and I wish the developers responsible for this particular portion of
OO code would step up to the plate and make a statement about it.

This is such a trivial thing to fix it is difficult to understand why no
developer seems to have commented on the issue.

Please fix it, so that tables, label sheets etc. can be laid out correctly in
Writer: I really don't want to have to create and maintain a private fork.

Same as Issue 28243.

Same as Issue 28243.

And it hasn't been fixed over there either.

This problem still exists in version 2.2.1. Will someone please advise if it
will be looked at and fixed? Thank you.

I just tried Open Office 3.0 Beta 2 and this issue still exists. Are there any
plans to fix this problem? Thank you.

*** Issue 28243 has been marked as a duplicate of this issue. ***

Bump.

It has been over EIGHT YEARS since this bug was filed, but I just ran into it on the current release (AOO 3.4.1, OSX). Importance is marked as "P3 trivial" (and this "P3" designation is not even explained anywhere on the "fields" page), but I think this is very short-sighted -- sketching something to eight-inch precision without suffering roundoff errors is really not much to ask.

Adding my 2 votes.

heywood: Thanks for raising this issue again. I just added two votes. I filed the bug March 21, 2005. It's amazing that such a basic and often-used feature can be left in such a limiting state. Perhaps the developers will finally wake up and fix it. How hard can it be to add a few digits of precision to dimensions?

The bug is currently assigned to "AOO issues mailing list". What is that?? It sounds like the equivalent of the circular file.

I disagree with the rating of "P3 trivial". If you cannot accurately place things on the page, it is not trivial. We are not just writing letters to mom. We need to create accurate and complex documents, tables, forms, drawings, and so on.

Thank you.

ALG: Not sure if it is as trivial as described. The DrawingLayer internally uses 1/100th mm in 32-bit integer, thus the resolution is limited to this. I am working on changing this to double precision, but as long as this is not done, this issue might run into problems.

@alg, 0.01 inches is 0.0254 mm.   So even if internal precision is limited to 0.01 mm, it should be able to handle 3 decimals for inches, right?

The issue is for countries that still use non-metric, customary units, as in the US and UK.  Not only do we use inches, but we use non-decimal fractions, based on 8ths or 16ths.  So "4 1/8 inches" is a very common thing to deal with. 

The tricky thing is we'd want an extra decimal for inches, but not for mm.

ALG: I did not say that it has to get us into trouble, but it could. It also depends on the document size you choose in preferences; some people already stumbled over these internal limitations. And with three digits for inches

0.001 inches -> 0.00254mm -> 0.0 with 1/100th mm limittation
0.004 -> 0.01016mm -> 0.01
...

The internal data *is* in 1/100th mm, on the UI it is shown as inches. In Writer the model is on twips, analog from there...

(In reply to comment #15)
> sketching something to eight-inch precision without suffering
> roundoff errors is really not much to ask.

Sorry for replying to my own comment, but I just noticed an (obvious?) typo in my earlier posting -- I meant "eighth-inch," not "eight-inch." I certainly hope AOO can handle eight-inch increments ;).

Anyway, I do appreciate the numerical subtleties (internal precision, mm vs. inch, etc.), so I wasn't trying to suggest that this should be a trivial fix -- only that I don't think the "P3 trivial" _rating_ seemed unreasonable.

This is something that is a real problem. The problem has been known for many years now, has been confirmed and so it needs to be fixed. 

Restricted to only 2 decimal places limits the value of using draw for dimensioned drawings. I do not agree that this is an "enhancement"!

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.

*** Issue 126372 has been marked as a duplicate of this issue. ***

*** Issue 127333 has been marked as a duplicate of this issue. ***