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@lists.sourceforge.net wrote:
Send Inkscape-devel mailing list submissions to inkscape-devel@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@lists.sourceforge.net
You can reach the person managing the list at inkscape-devel-owner@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:
- Re: Problem export to png in spanish version (alvinpenner)
- 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@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.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-tp... 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@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-tp... 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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
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.
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.162f...
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
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.
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
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
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.162f...
http://sourceforge.net/mailarchive/attachment.php?list_name=inkscape-devel&a...
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
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.
http://sourceforge.net/mailarchive/forum.php?thread_name=20121104003312.162f...
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
participants (4)
-
unknown＠example.com -
Jasper van de Gronde -
Jelle -
mathog