- From: ~:'' ありがとうございました。 <j.chetwynd@btinternet.com>
- Date: Mon, 10 Sep 2007 07:06:43 +0100
- To: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Cc: www-svg@w3.org
Olaf, that really is a very nice example. it's true, I had understood your previous solution, however a novice SVG coder may not. I wasn't certain, however due to the code bulk. the purpose in creating a reduced specification, is similar to tiny. to identify what is essential, and thus help speed development of a variety of 'complete' authoring tools. regards Jonathan Chetwynd Accessibility Consultant on Media Literacy and the Internet On 9 Sep 2007, at 18:19, Dr. Olaf Hoffmann wrote: > Olaf, > > I am grateful for your many attempts to understand the issues I raise. > your solution also appears excellent, though the method isn't clear > to me directly**. Well the idea is very generic and not much related to SVG. A hole is nothing with something around it, not necessarily some substance that was removed from something (as with clip or mask). Now how to do it? First you need a huge 'something' this is a path fragment like M-10000 -10000v20000h20000v-20000z This is a very large rectangled shape, much bigger as the viewBox you want to use. If you add another 'small' path fragment, for example M-100 -100h200v200h-200z you get something with a hole: d=" M-10000 -10000v20000h20000v-20000z M-100 -100h200v200h-200z" Here either you reverse the painting direction as in this case or you can use fill-rule="evenodd" to define, what is inside and what is outside. Doing this, the hole is simply everything outside the shape. Anyway from a philosophical or mathematical point of view, it is always a question of defintion, what is inside and what outside. In SVG this is defined by the fill-rule. Even if one does not understand really, how this is done, I think, the fill-rule works almost intuitively, especially with fill-rule="evenodd". It is in general not really necessary to have two separated path fragments to get a hole, This is possible too, if one path crosses itself somewhere, especially if it is a closed path. > > my concern is whether a child can use SVG authoring tools, unaided. > Tuxpaint, iSketch, msPaint and very many other tools already provide > this facility for raster painting. Ok, thats another interesting thing. But comparing my problems with graphical environment programs with pull down menues and mysterious symbols with the strategies of my young nephews I'm quite optimistic, that they are able to use them by trial and error more effectively than me after one or two hours ;o) > > A child who can use scissors and paper, and understands the GUI icons > and method used to represent this process. > A child has much experience of stretchy substances, and does not > require to understand percentage values. Yes, that is true. With most current computers they only have a keyboard and a pointing device. And even with this limited tools it is already nice, what one can create using such programs with GUIs just dragging around points and adding or removing points and control points, joining paths together etc without knowing anything about the mathematics behind it. > > similarly someone not versed in SVG can understand much by reviewing > code samples. > however, the representation of holes in an SVG document is perhaps > more complex than strictly necessary. > Not sure, the first step is to understand, what a hole is - nothing - then it is quite clear, that you have to care more about the question, what is around the nothing to give it more substance. You cannot change the fact, that the hole is nothing, but you can add other things to pronounce this ;o) Methods using clip or mask 'cut' into something to remove parts of it to create a hole, this is somehow a much more complex process as just to avoid to put something in a place, where you do not want to have it ;o) > the reality that output is frequently accurate to 12 significant > figures, where 3 or maybe 5 would be sufficient, greatly hinders > ready comprehension. Well as you can see, I need only one path (in the example the yellow path) to create an object with a hole. And this is possible too with programs like Inkscape. You need a minimum of two separated path fragments (two M/m commands) or a crossing of the path with itself. > > It's my contention that to define and create such an authoring tool, > an SVG specification has to be designed with this in mind. > The evidence being that there isn't such a tool after a decade. > I know Inkscape a little bit (mostly using potrace to convert raster images to SVG), and this is already a very nice tool. And there are other commercial programs with SVG export. Most of them are designed for several formats, not just one. But I agreee because the intellectual capacities of specification authors, implementors, programmers and document authors are limited, there are unsolved problems related to all of them. I think, it would be a bad idea to reduce the possibilities of a language to the intersection of all these capacities. Then a lot of useful things are excluded, because someone is not able to understand them. In the worst case you get as an intersection an empty set and no one can express anything ;o) > regards > > Jonathan Chetwynd > Accessibility Consultant on Media Literacy and the Internet > > **would a reduced testcase similar to Jeff's help clarify your method? See attachment and explanation above and inside the sample. The green rectangle with a link is at the bottom. If the viewer supports animateMotion, you have to hurry to activate the link related to the green rectangle while parts of it are not covered by the yellow filled and dark blue stroked path. And note what happens, if the fill-rule is switched by the animate element. Could be expanded to a simple declarative game for children or pensioniers or bored mobile phone owners - 'grab the green rectangle if you can' ;o) The other samples are complicated with the need of a circular shape. This results in either the full profile A/a commands or some numeric calculated cubic bezier curves. This is avoided with the simple paths in this sample. <donuts03.svg>
Received on Monday, 10 September 2007 06:06:59 UTC