On 04-Jun-2019 23:21, wiesi--- via Inkscape-devel wrote:
The question is also, if we would want this for interactive entry,
Probably not. I cannot think of a use case for preexisting data where it would not be better to format it first rather than type it in. Especially because the data might already be in some form of text file which could be rapidly converted to input format with various sorts of batch edit commands (ie, select range, substitute in a certain way)
batch processing or processing the output of other tools
These are the same aren't they? Unless by the latter you mean have it hook such output directly from Inkscape without saving the intermediary file.
: It is usually rather easy (but nevertheless some work) to create an external tool to convert such a list to SVG. For my own tools that generate graphics files I usually end up outputting SVG files (or parts of them) directly, because outputting, for example,
<line x1="45.6" y1="23" x2="-15" y2="8" />
Because SVG is SGML like specifying rotation angles and formatting gets complicated in a hurry.
is not much more complicated than
moveto 45.6, 23 lineto -15, 8
A variant of that uses "angle" operators. Those effectively shift the rotation in the current transformation matrix but are easy for people to understand because it is just like using a protractor and a ruler (the ancient Greeks would get it) and they don't have to do the math to get pairs of coordinates from a set of measured lengths, the input program does it. I don't recall where I saw that idea but it isn't mine. This method simplifies the conversion of many sorts of measurements to graphics coordinates because moveto/lineto/etc. take fewer parameters. This:
origin # equivalent to moveto 0,0 degree_angle 45 moveto1 100 #in this context, same as moveto 70.7 70.7 # draw an object, typically much more complicated than this one deg_angle 0 # absolute angle set in degrees #start # optional mark for later "close" line1 5 # start x,y, angle, length define 2nd point's coordinates inc_deg_angle 90 #0 + 90 = 90 line1 5 inc_deg_angle 90 #90 + 90 = 180 line1 5 inc_deg_angle 90 #180 + 90 = 270 line1 5 #line_close #use instead of preceding if start was used square_ll 10 #use current angle, starts at lower left corner
draws a square of side 5 counter clockwise (assuming origin 0,0 is at lower left corner, other standards are possible) and then a square of side 10 below it.
The place where all of this goes wrong, in terms of CAD, is when the input data (measurements or calculations) are slightly off and the path isn't trivial like a square. Surely we have all been there, measure around a building with a complex outer path and that path doesn't quite close because of accumulated errors. (In the example above maybe the lengths were 5.01, 5.02, 4.99, 5.00). That is where start/close can be helpful, it allows a "fix this" function to be called automatically. There are many such functions (assume angles are correct, assume lengths are correct, assume both may have errors, etc. etc. etc.). It should also throw an error on a really extreme error, as these are common when writing down data, like "5" when it should be ".5".
Rather than reinventing the wheel I still think adopting some existing standard for this sort of input is the simplest way to go. It can be extended with "fix this" functions if it supports some variant of start/close.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
Regards wiesi
David Mathog <mathog@...1176...> hat am 5. Juni 2019 um 03:49 geschrieben:
On 04-Jun-2019 18:11, brynn wrote:
If "Inkscape is not a CAD program" is not an appropriate answer, I would welcome suggestions how to answer messages like this:
"Inkscape is a terrible CAD program. Where do I enter the length and angle of the line? How can I draw a line if I can't enter the length and angle?"
(substitute radius/diameter/circumference, etc, for a circle; or dimensions for rectangle)
Well, this probably isn't what the target audience would want to hear, but since it sounds like the questioner might have a set of simple elements with known sizes, locations, and orientations derived from who knows what (actual measurements, some abstract calculation?), it isn't unreasonable to ask if there might be a way to provide a quick and easy conversion of that data to a drawing through Inkscape.
For instance, if the user could write their data as a text file made of simple declarative 1 line statements like:
moveto,x,y lineto,x,y ray,x,y,length,angle ray2,x1,y1,x2,y2 square,x,y,side,angle #x,y is center square2,x,y,side,angle #x,y is lower left corner rectangle,x,y,width,height,angle #x,y is center rectangle2,x,y,width,height,angle #x,y is lower left corner circle,x,y,radius ellipse,x,y,radiusA,radiusB,angle ellipse2,x,y,radius,eval,angle text,x,y,points,font,angle,text_string draw_color,color_name draw_color_rgb,R,G,B fill_color,color_name fill_color_rgb,R,G,B draw_width,width (etc.) quit
it would not be hard to write a converter to read that and write it out again as SVG, either to a file or imported directly into Inkscape.
Yes, this duplicates features of many other graphics languages, from cgm to hpgl to postscript. So it might be best to pick the text form of one of those standards and write an importer for it. (Not postscript though, that is Reverse Polish, too bizarre for the average user.) For all I know there may already be an import option which works like this. If so, point said user to it and say "have at it".
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel