[Inkscape-devel] Units

[Jelle]

Dear all,

On Units:
After some digging I found that Inkscape uses a 90dpi setting internally
for everything. It finally explains the insane precision to me. Now that's
fine with me, but it would be really handy if you could set your own
preferences. As a user of metrics it really is mindnumbing to have to work
with 3.543307 px per mm. I'd much rather would set that to 10 or 100 for
instance so I can more easily work from px units into mm and vice versa. I
guess that for those that use their feet to do measurements 90dpi makes
more sense though they must have some trouble when it comes to fractions
of Inches (what pinky's?). If I want to design something in metrics and I
get all those fractioned numbers in my files, it makes it a tad difficult
to edit it by hand or script. Especially the latter is rather important
for me.

So the question here is,.. is it humanly possible to create a setting of
your units and their conversion to px so the whole SVG document starts
using those unit settings? If this is set in some script, where can I find
the script and wouldn't it be great if that could be turned into a user
settings config script that is editable from Inkscape. I'd be happy to
make an interface for it as an extension as I think even I could do that
with my limited skills in programming. I bet it all comes down to getting
Inkscape to recognise these new settings at runtime, but restarting the
application after changing the settings might be an option (Alert: restart
Inkscape to use your new settings).

I love Inkscape and its functionality for web design, but I think making
it more flexible with unit settings might make it really useful for those
that want to organise their whole work flow including print with it.

On SVGDOM and Pyhton:
Can one access the SVGDOM from python like you do from javascript? Using
getAttributeNS etc.? If so, I'd like to try write some extensions.

On the topic of the Inkscape UI re-design:
If anything I'd love to see a UI that would be completely configurable
like the one in Coreldraw. I also like the Gimp where UI objects and
canvas are separated. Though it would be nice if there was some way to set
a Z order in those as you often move new windows over UI objects and thus
hiding them. Some UI object manager could be useful in that regard.
Alternatively I would suggest making the canvas UI have a set position in
the window and scale it when you open a docker. Now the part of the
drawing get's hidden that often holds the objects you need the docker for,
making more clicks. Using the GIMP format it might be possible to dock
over the right side of the canvas window edge and like wise for tools to
move them to the left side over the windows edge. This should be an OPTION
as not everyone has a screen estate of 1920x1600 where this method would
really make sense. It would defy some UI design adagia no doubt, but the
movements would be a logical extension of the ones you are already making.

Jelle Mulder


On Sat, 03 Nov 2012 06:30:22 +0800,

Send Inkscape-devel mailing list submissions to
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
or, via email, send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Inkscape-devel digest..."
1. Re: Problem export to png in spanish version (alvinpenner)
2. Re: Problem export to png in spanish version (Benjamin N??ez)
----------------------------------------------------------------------
Message: 1
Date: Fri, 2 Nov 2012 14:55:58 -0700 (PDT)
Subject: Re: [Inkscape-devel] Problem export to png in spanish version
Content-Type: text/plain; charset=UTF-8
cami?nCatalu?a.png
<Loading Image...>
- not reproduced on Windows 7, Inkscape 0.48.3.1.
- attached is a png file saved using Export Bitmap.
- just for clarification, is it only the file that has non-Ascii
characters,
or do the directories also have non-Ascii characters?
Alvin Penner
--
http://inkscape.13.n6.nabble.com/Problem-export-to-png-in-spanish-version-tp4965537p4965540.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
------------------------------
Message: 2
Date: Fri, 2 Nov 2012 23:29:53 +0100
Subject: Re: [Inkscape-devel] Problem export to png in spanish version
Content-Type: text/plain; charset="iso-8859-1"
Ahhhh ok, it's true. When we use export bitmap no problem with "?".
Is only when I try use the option "save as" and Cairo PNG when I have
that
problem.
And your question yes, when the directorie have non-Ascii characters I
can't save the file with "save as", but no problem when I use Export
Bitmap.
Thanks for everything.
Benja

cami?nCatalu?a.png
<
http://inkscape.13.n6.nabble.com/file/n4965540/cami%C3%B3nCatalu%C3%B1a.png
- not reproduced on Windows 7, Inkscape 0.48.3.1.
- attached is a png file saved using Export Bitmap.
- just for clarification, is it only the file that has non-Ascii
characters,
or do the directories also have non-Ascii characters?
Alvin Penner
--
http://inkscape.13.n6.nabble.com/Problem-export-to-png-in-spanish-version-tp4965537p4965540.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
Inkscape-devel mailing list
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[i***@fastmail.net]

On Mon, 05 Nov 2012 17:56:07 +0800

Post by Jelle
After some digging I found that Inkscape uses a 90dpi setting
internally for everything. It finally explains the insane precision to
me. Now that's fine with me, but it would be really handy if you could
set your own preferences. As a user of metrics it really is
mindnumbing to have to work with 3.543307 px per mm. I'd much rather
would set that to 10 or 100 for instance so I can more easily work
from px units into mm and vice versa. I guess that for those that use
their feet to do measurements 90dpi makes more sense though they must
have some trouble when it comes to fractions of Inches (what
pinky's?). If I want to design something in metrics and I get all
those fractioned numbers in my files, it makes it a tad difficult to
edit it by hand or script. Especially the latter is rather important
for me.

see my recent post on a related subject:

http://sourceforge.net/mailarchive/message.php?msg_id=30053042

Post by Jelle
So the question here is,.. is it humanly possible to create a setting
of your units and their conversion to px so the whole SVG document
starts using those unit settings? If this is set in some script, where
can I find the script and wouldn't it be great if that could be turned
into a user settings config script that is editable from Inkscape.

The inch and foot units are defined in the Inkscape config file
"/usr/share/inkscape/ui/units.txt", or possibly
"/usr/share/inkscape/ui/units.xml". I'm not sure which of these files
is supposed to be normative; why are there two of them?

If you were to edit your "units.txt" file to include the following
definitions, that might accomplish some of what you want:

# name name_plural abbr type factor PRI description
# ---------------------------------------------------------------------------
pixel pixels px LINEAR 1.00 Y CSS Pixels (1.0 px/mm)
millimeter millimeters mm LINEAR 1.00 N Millimeters (1.0 mm/px)
centimeter centimeters cm LINEAR 10.0 N Centimeters (10 mm/cm)
meter meters m LINEAR 1000.0 N Meters (100 cm/m)
inch inches in LINEAR 25.4 N Inches (25.4 px/in)
foot feet ft LINEAR 304.8 N Feet (12 in/ft)

Post by Jelle

It seems rather silly that for some purposes, the unit definitions
would be read at runtime from a config file, while for other
purposes, they would be compiled into the program binary, but that
appears to be how it currently works.

I'd be happy to make an interface for it as an extension as I think
even I could do that with my limited skills in programming. I bet it
all comes down to getting Inkscape to recognise these new settings at
runtime, but restarting the application after changing the settings
might be an option (Alert: restart Inkscape to use your new settings).

I would point out that the SVG specification does not prescribe any
particular ratio between "px" drawing units and actual physical
lengths. (It certainly DOES NOT specify that 90 px = 1 inch, as
Inkscape currently assumes [units.txt]; this ratio is only mentioned
as "for example".)
http://www.w3.org/TR/SVG/coords.html#Units
I suggest that for Inkscape, "px" be considered to be equivalent to
the specified "Default unit" from the Document Properties window. If
the default unit is metres, or whatever, then that's what "px" means,
for that document, but no other. I don't see how this is inconsistent
with the SVG specification.

I love Inkscape and its functionality for web design, but I think
making it more flexible with unit settings might make it really useful
for those that want to organise their whole work flow including print
with it.

https://blueprints.launchpad.net/inkscape/+spec/real-units
Bob wants to draw a house plan in feet and inches, but still
print it on a letter-sized paper. (one idea: different layers can
have different scales: e.g. border layer is actual size, house
layer is 1 in. = 8 ft.)

-- Ian Bruce

[Jasper van de Gronde]

Post by Jelle
...
So the question here is,.. is it humanly possible to create a setting of
your units and their conversion to px so the whole SVG document starts
using those unit settings?

What Inkscape should do, is allow setting (either implicitly or
explicitly) both the width/height and(!) the viewBox. I actually started
out implementing this in the document preferences dialog, with default
settings that essentially gave sensible correspondences between pixels
and the units used for the document size. However, it turns out that
Inkscape essentially has three not completely compatible concepts of units.

Having said that, maybe there is still a way to do this, so feel free to
try implementing setting viewBox along with the document size (or some
such scheme). And if anyone feels like tackling the units system, here
are the main files to look:
src/sp-metric*
src/helper/unit*
src/util/unit*

I still might have some code lying around that removes most of
sp-metric, so this could serve as a start.

[i***@fastmail.net]

On Tue, 06 Nov 2012 09:51:03 +0100

Post by Jasper van de Gronde
What Inkscape should do, is allow setting (either implicitly or
explicitly) both the width/height and(!) the viewBox. I actually
started out implementing this in the document preferences dialog, with
default settings that essentially gave sensible correspondences
between pixels and the units used for the document size. However, it
turns out that Inkscape essentially has three not completely
compatible concepts of units.
Having said that, maybe there is still a way to do this, so feel free
to try implementing setting viewBox along with the document size (or
some such scheme).

Please see my recent post on exactly this issue:

http://sourceforge.net/mailarchive/forum.php?thread_name=20121104003312.162fa089.ian_bruce%40fastmail.net&forum_name=inkscape-devel

Post by Jasper van de Gronde

There is a much better solution, which is illustrated by the attached
image "scale.png". This is intended as an addition to the current
"Document Properties/Page" config window. It specifies the scale at
which the drawing will be displayed on the physical screen, as a
ratio between real dimensions on the screen, and the declared
dimensions of the drawing.
It seems rather silly that for some purposes, the unit definitions
would be read at runtime from a config file, while for other
purposes, they would be compiled into the program binary, but that
appears to be how it currently works.

And if anyone feels like tackling the units system, here are the main
src/sp-metric* src/helper/unit* src/util/unit*
I still might have some code lying around that removes most of
sp-metric, so this could serve as a start.

I don't understand why there should be specific code to handle metric
units. Surely the simplest thing to do is have the ratios between
various real-world units defined in the "units.txt" file, and then have
the "Default units" option from the "Document Properties/Page" dialog
specify which one of those will be considered equivalent to "px" for
purposes of that document.

Systems of related units, with integer ratios between them, such as
inch/foot/yard/mile, and um/mm/cm/m/km, could be treated as a special
case. Then specifying the ratio between any pair of them, such as
1.0 inch = 0.0254 metre , also determines all the other ratios. Having
all such units specified in a config file eliminates the need for code
changes when somebody wants to introduce new ones.


-- Ian Bruce

[Jasper van de Gronde]

Post by i***@fastmail.net
..
I don't understand why there should be specific code to handle metric
units.

It is a different kind of "metric" :) (Think measure instead SI units.)

Post by i***@fastmail.net
Surely the simplest thing to do is have the ratios between
various real-world units defined in the "units.txt" file, and then have
the "Default units" option from the "Document Properties/Page" dialog
specify which one of those will be considered equivalent to "px" for
purposes of that document.

Nobody said it is particularly difficult, but it does take time. Of
course, if you're volunteering, I couldn't be happier :) (As would a
whole lot of other people.)

