Re: Generalizing the utility of refx and refy by using their inverse, dx and dy

Hi Ryan,

> On 25 May 2016, at 1:41 PM, Ryan Pettigrew <tenacious_techhunter@verizon.net> wrote:
>
> Generalizing the utility of refx and refy by using their inverse, dx and dy:
>
> Allowing authors to precisely define an arbitrary point relative to which their content is drawn can be very useful. Consider a face-on drawing of an archery target, and a drawing of an arrow as seen along the length from the feathered end. The author uses a viewbox to make the child elements that compose his archery target center on the coordinates x="0" and y="0". The author then draws his arrow in a child element in the same way, so he can reuse the work to place multiple arrows. At this point, the author might naively try giving the child element that composes his arrow coordinates of x="0" and y="0", and expecting it to hit the bullseye; but, instead, the arrow is placed below and to the right by the dimensions of whatever arbitrary artistic decisions he made in constructing the arrow...
>
> Now, the solution to this problem that current experienced svg authors may find obvious is to make sure the viewbox of the element containing the arrow is centered, find the width and height of the element, divide both of those numbers by 2, and then subtract the respective results from the x and y coordinates the arrow is to be placed at. However, this introduces a number of problems...
>
> Firstly, that subtraction must now be done for each and every added arrow... Additionally, suppose that the width and height are not some conveniently divisible number; this would require repeatedly subtracting a series of precise digits... In this case, the limits of SVG are making a mess of things.
>
> A way out is certainly hinted at by the marker element, which solves this problem with the refx and refy attributes, by indicating the point to be centered upon the specified coordinate. However, trying to generalize this implementation introduces problems of its own. If x and y are to remain the absolute location, and refx and refy to be the relative location, then refx and refy would have to refer to the initial coordinate for specifying the extent of the drawing, from which the width and height are applied; that is not how they are used in marker elements. Making refx and refy the absolute locations also violates the implicit status of x and y being the absolute locations.
>
> Better still are dx and dy as found in the text and tspan elements. Here, they shift the text relative to the absolute coordinates defined by x and y. They are valued at exactly the negative of refx and refy, are likely to be better known, and defaulting dx and dy as dx="0" dy="0" results in no required change to how existing content is interpreted. A case for consistency could be made that refx and refy should be deprecated in favor of dx and dy in marker elements.
>
> Coming back to our beleaguered author to see how these changes play out, he centers his viewbox within the arrow’s element, calculates the values for his subtractions, and puts those values in dx and dy to center the arrow on the bullseye. A few short use elements later, he now has his intended arrow-riddled target. He also finds that he can center any content relative to any point he finds convenient; for instance, the eye of a certain tiger.

This is definitely a use case that the working group should tackle once SVG 2 is published.
I’ve created a GitHub issue on your behalf: https://github.com/w3c/svgwg/issues/146

When I find some time to think about this I’ll comment there.

Thanks,
Nikos.



The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.

Received on Wednesday, 25 May 2016 06:43:11 UTC