Re: Live path effects sample from mountain view f2f

FWIW - PDF does the same thing, where content authoring tools will put
additional "metadata" in the document to enable richer editing.  Such data
can either be document or object-level.

SVG + data* attributes seems like it would enable something similar.  (but
this is also a PERFECT example of why the lack of support for proper
namespacing in HTML5 is a problem in the real world!)

Leonard

On 10/30/11 2:40 AM, "Dirk Schulze" <dirk@dschulze.com> wrote:

>Hello SVG folks,
>
>Live path effects are a good example for the different needs and
>preferences of SVG content creators (the applications) and SVG viewers.
>
>Content creators need detailed information about the objects, applied
>effects and so on. This makes it possible to reproduce the steps that
>were done to make a certain effect possible, to undo, redo them and
>combine them with other effects.
>
>In my opinion SVG viewers don't care that much about these information.
>They don't need to know how an effect was created by an application. The
>viewer just wants to display the content on the display and make it
>accessible to the user. The main target is performance. The content must
>be drawn as fast as possible. That is not necessarily a need of content
>creators. That can be seen in Inkscape with some smaller delays on
>repainting objects when you apply effects to them. And that is ok for
>these applications (partly).
>
>Just as an example what needs to be done for the simple example of Chris:
>1. Parse the path data (first DOM access)
>2. Create the path, apply the stroke style
>3. Create the stroke outline path and make sure that is doesn't contain
>holes by crossing stroke parts. Determine how detailed the stroke path
>must be. Not all graphics libraries provide these features and it must be
>covered by the application itself.
>4. Get information about path effects (search effects on the DOM, more
>DOM accesses)
>5. Create the transformation function for the path effect
>6. Apply transformation function to every element of stroke path
>7. Draw the resulting path on the screen
>
>In comparison to the current result of such an effect created in Inkscape
>for the viewer:
>1. Parse the path data
>2. Create the path, apply the stroke style
>3. Draw the path on the screen
>
>I can understand the needs of content creators. But maybe the way
>Inkscape is doing it is the best way: add more meta data to the SVG file
>how the content was created. The Viewer wouldn't care about these
>information on rendering. The metadata can be archived in an own
>namespace like Inkscape does it. Most of the users (>95%?) don't care
>about how the content was created anyway and web developer can decide to
>remove the meta data of the SVG if they don't want the users to see these
>information.
>
>I could also imagine to create two profiles: One profile for viewers and
>one profile for content creators. This could replace the current profile
>concept tiny, mobile, full, .... The profile for viewers is a smaller
>subset of the profile of content creators. Once content creators and
>viewers agree, a certain feature could be added to the viewer profile as
>well. Or creators use the <switch> element with the modified behavior
>described by Erik Dahlström. The switch could check for a certain feature
>of a viewer (even if it is not specified yet). If the viewer doesn't
>support the feature, the pre-calculated result will get displayed. That
>would make it possible for SVG Viewers to decide for their selfs which
>part of the content creator profile match their own needs.
>
>Greetings,
>Dirk
>
>Am 29.10.2011 um 02:14 schrieb Chris Lilley:
>
>> Hello SVG,
>> 
>> The live path effect plus the original path (inkscape:original-d) are
>>small compared to the eventual path which results.
>> 
>> -- 
>> Chris Lilley   Technical Director, Interaction Domain
>> W3C Graphics Activity Lead, Fonts Activity Lead
>> Co-Chair, W3C Hypertext CG
>> Member, CSS, WebFonts, SVG Working
>>Groups<drawing-inkscape.svg><drawing-svg.svg>
>
>

Received on Sunday, 30 October 2011 19:20:58 UTC