- From: ddailey <ddailey@zoominternet.net>
- Date: Sat, 19 Feb 2011 08:59:33 -0500
- To: "Alex Danilo" <alex@abbra.com>
- Cc: <www-svg@w3.org>, <chris@w3.org>, <yan.li@sru.edu>, <yanli@scnu.edu.cn>, <david.dailey@sru.edu>
Thanks to all who responded for shedding light on this. Within Vector Effects, some of it, like veStroke can be handled by <replicate>[1] so that's not so crucial to me. But for cartographers it appears that veUnion, veIntersect, veExclude (like when a lake appears on the border of two countries)and vePath are important . The last one, vePath, so much so that there have been alternative proposals like <superPath> that would actually include orientation information about a path and its subpaths as well for purposes of knowing which subpaths are clockwise or counterclockwise for animating or directionally stroking along the border of a region that shares parts of its boundary with other regions (as with countries), as Jean-Claude Moissinac presented recently [2]. In terms of the broader issues of 1.2, like text flow into shapes and <textArea>, absolutely! There are some very important things there that I'd be tempted to call urgent priorities. While on the topic, but perhaps less urgently, in addition to being able to flow ordinary text (along normal baselines) into a shape, the ability to flow glyphs into differing shapes as their baselines are deformed so that the words Rubber Soul [3] for example would fit into a curvy shape with Rubber being bottom aligned to the same line that Soul is top-aligned to would be essential for certain corporate logos, and other text-art (see more examples of top-aligned text at [4]) . That the geometry of fonts cannot be better controlled and that, for example, the HTML5 logo is being drawn with paths rather than letters, I think, speaks to a crucial shortcoming of SVG as presently implemented. Using shapes to draw letters runs contrary to accessibility, even if we annotate the material with <title> and <desc>. Adding a character-to-path-data function (such as discussed at [4] )would at least allow us to program such things -- which at present I'm not convinced can be done without turning text into pure graphics (and hence undermining its "textiness") -- the placement control of <tspan> is just too limited. cheers David [1] http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2010/replicate.htm (updated Feb. 2011) [2] http://www.svgopen.org/2010/registration.php?section=conference_speakers [3] http://www.misformusic.com/2010/09/tims-pepperland-the-beatles-rubber-soul/ [4] http://srufaculty.sru.edu/david.dailey/svg/top-align.htm [5] http://tech.groups.yahoo.com/group/svg-developers/message/64071 ----- Original Message ----- From: "Alex Danilo" <alex@abbra.com> To: <ddailey@zoominternet.net> Cc: <www-svg@w3.org>; <chris@w3.org>; <yan.li@sru.edu>; <yanli@scnu.edu.cn>; <david.dailey@sru.edu> Sent: Friday, February 18, 2011 4:46 PM Subject: Re: SVG 1.2 Vector Effects > Hi David, > > --Original Message--: >> >>A colleague and I are working on a paper together and have some questions >>about SVG1.2 and, specifically, the vector effects parts: >> >>1. I gather that SVG 1.2 is still a working draft. Will it become a >>recommendation or will the WG just bypass it and move to 2.0? And if so, >>will Vector Effects become a part of that? > > 1.2 was in development for a long time - so long we did debate whether to > rename it 2.0 a > few times. In the course of standardization what progresses is what the > people in the WG > spend time on. So, during that time there were a lot of members interested > in Tiny and so, > a lot of work was done to push Tiny 1.2 forward at the expense of the work > being done > for Full. > > So the WG decided to split out the various features done as part of the > 1.2 work and make > them modules. This is likely to be the approach taken for 2.0 - a core, > with optional extra > modules. Vector effects would be one of them. > >>2. What progress, if any, do we know of browsers or other user agents >>actually implementing Vector Effects? I know that Opera has implemented >>some very important parts of 1.2. Is there any inventory of cross-browser >>progress on the various parts of 1.2? > > Inkscape implemented all the text flow stuff in 1.2 which is really cool, > more so than vectoro effects > since you can wrap text inside arbitrary polygons, etc. Very useful for > flow charts and all sorts > of things. Alas, progress on that part of the spec. has stalled due to > dissenting voices in other > (non) namespaces... > > We implement most of the compositing blend modes for 1.2 as does the Adobe > viewer in > it's own privae namespace (try exporting a burn from Illustrator and check > the output). > We also do the non-scaling vector effect. > > As far as I'm aware no other vector effects ever made it to an > implementation, the original > draft was hopelessly underspecified and a total lack of authoring tools > generating it didn't > motivate anyone to implement. However some effects could be easy and > useful to do, > but there are some like the union/intersection primitives that would be > challenging to > build efficiently and correctly and so, are unlikely to appear very soon > in any viewers > I know of. > >>3. Are there JavaScript implementations available as an API or something >>for doing the various things discussed in Vector Effects? I have a notion >>(albeit fuzzy) that as specs are moved along the path from working draft >>to recommendation, they frequently find some instantiation in actual code >>somewhere. > > There always must be 2 implementations of a feature to prove it can be > built before > reaching Proposed Recommendation. So yes there would be implementations if > it > were to be finished but who know how long that would take! Doing it in JS > is likely > to be painful for the more interesting effects. > > Cheers, > Alex > >>4. A number of the images in the vector effects primer are broken : >>http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffectsPrimer.html . >>Any chance those could be repaired? >> >>regards >> >>David >> >> >> >> >> > > >
Received on Saturday, 19 February 2011 14:00:11 UTC