Mike,
Well done! I fully agree with you-
I opened a new calc document, changed the measurement unit from cm to inches. That marked my
document as being changed!
As far as I see there's nothing changed in the document....
Then I changed a column width to 1 (inch) and saved
I took another document to change back from inches to cm.
Then I opened the first document to find that the column width is set to 2.54 cm
So, it seems that the measurement unit is not saved in the document.
However, when I change the default measurement unit the file is marked as changed! Why? Rounding???
What should happen is that the measurement unit is saved in the document, not the rounded internal
value.
On 19 nov. 2015, at 17:32, Mike Scott wrote:
On 19/11/15 15:39, V Stuart Foote wrote:
No, the all measurements in the StarOffice -> OpenOffice Draw/Impress legacy
are derived from raster screen bitmap graphics which has maintained the text
"print" centric practice and uses a smallest "Field_Unit" of twips for
calculations of placement onto the canvas.
A twip (1/1440") --from Postscript 1/72" point-- is a screen independent
value converted (and rounded) in calculating vertex placements as pixel
dimensions. There are routines to convert measurement from twip to mm or
inch--but they are equally imprecise for use in CAD.
Meaning there is no history for vector based measurements (vertex, angles,
radius, and distances) needed for CAD. What is provided is all geared to
rendering bitmap onto a raster canvas--for resample to screen pixels.
So, the "arbitrary" lack of precision is a function of the resampling to
"fit" bitmap elements to pixels of a raster screen. wo Floating point
precision of measurements remains much less significant than performance for
rendering the twip derived document canvas. Yes there was a tradeoff, but an
easy one to make.
If you need the precision for CAD you want a program designed to handle
vectors under the hood, not bitmaps--period!
Whatever the internals within LO, the present behaviour is irrational. Yes, obviously everything
/eventually/ has to be adjusted some arbitrary grid size. However, there's no reason at all for
arbitrary roundings before printing.
In particular, I've just experimented to see what's stored. I draw a single line and position it
(or try to!) at 1.234cm from the margin (itself set at 1cm). I do this twice, with units set to
cm (which forces a rounding to 2.34cm) and them mm (retains 2 dp's in/mm/ this time).
The generated contents.xml has a draw:line element, whose position is in the first case
svg:x1="2.23cm" and in the second svg:x1="2.234cm". So the
They really, really ought to be the same. If the user chooses to work in cm, mm, or cubits, the
available physical precision should nevertheless be ultimately defined by what the printing
system can do.
OTOH, if the stored measurements are rounded to some arbitrary grid, then my two files should
have the same rounded content.
Final experiment. Set the units to feet - and see how the precision drops to about 3mm because
the entries are rounded by the GUI to 2 dp in feet. Rational behaviour? Not from a user's POV.
--
Mike Scott (unet2 <at> [deletethis] scottsonline.org.uk)
Harlow Essex England
--
To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted
--
To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.