Post by i***@fastmail.net
Systems of related units, with integer ratios between them, such as
inch/foot/yard/mile, and um/mm/cm/m/km, could be treated as a special
case. Then specifying the ratio between any pair of them, such as
1.0 inch = 0.0254 metre , also determines all the other ratios. Having
all such units specified in a config file eliminates the need for code
changes when somebody wants to introduce new ones.

Actually, something like that might indeed make sense. Perhaps it would
then make most sense to simply split the definitions of the units
themselves and the relationships between them. Conversion between two
units would then only be possible if there is a path of conversion rules
between them.

[i***@fastmail.net]

On Tue, 06 Nov 2012 13:00:36 +0100

Post by Jasper van de Gronde

Post by i***@fastmail.net
I don't understand why there should be specific code to handle metric
units.

It is a different kind of "metric" :) (Think measure instead SI units.)

Well, colour me corrected.

Post by Jasper van de Gronde

Post by i***@fastmail.net
Surely the simplest thing to do is have the ratios between various
real-world units defined in the "units.txt" file, and then have the
"Default units" option from the "Document Properties/Page" dialog
specify which one of those will be considered equivalent to "px" for
purposes of that document.

Nobody said it is particularly difficult, but it does take time. Of
course, if you're volunteering, I couldn't be happier :) (As would a
whole lot of other people.)

