Extension of the HPGL export filter

this is an excellent addition to the existing hpgl code, thanks for doing this!

I particularly like the extensive tooltips, which are not very common in these Python extensions. Also the response to the case where pySerial is not installed is very graceful, no unexpected crash. (Personally, I wouldn't make pySerial part of the Inkscape package, users should be able to do this by themselves.)

The only concerns I have are about compatibility.
- For example, I think the default orientation angle would have to be 0, not -90, to be compatible with current code.
- the units of the offset at the origin are now mm instead of pixels.
- I believe the direction of movement in response to the origin offset is now the reverse of the original code
- the absolute coordinates of the original drawing appear to have been converted to relative coordinates by calculating the outline of the drawing.

Since I am not an actual user of this extension, I don't know if these changes are desirable or not, perhaps some feedback could be obtained from others, for example on the Inkscape users list.

thanks!

i always hate it when some difficult options don't explain themselves, so i always try to help the user as much as possible when i write a script.

for instance: in the original HPGL extension was an option "x-origin", i thought it was a offset function, but after analysing the code i found out it is used to move the paths into positive dimensions (within the document border), which also requires a negative input and is very confusing.
without this option a drawing could have produced negative values which would result into a corrupted HPGL drawing.
this was nearly impossible for a normal user to understand.

you are right, the compatibility is broken. i accepted this fact because most of the existing features didn't make sense or where difficult to understand.

- the orientation of most of the plotters is vertical to the long side of the plotter, so an orientation of 0° would plot vertical instead of horizontal like the drawing is shown in inkscape.
- the units: one would have to calculate the dimensions one want to use by convert mm (or whatever unit) to inch divided by dpi. i simply do this for the user internally.
- the original parameter was a "origin" instead of the "offset" it is now, so the functionality has changed completely and both features are not comparable.
- the relative coordinates: yes, this was a bit of a gamble, but i figured that most of the users just want to plot a drawing and don't care about the absolute position of the drawing. this could be a bit confusing for hardcore users (which are used to professional software), but it is a tremendous help for first time users. also this feature guarantees that the HPGL data is always in the positive range and the drawing is not too far away from the zero point so no foil is wasted.

do you mean a mailing list with the Inkscape users list? i really have no idea what the "normal" approach is for this request, maybe someone could help me here.

i thank you for your comments, only a critical view on the code and functionality can make a great product.

I re-read some of the previous discussion, in Bug 391923, and discovered to my embarrassment that the offset units you are proposing are the same as what Preben S originally proposed. So I have committed this essentially as is. Made a few cosmetic changes, changed TRUE to true in the .inx file so that the defaults would load correctly.

Thanks for the contribution!

forgot this, committed to rev 12124

i found three bugs and added an improvement, so the code needs to be updated...

bugs:
- sometimes the HPGL data began with a pointless PD (pen down) command (reason: array not reinitialized)
- when the svg data used the "viewBox" attribute the drawing was scaled wrong (reason: viewBox was not processed. took me hours to find -.-)
- the flatness was calculated wrong which resulted in wrong line lengths (reason: the "class" cspsubdiv seems to check if the curve needs to be divided, but it checks a user-delivered value with the length from a point to its handle instead of the length of the bezier curve, which resulted in random line lengths. i replaced the class with my own code which i have integrated)

the bugfixed code is attached.

thanx!

thanks for the update, I will try to look at it this weekend, or at least within the next week.

With respect to the flatness calculation in cspsubdiv, I would recommend against committing or proposing a new version of the code that implements this, unless the code is different in some fundamental way. If there is a deficiency in the existing calculation, then the normal procedure is to submit a separate bug report on this issue, so that it can be evaluated and confirmed and applied to all the calculations that depend on this flattening subroutine.

thanks Alvin.

about cspsubdiv:
the actual behaviour doesn't look like it's unwanted. there is an actual method that is explicitly designed to check for the distance from a point to its handle, and it is within the cspsubdiv.py.
other than that i have no way to determine what was intended since the "class" is not documented in any way.

after a quick search i found my conjecture confirmed: cspsubdiv is only used by flatten.py, and flatten is requesting a unitless number from the user, cspsubdiv is not intended to check for a specific length of some sort, so it is not a deficiency.

i could propose a change to cspsubdiv in terms of a new parameter that enables a check for the real length while preserving compatibility or something like that, but then i have to wait for that proposal to be fulfilled before i can use it to fix my bug.
if you want that just say it and i will do the proposal.

yes, I think it would be best to submit this as a separate bug report. It is not clear to me what the difference is between the method currently used in cspsubdiv and the method that you are proposing. The intent of this routine, I think, is to decide how long each line segment should be. When doing this, the only thing that is relevant is the curvature. If I were designing something like this, I would not use the lengths of the Bezier control arms, nor would I impose a limit on the individual line lengths. What is needed is an estimate of the maximum perpendicular distance from the Bezier arc to a straight line joining the two endpoints. If this cannot be done analytically, then it can be done approximately, by calculating the maximum of the two known perpendicular distances between the Bezier control arms and the line joining the endpoints. Also, there is C code in the main body of Inkscape that does essentially the same job, and it might be worthwhile to find out how that code works.

after consideration i have decided to stick with the length target. there a multiple reasons for it:

- it is easy to achieve
- the existing methods in bezmisc.py are supporting it
- it gives a visual result as good as any other calculation when fine-tuned
- the data overhead in contrast to a calculation depending on angles is rather negligible
- a adaptive algorithm is more diffiícult to operate for the end-user, it would need 2 parameters to handle the dispersion

about cspsubdiv:
to avoid releasing defective code (the original checkin) i ask you to commit the new code as found attached, i will do the other bugreport soon. it will include removing the method from this extension and calling it in cspsubdiv.

I have taken a quick look at the code in the new function divideCurves. If I understand it correctly, then it will produce a sequence of line segments each of whom has essentially the same length. I would strongly recommend against the use of a procedure like this. First of all it is incompatible with what was previously used. Secondly it is inefficient. It will generate too many unnecessary segments in areas where the curvature is low, such as linear segments. And it will generate too few segments in areas of high curvature where a small spacing is needed.
    What is needed is a routine that puts an upper limit on the allowable perpendicular deviation between the approximated line segment and the original curve. This is precisely what the original function cspsubdiv does. It calls the routine ffgeom.distanceToPoint which calls ffgeom.perpDistanceToPoint which calculates the perpendicular distance between the arc and the line using the Bezier control arms as approxinations. I have not gone through the mathematical derivation in detail but I believe this is the intent of this routine. In this context, then, the parameter 'flat' is defined as the upper limit on the allwable deviation between the arc and the line, as expected.

you are right, there is no need to alter cspsubdiv.

new version is attached, please note that the .inx file has changed as well.

fixed a minor bug. i hope it's the last.

thanks, new version committed to rev 12174.

I just made one minor change, to change encoding back to fileencoding in the last line of the .py file. This was done to maintain compatibility with the rest of the Inkscape code. In Inkscape rev 9900 a fairly global change was made to use the terminology fileencoding rather than encoding. Since I know nothing about this issue, I thought it was best to maintain compatibility.

thanx.

i never really understood what that line was for anyway, are there any people actually working with vim?
i really hate vim.

Hi Alvin,

i'm sorry, but a user on my blog suggested a change to fit his old Roland DPX 2000 which uses a coordinate system with a centered zero point.

the change is attached, it is another boolean parameter to fit that type of plotter which is false by default.

the user has already tested with the new parameter activated over the last two days, and i tested today 7 plots without it, so it should be bug-free.

TimeWaster

thanks, committed to rev 12220

@TimeWaster - According to <http://blog.launchpad.net/general/of-bugs-and-statuses> a report is marked Fix Released when " end-users can expect to download or access an updated version of the software that contains the change". In the Inkscape project, we consider it is the case when an official version is released, but not when the patch is committed to the development trunk.

i apologize for the double post [here and time wasters]
i'm using this for engraving plates and need the object to be at the same location as on screen.
if this could be an option to toggle on/off
- the relative coordinates: yes, this was a bit of a gamble, but i figured that most of the users just want to plot a drawing and don't care about the absolute position of the drawing. this could be a bit confusing for hardcore users (which are used to professional software), but it is a tremendous help for first time users. also this feature guarantees that the HPGL data is always in the positive range and the drawing is not too far away from the zero point so no foil is wasted.

my controller is ok with negative numbers.

also option to add manual add commands before and after the in; command.

hi mitch,

your request exceeds the scope of this bug report. (the piece of software described here looks and works different with the newest version in trunk. this report is just not closed because the new major inkscape release isn't out yet)

i will contact you tomorrow about your feature wishes if it is ok with you?

regards,
TimeWaster