[CTS 10] Relative coordinates

[PhilterPaper]

When hand-coding large runs of graphical calls, it is easier to think in terms of relative position to the current point, than to add offsets to the current point (to get absolute coordinates). Graphical languages such as SVG offer both absolute and relative coordinates in many places, which is often very convenient.

There are a number of ways this might be done. One would be to offer "relative" versions of path-drawing methods: rarc(), rline(), rellipse(), etc., where all coordinates are relative the the Current Point. The current methods might take an option or optional parameter to declare that coordinates are relative and not absolute. The current methods might accept string coordinates with the number prefixed by R (this would be slower, as string coordinates would each have to be examined, any 'R' removed, converted to a number, and added to the Current Point if it's relative).

A final choice would be to implement a new graphics path method, very similar to SVG's path call. It would be a new language (like SVG's 'd' parameter to path) to do lines, curves, etc., with any mix of absolute and relative coordinates. Something similar might be done to augment text methods, so relative coordinates could be used.

[PhilterPaper]

One of the items on my Builder enhancements list is to implement SVG, in the sense of another image format. This might be a practical answer to this request. That is, rather than implementing a new path-like version of graphics calls, PDF::Builder would implement a large subset of true SVG (it's probably too much to do all of SVG). See CTS 14 #89. This would then be in lieu of enhanced "regular" PDF graphics (arc, circle, spline, etc.).

[PhilterPaper]

I'll still keep this ticket around (though closed), once SVG image handling is released in PDF::Builder 3.027. At some point in the future I may choose to permit any x or y coordinate (in text or graphics) to be a string suffixed with an 'R' to indicate that it's relative to whatever the "current" position is. If you haven't done a translate() or move() yet, the current position is (0,0). This permits arbitrary mixing of absolute and relative coordinates in a universally consistent manner, without having any new methods or formats to remember.

A more remote possibility is to implement a path() method, very much in the vein of SVG's 'd' tag, to define a path with a mix of absolute (capital letter) and relative (lowercase letter) graphics commands. Note that all the coordinates for a given graphics command (e.g., L/l for line) need to be absolute or relative -- no mixing. This still does nothing for text positioning. Would probably want to call standard graphics (and text?) routines from path(), once the absolute/relative coordinates have been translated to absolute coordinates.