Could you tell me what is the significance of the current "units.txt"
and "units.xml" files?

As I said in my initial post, the influence of "units.txt" seems to be
less than total, and that of "units.xml" is apparently nil.

Post by Jasper van de Gronde

Post by i***@fastmail.net
Systems of related units, with integer ratios between them, such as
inch/foot/yard/mile, and um/mm/cm/m/km, could be treated as a special
case. Then specifying the ratio between any pair of them, such as 1.0
inch = 0.0254 metre , also determines all the other ratios. Having
all such units specified in a config file eliminates the need for
code changes when somebody wants to introduce new ones.

Actually, something like that might indeed make sense. Perhaps it
would then make most sense to simply split the definitions of the
units themselves and the relationships between them. Conversion
between two units would then only be possible if there is a path of
conversion rules between them.

That's what I was thinking of, except that you still have to define the
units in terms of something else. I propose that the "units.xml" format
be extended to handle hierarchical definitions, and ratios, as I
suggested in my previous post. For example:

<unitdefs>
<linear>

<unit factor="1.0">
<name>metre</name>
<plural>metres</plural>
<abbr>m</abbr>
<description>Metres (SI base unit)</description>

<unit factor="1/1000">
<name>millimetre</name>
<plural>millimetres</plural>
<abbr>mm</abbr>
<description>Millimetres (1000 mm/m)</description>
</unit>

