Re: [1.2T-LC] inverse and constrained transformations (ISSUE-2073)

Hello,

about the last changes on this issue in the current version of the
editors draft:


1)
Now it is noted:
"Note that the inverse of the CTM may not always exist. If the CTM is 
non-invertible, then rendering of the element is disabled. The 'ref(...)' 
value in this case is not an unsupported value."

If we consider the main idea of the constrained transformation,
as far as I understand this, it is, that the element with such a 
transform value ref(...) is not transformed at all and not that
the display is disabled.
I cannot see, that this disabling provides any functionality related
to a constrained transformation or something useful for authors
at all.

The problem with the missing or undefined inverse seems to me
more a symptom, that the idea to use the inverse at all to get
the desired effect is not well thought out. Apart from the problem
with the missing inverse it might be quite time consuming for the
viewer too (Additionally the current wording leaves it open
anyway, what happens, if the inverse does not exist, what can
happen for some stupid skewing angles, therefore it does not
even avoid all problems for less clever implementations).  
However as already mentioned in previous responses, Opera 
manages this constrained transformation even if there is no
inverse at all, clearly indicating, that there is a much better 
thought out method to get the desired effect.
Maybe we cannot expect currently, that all implementations
are changed now (even if Opera explains, what they did to
solve the problem) , but already better implementations 
should not be frustrated either.

The current changes mainly force more clever implementors
to care about or to simulate problems, they do not have at
all. And if they do not need to calculate the inverse at all,
for them it is unneccessary computation, to check, whether
the rendering has to be disabled or not. 
Both for clever implementors and authors the current 
requirement to disable rendering is very contraproductive.
Implementors are frustrated to look for a better, more
effective method (which could be maybe specified in 
SVG 1.2 full) and authors are frustrated to use constrained
transformation (combined with animation), because 
typically it will not be the intention, that the rendering is 
disabled at all.

Therefore I suggest to remove the requirement to disable
rendering, if the inverse does not exist, as in the previous
wording, which can be improved maybe, but better not
with constrains on the functionality or with a requirement
to change the behaviour of viewers already managing the
problem without any trouble.


2)
In '7.6.1 The TransformList value' now appears something
similar contraproductive. It is noted:

"If the list of transforms includes a matrix with all values set to zero (that 
is, 'matrix(0,0,0,0,0,0)'), or any other non-invertible matrix (such 
as 'matrix(0,0,0,0,50,50)' or 'scale(1,0)'), then rendering of the element is 
disabled. Such a value is not an unsupported value."

Previously it was noted:
"If the list of transforms includes a matrix with all values set to zero (that 
is, matrix(0,0,0,0,0,0)) then rendering of the element is disabled. Such a 
value is not an unsupported value."


Finally with vector-effect non-scaling-stroke it became a simple
method available to use and to see objects with reduced 
dimensionality. To get similar effects and functionalities in
SVG 1.1, this requires clipping, masking, filtering, not available
at all in SVGT1.2. 
Therefore it is disappointing that this possibility or functionality
is now removed in a very late phase of the SVGT1.2 drafts without 
any reasoning.

My suggestion is, that these possibilities are not excluded, 
that authors can use this in combination with vector-effect 
non-scaling-stroke to get some tricky functionality (as already
indicated in previous responses about this issue), else not
available in SVGT1.2 at all.
In previous drafts only 'matrix(0,0,0,0,0,0)' indicated a disabled
rendering. I think this is enough to provide this functionality, if
an author for example wants to start a none additive 
animateTransform for an initially disabled element. There is
no more benefit for authors with other notations to indicate
a disabled rendering by transformation, I can see. And even
if this is left out completely as in SVG1.1, author still can
use the display property to remove undesired objects in a
more effective and direct way as to use transformations for
this purpose.


Olaf

Received on Thursday, 30 October 2008 15:05:38 UTC