6:56 p.m.
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,
<inkscape-devel-request(a)lists.sourceforge.net> wrote:
Send Inkscape-devel mailing list submissions to
inkscape-devel(a)lists.sourceforge.net
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
inkscape-devel-request(a)lists.sourceforge.net
You can reach the person managing the list at
inkscape-devel-owner(a)lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Inkscape-devel digest..."
Today's Topics:
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)
From: alvinpenner <penner@...1856...>
Subject: Re: [Inkscape-devel] Problem export to png in spanish version
To: inkscape-devel(a)lists.sourceforge.net
Message-ID: <1351893357935-4965540.post@...2730...>
Content-Type: text/plain; charset=UTF-8
cami?nCatalu?a.png
<http://inkscape.13.n6.nabble.com/file/n4965540/cami%C3%B3nCatalu%C3%B1a.p...
- 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
--
View this message in context:
http://inkscape.13.n6.nabble.com/Problem-export-to-png-in-spanish-version...
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
------------------------------
Message: 2
Date: Fri, 2 Nov 2012 23:29:53 +0100
From: Benjamin N??ez <benji.n.gon@...400...>
Subject: Re: [Inkscape-devel] Problem export to png in spanish version
To: alvinpenner <penner@...1856...>
Cc: inkscape-devel(a)lists.sourceforge.net
Message-ID:
<CAAZNt3vyWuVE-u0VdMEr-GeUOiCJ3kuX2n_quvZhm_4dQOsbpw@...401...>
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
2012/11/2 alvinpenner <penner@...1856...>
> 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
>
>
>
> --
> View this message in context:
>
http://inkscape.13.n6.nabble.com/Problem-export-to-png-in-spanish-version...
> 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
> Inkscape-devel(a)lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>
5:25 p.m.
On Mon, 05 Nov 2012 17:56:07 +0800
Jelle <pjmulder@...353...> wrote:
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
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.
quoting myself:
> 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)
On the other hand:
> 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.
> Note the following related feature request, rated as
"Priority:
> High":
>
> 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
5:51 p.m.
On 05-11-12 10:56, Jelle wrote:
...
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.
6:57 p.m.
On Tue, 06 Nov 2012 09:51:03 +0100
Jasper van de Gronde <th.v.d.gronde@...528...> wrote:
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.1...
> 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
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 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
9 p.m.
On 06-11-12 10:57, ian_bruce@...2136... wrote:
..
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.)
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.)
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.
1:55 a.m.
On Tue, 06 Nov 2012 13:00:36 +0100
Jasper van de Gronde <th.v.d.gronde@...528...> wrote:
> 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.
> 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.
> 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
2:35 a.m.
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
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
4:59 a.m.
On Tue, 06 Nov 2012 09:35:46 -0800
mathog <mathog@...1176...> wrote:
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")?
I think the OP has quite adequately explained the problem:
> 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.1...
http://sourceforge.net/mailarchive/attachment.php?list_name=inkscape-deve...
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
6:04 a.m.
On 06-Nov-2012 11:59, ian_bruce@...2136... wrote:
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.
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."
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.
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.
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?
> 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.
which says
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
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
3795
days inactive
3796
days old
inkscape-devel@lists.inkscape.org
9 comments
4 participants
participants (4)
-
unknown＠example.com -
Jasper van de Gronde -
Jelle -
mathog