<unit factor="1/100">
<name>centimetre</name>
<plural>centimetres</plural>
<abbr>cm</abbr>
<description>Centimetres (100 cm/m)</description>
</unit>

<unit factor="1000">
<name>kilometre</name>
<plural>kilometres</plural>
<abbr>km</abbr>
<description>Kilometres (1000 m/km)</description>
</unit>
</unit>

<unit factor="0.9144">
<name>yard</name>
<plural>yards</plural>
<abbr>yd</abbr>
<description>International Yards (0.9144 m/yd)</description>

<unit factor="1/3">
<name>foot</name>
<plural>feet</plural>
<abbr>ft</abbr>
<description>Feet (3 ft/yd)</description>

<unit factor="1/12">
<name>inch</name>
<plural>inches</plural>
<abbr>in</abbr>
<description>Inches (12 in/ft)</description>
</unit>
</unit>

<unit factor="1760">
<name>mile</name>
<plural>miles</plural>
<abbr>mi</abbr>
<description>Miles (1760 yd/mi)</description>
</unit>
</unit>

</linear>
</unitdefs>

Here, the relationship between Metric and Imperial units is implicit in
the ratio [1/1.0 metre : 1/0.9144 yard]. Other unit conversions must
follow the path through the hierarchy, as you suggest. If a top-level
unit definition does not specify a conversion factor, then there will be
no possibility of converting units from that hierarchy to those from
another, which is perfectly OK.

Any other units that people wish to use (angstroms, picas, nautical
miles, light years, etc) can simply be inserted into this tree, at
either the top level, or a subordinate one. "px" units will not be
defined here; they will be considered equivalent to whatever is selected
as the "Default unit" for the document.


-- Ian Bruce

[mathog]

Maybe I am old fashioned but I just don't understand the problem. For
as long as I can remember scale drawings said in
the legend something like "1 inch per foot" or "1 inch per mile", or
whatever. In Europe it was probably "1 cm per meter",
which is even easier. Then the person making the drawing, and the
person reading it, would just replace one unit for the other in their
head - 10 was inches on the drawing, but feet in the real world. Which
was pretty easy to do so long as it was 1 of these for 1 one of those,
and only slightly harder if it was 1:5 or some other ratio.

The document being produced by Inkscape is a drawing, and it will never
be at actual scale for microscopic or macroscopic objects. If it was it
wouldn't be possible to print the drawing without scaling it up or down.
This has always been true of
drawings of actual objects, except in a few extremely rare instances
where full scale drawings are produced (like masks for chips
or spray painting templates).

Would not some sort of "sticky" comment that reflected the drawing to
represented object length ratio suffice to address this "problem"?

David Mathog
***@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech

[i***@fastmail.net]

On Tue, 06 Nov 2012 09:35:46 -0800

Maybe I am old fashioned but I just don't understand the problem. For
as long as I can remember scale drawings said in the legend something
like "1 inch per foot" or "1 inch per mile", or whatever. In Europe it
was probably "1 cm per meter", which is even easier. Then the person
making the drawing, and the person reading it, would just replace one
unit for the other in their head - 10 was inches on the drawing, but
feet in the real world. Which was pretty easy to do so long as it was
1 of these for 1 one of those, and only slightly harder if it was 1:5
or some other ratio.

