Problem description: When using different measure units in different project files, it becomes a problem to open and save. The dimension lines changes and it is necessary to rework the drawing. I have worked with drawings in meters, centimeters and inches. When you have a drawing open and create a new one, with a different measure units, it affects all the files. It would be better that the measure units and grid configuration were in the file properties, because they are specific to that project. I believe that all the options of tools-options-LibreOffice Draw, like General, View, Grid and Print should be in the file properties, and Draw use them to perform the specified properties to the window of the file, interdependently of other opened files. Steps to reproduce: 1. Open or create a drawing file in meters with a grid configuration of 10 spaces of 0.01m. 2. draw some figures, dimension lines and save it 3. create a new one but change the units to inches, and change the grid configuration 4. when saving the new options, the dimension lines of the first file changes to inches. Current behavior: Inconsistent measure units applied to the drawing Expected behavior: Request to enhance the measure units and grid, or all the options of tools-options-LibreOffice Draw, to be in the file properties of each file, and not to to all the Draw module. Operating System: Windows 8 Version: 4.3.1.2 release
Seems a reasonable request. Does not seem possible at present and likely requires amending the ODF specification. Status set to NEW. Platform set to All/All. Severity set to enhancement.
I disagree, changing the measurement unit does not change the values that are stored in metric units in the document. I think that your proposition will lead to interoperability problems if you force the user of your document to use your own exotic (exotic for him) unit system. Additionally, that may lead to legal difficulties. Indeed it may be prohibited to use not metric units for commercial transactions or in official documents (eg. bill of sale). For example, it is the case in France. Switching from unit system to another seems a surprising workflow to me. UX advise requested. Best regards. JBF
(In reply to comment #2) > I disagree, changing the measurement unit does not change the values that > are stored in metric units in the document. Hmmm. I see what you mean. Because ODF references the SVG specification a 2x2 cm rectangle drawn at offset 2 cm (x) and 2 cm (y) with default 1 cm margins results in: <draw:custom-shape draw:style-name="gr1" draw:text-style-name="P1" draw:layer="layout" svg:width="2cm" svg:height="2cm" svg:x="3cm" svg:y="3cm"> <text:p/> <draw:enhanced-geometry svg:viewBox="0 0 21600 21600" draw:type="rectangle" draw:enhanced-path="M 0 0 L 21600 0 21600 21600 0 21600 0 0 Z N"/> </draw:custom-shape> That is a problem at the SVG specification level. There is provision in the SVG specification to use User Units: http://www.w3.org/TR/2003/REC-SVG11-20030114/coords.html#Units ... however that may require a large change to the manner in which measurement units are currently handled in LO (and maybe ODF). Even then this feature of SVG may not be sufficient. It would be good if there was a way (for example) to create a scale drawing using metric and send it to someone using imperial and have them see the same thing. Currently scale drawing interoperability is difficult across locales with differing measurement units.
(In reply to comment #3) > Because ODF references the SVG specification Ugh. I think that statement (in context) is wrong i.e., the SVG specification is referenced, but not for these attributes. It is the XSL specification that ODF references in relation to units of measurement of type Length: http://www.w3.org/TR/2001/REC-xsl-20011015/slice5.html#section-N8185-Definitions-of-Units-of-Measure It appears a unit is mandatory, and as JBF indicates these are not altered in the document simply by changing the unit of measurement in the options.
So we are saving measurement and grid information into a .odg file, so it would be useful to have access to them from File > Properties and Format > Page. I've used Inkscape and they provide similar accessibility. http://www.flyertutor.com/images/inkscape-documentproperties-window.png These settings are being saved in ./settings.xml
Isn't this a duplicate of bug 98453? Keep it available since some valuable comments are found here. Wrt. what information should be stored see also: Bug 98453: Units Bug 78035: grid settings Bug 59068: drawing scale
In my opinion, bug 98453 is not a duplicate of bug 83325, but they are related. Bug 98453 is about a problem with the units of measure with the current framework of Draw. If in the Draw global settings the units of measure are centimeters, and a Draw file saved in inches is opened, Draw should adjust or change the default units for the units of the file in that instance. As the rulers do. The bug 83325 is a request for making the settings of the grid, the units of measure and the scale, part of the file properties, and not the global settings of Draw. Then Draw will use it to adjust the instance of the working file to that settings, and it will not be necessary to define those settings in Tools - Options - General. If this is not likely to be developed, at least bug 98453 should be attended so the users can work with drawings with different units, without having to go to Tools - Options - General, to change the default units, each time a drawing with different units is opened. Although it will be necessary to keep going to Tools - Options - General, to define a new drawing file, when the units of measure were different from the usual units used. I think this could be the first step for further development of bug 83325; if Draw can adjust those settings in the working instance of the file, then later on can be developed the code to include the grid, units and scale settings to the file properties, that override the default or global settings, and ultimately be removed. Sadly I still can't participate with coding, but I am studying and preparing myself to get involved. But is a slow process.
*** This bug has been marked as a duplicate of bug 59068 ***