Minutes, 26 June 2014 SVG WG telcon



as text below:


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

                               - DRAFT -

                    SVG Working Group Teleconference

26 Jun 2014


      [2] http://lists.w3.org/Archives/Public/public-svg-wg/2014AprJun/0105.html

   See also: [3]IRC log

      [3] http://www.w3.org/2014/06/26-svg-irc


          [IPcaller], ed, heycam, birtles, stakagi, krit,
          Doug_Schepers, Smailus, ChrisL, Tav





     * [4]Topics
         1. [5]Proposal: Remove altGlyph, altGlyphDef,
            altGlyphItem and glyphRef from SVG2
         2. [6]How should the following two SVGPathElement methods
            work when there's no path data?
         3. [7]Filter effects and blend modes for feBlend
     * [8]Summary of Action Items

   <trackbot> Date: 26 June 2014

   <Smailus> who is on the phone

   <scribe> ScribeNick: birtles

   <scribe> Scribe: birtles

Proposal: Remove altGlyph, altGlyphDef, altGlyphItem and glyphRef
from SVG2

   ed: I sent to the mailing list tests which I ran on all the
   different browsers I could find


      [9] http://lists.w3.org/Archives/Public/www-svg/2014Jun/0084.html

   ed: this test was to verify that altGlyph doesn't work on
   normal fonts that are not SVG fonts
   ... I couldn't find any browser that did that
   ... the only browsers that supported altGlyph only did so for
   SVG fonts
   ... so since we're removing SVG fonts it makes sense to remove
   these as well

   heycam: makes sense to me

   ed: if you look at the test itself
   ... I wasn't sure how to reference glyph IDs so I used various
   ... but none of them worked

   heycam: it might have interesting the spec actually said what
   the syntax was for referencing glyphs from different font

   ChrisL: I don't think there is an approved way of pointing into
   a table in a binary font format
   ... that syntax was only ever intended for SVG fonts

   heycam: anyone against removing these from SVG2?


   RESOLUTION: We will remove altGlyph and company from SVG2

   <ChrisL> +1

   Smailus: I agree

   <scribe> ACTION: Erik to remove altGlyph and company ffrom SVG2
   [recorded in

   <trackbot> Created ACTION-3632 - Remove altglyph and company
   from svg2 [on Erik Dahlström - due 2014-07-03].

How should the following two SVGPathElement methods work when there's
no path data?

   ed: I did what we discussed on the last call and posted to the
   mailing list with various options from the browsers


     [11] http://lists.w3.org/Archives/Public/www-svg/2014Jun/0126.html

   ed: I listed a bunch of different proposals
   ... the email thread also had a few more suggestions
   ... for the first one, getPointAtLength, that returns an
   ... one suggestion from Dirk was to return undefined


     [12] http://lists.w3.org/Archives/Public/www-svg/2014Jun/0132.html

   krit: or null? does nullable return undefined or null?

   heycam: returning undefined is a bit difficult from IDL
   ... it doesn't really happen in other APIs, generally we return
   ... I would suggest that over undefined

   ed: would that be stringified to 0... ?

   heycam: I would suggest we change the IDL to SVGPoint? so that
   null can be returned as is

   <krit> null

   ed: so if you're expecting to get an SVGPoint back you'd have
   to check the return value point for

   heycam: sorry, I was referring to the other method
   ... last time I think we discussed the pros and cons of objects
   with NaN members vs returning a null value
   ... if the object has NaN values the code would probably
   continue further but it might make it harder to track down
   problems later
   ... anyone prefer NaN x/y values?

   ed: Dirk suggested in the mail that that might be ok

   <krit> I am fine with null or SVGPoint(NaN, NaN)

   Smailus: I prefer making something clearly an error

   krit: if you search GitHub for these two methods you won't find
   any results except test cases

   <ChrisL> agree, returning a potentially valid value is
   suboptimal (even if a second call can disambiguate it)

   krit: to give you an idea how important they are

   birtles: I slightly lean towards SVGPoint(NaN, NaN) but null
   may be ok too


     [13] https://github.com/search?q=getPointAtLength+extension%3Asvg&type=Code&ref=searchresults

   heycam: Tab mentioned that there's a similarity with
   ... in the end we settled on making getBoundingBox on an empty
   group return rect(0, 0, 0, 0)
   ... but if you called getBoundingBox on a parent of that, that
   0 point wouldn't contribute to the parent's bbox

   Smailus: so that's an argument for returning 0 to keep things

   ChrisL: there's many different things we could be consistent


     [14] http://lists.w3.org/Archives/Public/www-svg/2014Jun/0140.html

   ed: Tab also mentioned that it's not defined if you use an
   distance larger than the lenght of the path

   heycam: and for getPointAtLength you could use a length greater
   than the length of the path
   ... Tab said in that same mail that if you defined what
   happened if you passed in a length that's too large then you
   probably would use the same behavior
   ... I'm inclined for it to be 0,0 if there's no path data

   Smailus: I support that

   <ChrisL> ok

   <ChrisL> ok but we need to include an example of that check, in
   the spec

   heycam: you'd still need to check if there's any path data to
   disambiguate between 0,0 due to no path data or do to actually
   being 0,0

   shepazu: you'd have to add a check either way
   ... whether that be an exception or whatever
   ... but it depends what is common practice these days

   <nikos> for getPointAtLength it makes sense to me to return 0,0
   when there's no path data as that is within the bounding box

   <ed> proposal: if you pass a distance longer than the path ->
   return the last point on the path, if negative/zero distance ->
   return the first point on the path

   shepazu: we should put and issue with the rationale in the spec
   so that when we go to LC we can get feedback on this
   ... we could outline both approaches

   heycam: I'd be happy with an issue
   ... I think WebGL or some other API has a tendency for things
   to go to NaN

   ChrisL: I agree with Doug about putting it in the spec as an
   ... then we can get feedback

   <ChrisL> yes, its fine

   heycam: so for the interim shall we go with 0,0?
   ... plus an issue outline the alternatives and rationale

   RESOLUTION: getPointAtLength will return a 0,0 point if there
   is no path data and we will add an issue about this to the spec

   ed: and when the distance is longer than the path length or
   negative then we use the last point / first point on the path
   as appropriate

   heycam: you clamp the input length value to [0, length of path]

   ed: the second method is getPathSegAtLength
   ... which returns an index to a path segment
   ... that currently returns an unsigned long in the IDL

   krit: Rik would prefer to make it unrestricted double and
   return NaN when there is no path data
   ... I would prefer null

   heycam: what about doing something like getPointAtLength where
   you clamp the value so you either return 0 or the last path

   (someone): agreed

   heycam: krit what do you think?

   krit: how does it compare to getPointAtLength?

   heycam: it's similar in that you clamp the result at the end of
   the existing path
   ... so you clamp to the first / last segment of the path
   ... getPointAtLength clamps to the start / end point of the

   ed: it's only really strange when there is no real first
   segment if you want to be able to distinguish that case

   heycam: but you can look at pathData.length or whatever it is
   to see if there are any actual segments

   ed: yeah, that's fine, I'm ok with that

   heycam: I think the same arguments apply as well where you
   might be doing some calculations and there's some error where
   you've gone just past the end of the path
   ... the calculation shoudn't get corrupted from that

   RESOLUTION: getPointAtLength and getPathSegAtLength with clamp
   their input to be at the start / end of the path appropriate
   and so always return a valid point / path segment index

   <scribe> ACTION: Erik to add text for getPointAtLength and
   getPathSegAtLength to describe behavior when there is not path
   data or when the index/length is beyond the ends of the path
   [recorded in

   <trackbot> Created ACTION-3633 - Add text for getpointatlength
   and getpathsegatlength to describe behavior when there is not
   path data or when the index/length is beyond the ends of the
   path [on Erik Dahlström - due 2014-07-03].

Filter effects and blend modes for feBlend

   krit: I was looking into it in WebKit and it was very easy
   implement all blend modes for feBlend
   ... I also checked with Vlad from Mozilla and he suggested it
   was easy to do with Moz2D / Direct3D
   ... I suggest we add all blend modes to SVG
   ... to unify across canvas/CSS/SVG

   heycam: does canvas use different keywords for blend modes to

   krit: no

   heycam: is this for level 2 of filters?

   krit: no for the current level

   heycam: what is the status of the spec?

   krit: there are still issues about filter regions and it still
   needs detailed review
   ... and the animation part needs cleanup

   heycam: I'm happy with adding the remaining blend modes now

   RESOLUTION: Add all the additional modes specified for the CSS
   property to feBlend

   <krit> [16]http://dev.w3.org/fxtf/compositing-1/#ltblendmodegt

     [16] http://dev.w3.org/fxtf/compositing-1/#ltblendmodegt

   heycam: are these the ones in PDF?

   ChrisL: so long as the equations are in a W3C spec

   heycam: are we adding keywords supported by the property but
   not in SVG? or adding keywords to the property?

   krit: I'm adding hue, saturate etc. etc. which are already on
   the CSS property but not yet supported by feBlend

   heycam: does PDF define additional modes?

   krit: maybe. And Photoshop have more still
   ... but initially we wanted to stick with widely-supported
   blend modes

   <ChrisL> yes

   RRSAgent: make minutes please

Summary of Action Items

   [NEW] ACTION: Erik to add text for getPointAtLength and
   getPathSegAtLength to describe behavior when there is not path
   data or when the index/length is beyond the ends of the path
   [recorded in
   [NEW] ACTION: Erik to remove altGlyph and company ffrom SVG2
   [recorded in

   [End of minutes]

    Minutes formatted by David Booth's [19]scribe.perl version
    1.138 ([20]CVS log)
    $Date: 2014-06-26 13:44:55 $

     [19] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [20] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

   [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11
Check for newer version at [21]http://dev.w3.org/cvsweb/~checkout~/2002/

     [21] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/ffrom/from/
Succeeded: s/ index greater than the number of segments in the path/ dis
tance larger than the lenght of the path/
Succeeded: s/proposa/proposal/
Succeeded: s/actually segments/actual segments/
Succeeded: s/should get corrupted/shoudn't get corrupted/
Succeeded: s/might//
Succeeded: s/all the additional blend modes/all the additional modes spe
cified for the CSS property/
Found ScribeNick: birtles
Found Scribe: birtles
Inferring ScribeNick: birtles
Default Present: [IPcaller], ed, heycam, birtles, stakagi, krit, Doug_Sc
hepers, Smailus, ChrisL, Tav
Present: [IPcaller] ed heycam birtles stakagi krit Doug_Schepers Smailus
 ChrisL Tav

WARNING: Replacing previous Regrets list. (Old list: Rich)
Use 'Regrets+ ... ' if you meant to add people without replacing the lis
such as: <dbooth> Regrets+ Richard

Regrets: Richard
Agenda: [22]http://lists.w3.org/Archives/Public/public-svg-wg/2014AprJun
Found Date: 26 Jun 2014
Guessing minutes URL: [23]http://www.w3.org/2014/06/26-svg-minutes.html
People with action items: erik

     [22] http://lists.w3.org/Archives/Public/public-svg-wg/2014AprJun/0105.html
     [23] http://www.w3.org/2014/06/26-svg-minutes.html

   [End of [24]scribe.perl diagnostic output]

     [24] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

Received on Thursday, 26 June 2014 13:50:27 UTC