Issue 45593 - Measurement unit: Inch - Needs more decimal places
Summary: Measurement unit: Inch - Needs more decimal places
Status: CONFIRMED
Alias: None
Product: Draw
Classification: Application
Component: formatting (show other issues)
Version: OOo 2.0 Beta
Hardware: All All
: P3 Trivial with 21 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
: 28243 30277 126372 127333 (view as issue list)
Depends on:
Blocks:
 
Reported: 2005-03-21 00:12 UTC by johnwhardy
Modified: 2017-02-24 20:08 UTC (History)
11 users (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description johnwhardy 2005-03-21 00:12:32 UTC
In DRAW and WRITER, if you choose "Inch" as the "Measurement unit", you are
limited to two digits to the right of the decimal point. This is WAY to
limiting. There should be at least four or five, preferrably even six digits (or
more) available. Even something as simple as [.375"] or [.0625"], very common
spacings and dimensions, are not possible. The user should not have to change to
some other unit of measurement (points or millimeters) to achieve more accuracy
in sizing or positioning elements of a document or drawing. It is now the year
2005, and there is no excuse for such a limitation. Thank you.
Comment 1 wolframgarten 2005-03-21 08:07:37 UTC
Chnaged to enhancement.
Comment 2 orsonj 2005-05-05 00:10:09 UTC
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 )
Comment 3 orsonj 2005-05-05 00:19:02 UTC
This is also in the label creator.
Comment 4 johnwhardy 2005-05-05 03:22:40 UTC
*** Issue 45593 has been confirmed by votes. ***
Comment 5 smerkley 2005-08-15 22:09:47 UTC
*** Issue 30277 has been marked as a duplicate of this issue. ***
Comment 6 robertf 2005-08-29 13:38:22 UTC
This problem also applies to units other than inches.
Comment 7 oorwullie 2005-10-29 11:53:57 UTC
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.
Comment 8 johnwhardy 2005-11-03 19:20:56 UTC
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.
Comment 9 peterhb 2005-11-05 20:17:32 UTC
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.
Comment 10 Joe Smith 2006-10-20 18:22:32 UTC
Same as Issue 28243.
Comment 11 johnwhardy 2006-10-20 19:55:55 UTC
Same as Issue 28243.

And it hasn't been fixed over there either.
Comment 12 johnwhardy 2007-07-29 02:51:03 UTC
This problem still exists in version 2.2.1. Will someone please advise if it
will be looked at and fixed? Thank you.
Comment 13 johnwhardy 2008-09-02 01:31:32 UTC
I just tried Open Office 3.0 Beta 2 and this issue still exists. Are there any
plans to fix this problem? Thank you.
Comment 14 cno 2010-11-30 16:11:39 UTC
*** Issue 28243 has been marked as a duplicate of this issue. ***
Comment 15 heywood 2013-05-04 15:28:37 UTC
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.
Comment 16 John Hardy 2013-05-04 18:42:47 UTC
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.
Comment 17 Armin Le Grand 2013-05-06 16:33:34 UTC
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.
Comment 18 Rob Weir 2013-05-06 18:08:35 UTC
@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.
Comment 19 Armin Le Grand 2013-05-07 14:56:16 UTC
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...
Comment 20 heywood 2013-05-07 18:47:16 UTC
(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.
Comment 21 eigenfunctions 2014-08-22 16:40:15 UTC
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"!
Comment 22 orcmid 2015-02-14 18:12:14 UTC
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.
Comment 23 mroe 2015-10-07 04:38:57 UTC
*** Issue 126372 has been marked as a duplicate of this issue. ***
Comment 24 oooforum (fr) 2017-02-24 14:20:07 UTC
*** Issue 127333 has been marked as a duplicate of this issue. ***