Re: Extension request: Auto-generate rectangles based on input values

David Mathog <[email protected]> Wed, 05 Jun 2019 09:59:10 -0700
Newsgroups gmane.comp.graphics.inkscape.devel
Message-ID <[email protected]>
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
[email protected]
Manager, Sequence Analysis Facility, Biology Division, Caltech

> 
> Regards
> wiesi
> 
> 
>> David Mathog <[email protected]> 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
>> [email protected]
>> Manager, Sequence Analysis Facility, Biology Division, Caltech
>> 
>> 
>> _______________________________________________
>> Inkscape-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
> 
> 
> _______________________________________________
> Inkscape-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel