- From: Rafal Pietrak <rafal@ztk-rp.eu>
- Date: Tue, 15 Jul 2014 20:51:59 +0200
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: www-style list <www-style@w3.org>
W dniu 15.07.2014 19:39, Tab Atkins Jr. pisze: > On Tue, Jul 15, 2014 at 10:25 AM, Rafal Pietrak <rafal@ztk-rp.eu> wrote: >> Isn't it so, that the entire discussion in this thread just means, that svg >> simply misses user-coordinates in addition to current "box coordinates" >> (like user-to-device as in cairographics)? > I think you may have responded to the wrong thread. If I'm wrong, and > you intended to respond to this thread, then I don't understand what > you mean. ^_^ > Yup. It might have sounded like one, but actually it was intended here ;7 If the discussion was along the lines: --> we need a shorthand "transform='translate()'" like "translate:", same for "rotate:", etc. (this is ok by me and is really *not* the reason why I've posted a comment here). --> some of the svg transformation chaining is "error prone", some mistakes people ALWAYS do (me too). --> developers ask for being able to control various transformations independently (yes, pls;). --> your proposal does giver fine-tue control of particular transformations (scaleX, rotate, etc), but at the expense of some "ordering hardwires" (I missed that on my reading, but I get it from comments of others, and if true hardwireing order of nonecomutative operations like transforms is ... problematic) ... then my comment was intended here. What I tried to say is, that all this just adds up to conclusion, that instead of supplementing current svg drawing model with c.a 20 new properties entangled with current transforms, most of the cases could probably be addressed by uniform introduction of (some) local coordinate system. This works for cairographics, could work here. But may be, that's just a too long shot. -R
Received on Tuesday, 15 July 2014 18:52:50 UTC