- From: Rik Cabanier <cabanier@gmail.com>
- Date: Wed, 19 Nov 2014 09:01:32 -0800
- To: Juergen Roethig <roethig@dhbw-karlsruhe.de>
- Cc: "www-svg@w3.org" <www-svg@w3.org>
- Message-ID: <CAGN7qDB07VipO2-jPRG1ta+mYAWO6aktLXYQJRr6sWyP1eYhzQ@mail.gmail.com>
Hi Juerge,
I'm unsure what you're trying to achieve with such a response.
Maybe you can try again but without the ad-hominem attacks?
regards,
Rik
On Wed, Nov 19, 2014 at 6:26 AM, Juergen Roethig <roethig@dhbw-karlsruhe.de>
wrote:
> Hello,
>
> premark: Although I assume that the question was _not_ serious (see
> later), I will give a serious answer ...
>
> Rik Cabanier wrote:
>
>>
>>
>> On Sun, Nov 16, 2014 at 10:52 PM, Juergen Roethig <
>> roethig@dhbw-karlsruhe.de <mailto:roethig@dhbw-karlsruhe.de>> wrote:
>>
>> Rik Cabanier wrote:
>>
>>
>>
>> On Sun, Nov 16, 2014 at 12:43 AM, Juergen Roethig
>> <roethig@dhbw-karlsruhe.de <mailto:roethig@dhbw-karlsruhe.de>
>> <mailto:roethig@dhbw-__karlsruhe.de
>>
>> <mailto:roethig@dhbw-karlsruhe.de>>> wrote:
>>
>> Steve Schafer wrote:
>>
>> On Sat, 15 Nov 2014 19:37:35 +0100, you wrote:
>>
>> You really want to tell me that the SVG WG does not
>> even
>> want to consider non-affine transformations for SVG
>> because
>> it might take more computational power than "simple
>> matrix
>> math"?
>>
>>
>> Not just more computational power, but more expressive
>> power.
>> The space
>> of "non-affine transformations" is effectively infinite.
>> Are you
>> willing
>> to limit that to some subset (e.g., projective
>> geometry)? Or do
>> you want
>> everything? The more you encompass, the more your means of
>> expressing a
>> transformation begins to look like a general-purpose
>> programming
>> language. There's no point in reinventing JavaScript
>> within
>> SVG--it's
>> already there.
>>
>>
>> I do not want "everything" out of "infinity", for sure! If
>> transformations other than affine ones had been discussed
>> before in
>> the SVG WG, coming to some sort of conclusion, I will see
>> what to
>> make out of it. Unfortunately, the specs (the existing 1.1
>> as well
>> as the upcoming 2) as well as my Google search on the topic
>> (probably using the wrong keywords) don't reflect such a
>> discussion.
>> That's why I ask what might have been discussed before!
>>
>>
>> Can you give an example of what such non-affine transformations
>> look like? Do you know of any tools that offer them?
>> Of course, "projective geometry" might be a
>> candidate for such a
>> class of transformations, especially with regard to the
>> z-index
>> which hopefully makes it in SVG2!
>>
>>
>> I don't understand why z-index is special. Can you eleborate?
>>
>>
>> An example of such a non-affine transformation might be the
>> one-point perspective
>> (http://en.wikipedia.org/wiki/__Perspective_projection#One-_
>> _point_perspective
>> <http://en.wikipedia.org/wiki/Perspective_projection#One-
>> point_perspective>).
>> This is some sort of projection of a point in a three-dimensional
>> coordinate system to a point in a two-dimensional coordinate system
>> (i.e. a plane). Why I would need z-index is obvious ... although I
>> know that z-index in SVG2 is currently defined as an index just
>> controlling the rendering order, it might also be regarded as the
>> third (missing) dimension, although with somewhat restricted
>> accuracy (since it is an integer value).
>>
>>
>> I didn't hear anyone propose to repurpose z-index as an actual dimension.
>> You will find a lot of resistance to change this common HTML/CSS property.
>>
>
> I do not propose to change it to be a dimension (with units such as px,
> mm, in, whatever)! I might just use the z-index not just in a qualitative
> ("if a>b, then a is in front of b"), but also in a quantitative way! There
> is no reason (from the spec) not to do so (besides the limited accuracy,
> since it is integer, but if I can live with that, why not ...). But it was
> just an example of how to achieve some missing information needed for a
> perspective view, and not part of any proposal!
>
> Other examples of non-affine transformations are all sorts of map
>> projections (http://en.wikipedia.org/wiki/__Map_projection
>> <http://en.wikipedia.org/wiki/Map_projection>) which neither need a
>> third dimesion (the z-index) nor are probably among the first
>> candidates for transformations to be implemented in SVG since they
>> might be somewhat too special.
>>
>>
>> If you could do this with excellent performance using a JS libary, would
>> that be acceptable?
>>
>
> We are not talking about JS libraries (which already exist for that
> purpose, for sure), but we are talking about native SVG (including JS
> interfaces to the SVG DOM) on this list! Although you can do all sorts of
> affine transformations via JavaScript, there is also a way to perform such
> transformations via pure SVG! And what I would do if a feature is not built
> in a language which I might use, that's not the question. But nevertheless,
> my reaction when some language does not offer a feature, but just via some
> library, might vary from "use the library", or "do not achieve the desired
> result", up to "do not use the language at all, but look for another one".
> It depends.
>
> Tools supporting such transformations/projections? The former should
>> be supported by all sort of tools which allow perspective views of
>> three-dimensional (virtual) worlds, and the latter might be a case
>> of special cartographic tools.
>>
>>
>> Can you give an example? I'm not familiar with any of such tools and
>> would like to see how they work.
>> It's likely that I'm not the only one.
>>
>
> And that's why I doubt the seriousity of the question: When I feed Google
> with "tools with support for perspective transform", the first two hits are
> links to help pages from Adobe about their software products "Adobe
> Illustrator" and "Adobe Photoshop"! I do not assume that someone who is
> "Senior Computer Scientist on Adobe's Web Standards team" does not know
> some of the key products of his own company. But if you really do neither
> know and nor want to use those tools, you might even use GIMP to achieve
> some sort of "perspective transformation", i.e. some non-affine
> transformation in a 2D context. BTW: This is obviously performed via a
> transformation matrix (which can be examined when you try the tool with
> GIMP) - so the argument from the first answer by Tab Atkins Jr. "Affine
> transforms are fast and easy to do on modern graphics hardware with simple
> matrix math. Non-affine transforms don't have this property,
> unfortunately." does not hold, obviously, for that sort of transformations
> which are not affine but realized via "simple matrix math".
>
> Juergen Roethig
>
Received on Wednesday, 19 November 2014 17:02:00 UTC