W3C home > Mailing lists > Public > public-svg-wg@w3.org > January to March 2009

[minutes] Jan 29, 2009 telcon

From: Doug Schepers <schepers@w3.org>
Date: Sun, 01 Feb 2009 22:11:03 -0700
Message-ID: <49868067.1050706@w3.org>
To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>

Hi, Gang-

The minutes for the SVG WG telcon of Jan 29, 2009 can be found here:


Or as text below:


      [1] http://www.w3.org/

                               - DRAFT -

                   SVG Working Group Teleconference

29 Jan 2009



   See also: [3]IRC log

      [3] http://www.w3.org/2009/01/29-svg-irc


          ed__, heycam, [IPcaller], Shepazu, anthony, Chris




     * [4]Topics
         1. [5]Issue-2007
         2. [6]SVG Full 1.2 scratchspace module
         3. [7]ISSUE-2205
         4. [8]ISSUE-2095
     * [9]Summary of Action Items

   <trackbot> Date: 29 January 2009

   <ChrisL> i'm getting an "engaged" signal when dialing zakim. Anyone
   else having problems?

   <scribe> scribe: Doug

   <scribe> scribeNick: shepazu



   <trackbot> ISSUE-2007 -- 'enable-background' Property Duplicated in
   Compositing and Filters Modules -- RAISED

   <trackbot> [10]http://www.w3.org/Graphics/SVG/WG/track/issues/2007

     [10] http://www.w3.org/Graphics/SVG/WG/track/issues/2007



   anthony: I ran across this while doing my actions regarding the
   compositing module
   ... seems like there's an incompatibility
   ... I'm looking into whether there is an incompatibility
   ... the original compositing module from SVG Full 1.2 followed the
   Adobe model, so that might be the reason
   ... I'll confirm this by next week

   ed: so, is the wording in your module different than that in 1.2
   Full, or is it only with filters?

   anthony: no, it's close to what was in Full 1.2
   ... I did take the wording closely from the filters module
   ... so the incompatibility arises between compositing and filtering
   ... when you composite in filters using feComposite, it ends up
   compositing the background twice, whereas with compositing module,
   it just writes it to a buffer
   ... that is, all the child elements you composite
   ... the example shows the differences quite clearly
   ... and there are differences between "accumulate" and "new"

   shepazu: is it possible to use both values, and maybe use an
   attribute value to switch between them?

   ed: we could have 2 behaviors, because it's used in different
   contexts, but do we want that?
   ... in filters, it's only used when you have @enable-background

   <ed__> and only when the keyword BackgroundImage is used in the

   <ed__> and BackgroundAlpha

   anthony: also, in the compositing module, I do talk about access to
   the background
   ... we can talk about this at the f2f
   ... for printing, it may be necessary to keep the Compositing module
   as it is

   ed: you would get something drawn if you used enablebackground on
   the root and didn't use any CompOps, right?

   anthony: yes, it is technically an error if you don't have a

   ed: yes, let's talk about it at the F2F... I can add that to the
   agenda page
   ... there is the question of how much content would change if we
   changed filters

   anthony: I am not convinced that we would need to change the
   behavior of filters

   ed: so you're recommending that we keep both behaviors

   anthony: yes, if that's possible... maybe we could change names of
   the attributes, to make a distinction



   anthony: I did make some of the changes Erik requested
   ... I added in the greater-than/less-than for the optional
   x/y/width/height values
   ... and added a definition for them as well
   ... should we hold off publication, or go ahead?

   shepazu: how about we wait until after the f2f

SVG Full 1.2 scratchspace module

   ed: I think it might be good to at least start the framework for the
   next major spec
   ... something that brings in Tiny with the Modules
   ... some of the stuff is best not done in modules, such as cleaning
   up the SVG DOM

   heycam: animation doesn't correspond to a module, either



   shepazu: this is from mozilla's review of widgets
   ... the basic issue is around different use profiles


     [14] http://www.schepers.cc/svg/blendups/embedding.html

   shepazu: I don't talk there about multimedia, but that's another
   issue (audio, video)

   heycam: what's the purpose of this scratchspace?
   ... is it all the stuff that doesn't fit in a module, along with how
   to integrate the modules together?

   ed: yes, we do need to start someplace to put all that

   shepazu: I think we can just start this spec, and decide later
   exactly how we are going to put the next spec together

   ed: I don't think most of the raised issues would fit in an
   established module
   ... we can at least start the work in this scratch module
   ... we can split parts out later, if we decide that's best
   ... we could all be editors

   shepazu: yeah, I'm happy to start it and add some structure
   ... I'd like the featurestrings to be derived automatically from the

   <scribe> ACTION: shepazu to start core/scratch module [recorded in

   <trackbot> Created ACTION-2426 - Start core/scratch module [on Doug
   Schepers - due 2009-02-05].



   <trackbot> ISSUE-2205 -- Consider adding support for stretched,
   wrapped text in a <textArea> -- RAISED

   <trackbot> [16]http://www.w3.org/Graphics/SVG/WG/track/issues/2205

     [16] http://www.w3.org/Graphics/SVG/WG/track/issues/2205

   shepazu: this is interesting... it's quite different than justifying

   ed: it's similar to SVG 1.1's length-adjust

   heycam: yes, but that doesn't change the font size

   <ed__> lengthAdjust = "spacing|spacingAndGlyphs"

   <ed__> [17]http://www.w3.org/TR/SVG11/text.html#TextElement

     [17] http://www.w3.org/TR/SVG11/text.html#TextElement

   lengthAdjust = "spacing|spacingAndGlyphs|fontSize" ?

   heycam: could be good

   shepazu: this is related (in a way) to sizing text to fit a box, and
   vice versa
   ... in the case where you have fixed width, it would determine the
   chunk size, and then adjust the font size accordingly, unlike your
   example, where you've pre-chunked it

   heycam: it would be less dramatic in that case
   ... in my example, I had to set width to auto, but it should be the
   hardcoded value of 360



   <trackbot> ISSUE-2095 -- Algorithm for soft-light blend mode --

   <trackbot> [18]http://www.w3.org/Graphics/SVG/WG/track/issues/2095

     [18] http://www.w3.org/Graphics/SVG/WG/track/issues/2095



   ed: this is for the compositing module



   ed: this email has the algorithms
   ... is there any reason to differ from PDF?

   anthony: if we're going to follow the Adobe compositing model, then
   it make sense what's in the ISO PDF spec

   Resolution: we will use the algorithms for the soft-light Color
   Dodge and Color Burn in the compositing module

   <scribe> ACTION: anthony to use the formulae from ISSUE-2095 to
   update the Compositing module [recorded in

   <trackbot> Created ACTION-2427 - Use the formulae from ISSUE-2095 to
   update the Compositing module [on Anthony Grasso - due 2009-02-05].

   trackbot, end telcon

Summary of Action Items

   [NEW] ACTION: anthony to use the formulae from ISSUE-2095 to update
   the Compositing module [recorded in
   [NEW] ACTION: shepazu to start core/scratch module [recorded in

   [End of minutes]
Received on Monday, 2 February 2009 05:11:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:29:41 UTC