The "units.txt" file specifies "3.543307" as the conversion factor
between millimetres and "px", the unit used internally. Does this ratio
meet your criteria for "only slightly harder"? Have you ever seen a
drawing which specified a scale of "3.937008 inches per metre"
(otherwise known as "1:10")?

As a user of metrics it really is mindnumbing to have to work with
3.543307 px per mm. I'd much rather would set that to 10 or 100 for
instance so I can more easily work from px units into mm and vice
versa. I guess that for those that use their feet to do measurements
90dpi makes more sense though they must have some trouble when it
comes to fractions of Inches (what pinky's?). If I want to design
something in metrics and I get all those fractioned numbers in my
files, it makes it a tad difficult to edit it by hand or script.
Especially the latter is rather important for me.

In any case, your analogy is inaccurate. You will recall that
engineering drawings of the sort you are describing, in addition to the
scale being specified in the legend, have all the most important
dimensions explicitly marked on the drawing itself, and these are ALWAYS
specified in terms of real-world dimensions, and are NEVER adjusted by
the scale factor of the drawing. The idea that a drawing of a machine
part, or building, designed in imperial units, would be dimensioned in
metric, or vice-versa, is too absurd to merit further comment.

The direct analog of the scale specification you are referring to, is
the zoom factor setting which appears in the lower-right corner of the
Inkscape window, not coincidentally the same position as the scale on a
paper drawing. Nobody is suggesting getting rid of this; we are merely
asking that the explicit dimensions in the drawing be expressed in terms
of appropriate real-world units, as they invariably are for a paper
drawing. Why should the measurement information available from a drawing
produced on a 3GHz 64-bit computer be inferior to that produced with a
ruler and pencil on a sheet of paper?

The document being produced by Inkscape is a drawing, and it will
never be at actual scale for microscopic or macroscopic objects. If it
was it wouldn't be possible to print the drawing without scaling it up
or down.

If you were looking at a road map, and the distance between New York and
Los Angeles was specified as "427.3 mm", would you regard that as
acceptable? Or would you conclude that the people who drew the map were
idiots?

This has always been true of drawings of actual objects, except in a
few extremely rare instances where full scale drawings are produced
(like masks for chips or spray painting templates).

Templates for wooden frames or steel plates in shipbuilding, body panels
for cars and other sheet-metal work, and cloth panels for sails, tents,
clothing, and hot air balloons, also come to mind, although many of
these processes probably now use computer-driven laser cutters, so that
no paper drawing is needed at all.

It seems safe to assume that when reduced-scale design drawings were
made for these objects, any explicit dimensions were specified using
real-world units.

Would not some sort of "sticky" comment that reflected the drawing to
represented object length ratio suffice to address this "problem"?

That's what the zoom setting box is for, and it's not constant, because
one of the advantages of a computer over a piece of paper is that you
can easily adjust the visible/physical scale ratio.

I also addressed this issue here:

http://sourceforge.net/mailarchive/forum.php?thread_name=20121104003312.162fa089.ian_bruce%40fastmail.net&forum_name=inkscape-devel

http://sourceforge.net/mailarchive/attachment.php?list_name=inkscape-devel&message_id=20121104003312.162fa089.ian_bruce%40fastmail.net&counter=1

And other people addressed it here:

http://wiki.inkscape.org/wiki/index.php/BlueprintGeometricAndTechDrawing

http://wiki.inkscape.org/wiki/index.php/BlueprintRealUnit

I note that these proposals are marked "priority: essential" and
"priority: high", respectively.


-- Ian Bruce

[mathog]

Post by i***@fastmail.net
The "units.txt" file specifies "3.543307" as the conversion factor
between millimetres and "px", the unit used internally. Does this ratio
meet your criteria for "only slightly harder"? Have you ever seen a
drawing which specified a scale of "3.937008 inches per metre"
(otherwise known as "1:10")?

Internally Inkscape has a consistent drawing model, which is 90 dpi.
The conversion you are referring to is the result of 90 dots per
inch/25.4
mm/inch to give 3.543307 dots (pixels) per mm. Internally inkscape has
all sorts of inch,pixel, and mm conversions, but they are all with
respect
to the fixed scale of 90 dpi.

Post by i***@fastmail.net
In any case, your analogy is inaccurate. You will recall that
engineering drawings of the sort you are describing, in addition to the
scale being specified in the legend, have all the most important
dimensions explicitly marked on the drawing itself,

That is correct, although the units may be implicit at each label with
the
units explicitly marked in the legend, as in "All measurements in
feet."

Post by i***@fastmail.net
If you were looking at a road map, and the distance between New York and
Los Angeles was specified as "427.3 mm", would you regard that as
acceptable? Or would you conclude that the people who drew the map were
idiots?

The map will say "427.3" and the legend will tell me what the units
are. I would
interpret the map accordingly without regard to its actual size, as I
may have
a copy which has been enlarged or reduced in size relative to the
"standard" map.

Post by i***@fastmail.net
Templates for wooden frames or steel plates in shipbuilding, body panels
for cars and other sheet-metal work, and cloth panels for sails, tents,
clothing, and hot air balloons, also come to mind, although many of
these processes probably now use computer-driven laser cutters, so that
no paper drawing is needed at all.

Yes, and if one were going to make such a thing from Inkscape one would
set the proper
scale factor for the "printer" which was capable of such a large scale
rendering.

Post by i***@fastmail.net
It seems safe to assume that when reduced-scale design drawings were
made for these objects, any explicit dimensions were specified using
real-world units.

Right. I seem to be missing your point. A drawing of the USA is
imported,
a line with arrow ends is drawn from LA to New York and is labeled
"3940". The legend
says units are in miles. What exactly is Inkscape doing wrong here
that needs
to be corrected?

Post by i***@fastmail.net

Post by mathog
Would not some sort of "sticky" comment that reflected the drawing to
represented object length ratio suffice to address this "problem"?

That's what the zoom setting box is for, and it's not constant, because
one of the advantages of a computer over a piece of paper is that you
can easily adjust the visible/physical scale ratio.

The zoom setting box in this analogy is just a magnifying glass to be
applied over the drawing.
Looking through it would not change the labels. Using it does not
affect the
scale relationship between the drawing and the real objects represented
in the drawing.

Post by i***@fastmail.net
http://sourceforge.net/mailarchive/forum.php?thread_name=20121104003312.162fa089.ian_bruce%40fastmail.net&forum_name=inkscape-devel

which says

Post by i***@fastmail.net
I found that in order to fit the whole drawing on the screen at once,
I
had to set the zoom factor to 3% or less, which was inconvenient.

That sounds like you tried to draw it 1:1 at the internal resolution of
90 dpi. My screen is about 2 feet across and
2 *33.3 ~= 67 ft, which is roughly house sized. If you go into the the
page setup and create a document which is 100ft x 100ft
then you can use the "ft" setting elsewhere. Note however that what
this has done is to create a drawing which is basically a
100ft x 100ft sheet of paper. When the cursor moves on that screen the
pixel values are very large. When I did that using
the Windows version zoom would not go below 1% so it was not possible
to fit the entire drawing on the screen at once (close though). This
approach is not the way to go, you might be able to squeeze in a house,
but certainly not a battleship or a city.

There are a couple of things that might be helpful in constructing
scale drawings. One would be a measuring tool which reads out in the
"real world" coordinates instead of document coordinates. For instance,
read the 50m diagonal length of a rectangle that was drawn at 30 meters
by 40 meters by selecting opposite corners and using "measure". Another
would be an external/internal scale factor ("1 foot per inch"), which
would change the ruler units and coordinate units, both of which are
always pixels no matter what the document settings has the drawing set
to. (This is what I think you requested originally, more or less.)
That wouldn't be very hard to do. Adding the same feature everywhere
might be a bit of a challenge. For instance, in "Transform"
one can set the shift value to "ft", but that is distance in the
drawing, not in the represented object. That dialog would need
to be modified if the scaled value was to be used instead.

True architectural drawing and CAD/CAM programs go a heck of a lot
farther than just providing a document to represented object scale.
Nowadays they detect nonphysical interactions (walls going through
walls), produce lists of parts, draw objects from parts libraries, make
3D views, feed into engineering analysis programs, etc. Inkscape is
just a drawing tool, and even if we give it a built in scale ruler
(essentially) it will still be just a drawing tool.

Regards,

David Mathog
***@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech

[i***@fastmail.net]

On Tue, 06 Nov 2012 13:04:29 -0800

Post by mathog
I seem to be missing your point.

Deliberately, it would appear, which is why I'm not going to bother
responding.