RE: Live path effects sample from mountain view f2f

This is also what Illustrator does when it creates SVG files. A problem with this approach is that it significantly increases the file size. Everyone will download these useless bits...
To work around this, people should use the native file format and treat SVG as an export option. Once exported as SVG, you can't go back anymore unless you're willing to lose a lot of data.

With all these new feature requests, we should ask ourselves that if you can do the same with a library, why go through the trouble of extending the language?

Rik

> -----Original Message-----
> From: Leonard Rosenthol [mailto:lrosenth@adobe.com]
> Sent: Sunday, October 30, 2011 12:20 PM
> To: Dirk Schulze; Chris Lilley
> Cc: SVG WG
> Subject: 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 Monday, 31 October 2011 04:05:21 UTC