W3C home > Mailing lists > Public > www-svg@w3.org > January 2011

Minutes, 19 January 2011 SVG WG telcon

From: Doug Schepers <schepers@w3.org>
Date: Wed, 19 Jan 2011 16:08:13 -0500
Message-ID: <4D3752BD.3090502@w3.org>
To: www-svg <www-svg@w3.org>
HTML version:

   http://www.w3.org/2011/01/19-svg-minutes.html

Text version:
                    SVG Working Group Teleconference

19 Jan 2011

    [2]Agenda

       [2] 
http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0046.html

    See also: [3]IRC log

       [3] http://www.w3.org/2011/01/19-svg-irc

Attendees

    Present
           ed, heycam, anthony, Doug_Schepers, ChrisL, +39.537.7.aaaa

    Regrets
    Chair
           SV_MEETING_CHAIR

    Scribe
           shepazu

Contents

      * [4]Topics
          1. [5]SVG 1.1 progress
          2. [6]Action-2816?
          3. [7]test suite updates
          4. [8]Test Suite issues
          5. [9]interact-pevents-04-t
          6. [10]conform-viewers-12-f
          7. [11]painting-marker-05
          8. [12]text-align-07
      * [13]Summary of Action Items
      _________________________________________________________

    <trackbot> Date: 19 January 2011

    <ed> Zakim: ??P5 is me

    <scribe> scribe: shepazu

    <scribe> scribenick: shepazu

SVG 1.1 progress

    ed: saw an email sent out, no response from commenters
    ... what's the status on actions?

    <ChrisL> action-2921?

    <trackbot> ACTION-2921 -- Chris Lilley to bring the 1.2 changes for
    bidi and text anchor back to the 1.1 spec -- due 2010-12-16 -- OPEN

    <trackbot> [14]http://www.w3.org/Graphics/SVG/WG/track/actions/2921

      [14] http://www.w3.org/Graphics/SVG/WG/track/actions/2921

    ChrisL: Action-2921 on me is closed

    <ChrisL> close ACTION-2921

    <trackbot> ACTION-2921 Bring the 1.2 changes for bidi and text
    anchor back to the 1.1 spec closed

    <ChrisL> Opera is wrong, if the png images are correct

    ed: I think the PNG images in the spec are not correct on that one,
    will need to be changed
    ... Opera will need to update to the new bidi in the new build
    ... I don't think the test is correct

    <ChrisL>
    [15]http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/002
    0.html

      [15] 
http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0020.html

    <ed>
    [16]http://dev.w3.org/SVG/profiles/1.1F2/publish/images/text/rtl-tex
    t.png is incorrect

      [16] 
http://dev.w3.org/SVG/profiles/1.1F2/publish/images/text/rtl-text.png

    ed: from left to right, it shoudl start with a dot

    <ChrisL>
    [17]http://dev.w3.org/SVG/profiles/1.1F2/publish/images/text/rtl-tex
    t.svg

      [17] 
http://dev.w3.org/SVG/profiles/1.1F2/publish/images/text/rtl-text.svg

    ed: the SVG Tiny spec has the correct image

    <ChrisL> looks correct in FF4

    ed: there are some differences in SVGT and SVG1.1

    ChrisL: in SVGT1.1 we didn't have tspan, and when we added SVGT1.2,
    we neglected to say it applied to tspan

    <ed>
    [18]http://dev.w3.org/SVG/profiles/1.1F2/publish/text.html#TextAncho
    rProperty

      [18] 
http://dev.w3.org/SVG/profiles/1.1F2/publish/text.html#TextAnchorProperty

    ChrisL: I've copied the text back from SVGT to SVG 1.1, does that
    mean the error got repeated?

    ed: no, it's the text-achor part I was concerned with, and that's
    okay

    <ed>
    [19]http://dev.w3.org/SVG/profiles/1.1F2/publish/images/text/rtl-com
    plex.png

      [19] 
http://dev.w3.org/SVG/profiles/1.1F2/publish/images/text/rtl-complex.png

    ed: the next image is also incorrect

    ChrisL: in 1.1, does it only apply to block level?

    <ed> [20]http://www.w3.org/TR/SVGTiny12/examples/rtl-complex.png
    shows the expected result (but like i said i'm not 100% sure it's
    actually a correct 1.1 test)

      [20] http://www.w3.org/TR/SVGTiny12/examples/rtl-complex.png

    heycam: no, each of the chunks can be used to anchor

    <ChrisL> seems like text-anchor should apply only to text content
    block element

    ChrisL: this test only has the one anchor

    heycam: shouldn't the hebrew stuff go rtl?

    <ChrisL> direcion is set to rtl on the root svg and a tspan is set
    to ltr

    <ChrisL>
    [21]http://dev.w3.org/SVG/profiles/1.1F2/publish/images/text/rtl-com
    plex.svg

      [21] 
http://dev.w3.org/SVG/profiles/1.1F2/publish/images/text/rtl-complex.svg

    ChrisL: this example is not sufficiently documented as to what it's
    trying to do
    ... maybe I should as the I18n folks, like r12a, to clarify this
    example

    heycam: example might be good if it had 2 versions of the file
    ... with different outcomes

    <scribe> ACTION: ChrisL to contact Ishida about bidi examples in the
    spec to simplify and clarify [recorded in
    [22]http://www.w3.org/2011/01/19-svg-minutes.html#action01]

    <trackbot> Created ACTION-2925 - Contact Ishida about bidi examples
    in the spec to simplify and clarify [on Chris Lilley - due
    2011-01-26].

Action-2816?

    Action-2816?

    <trackbot> ACTION-2816 -- Anthony Grasso to look into ISSUE-2339 and
    report back -- due 2010-07-13 -- OPEN

    <trackbot> [23]http://www.w3.org/Graphics/SVG/WG/track/actions/2816

      [23] http://www.w3.org/Graphics/SVG/WG/track/actions/2816

    ISSUE-2339?

    <trackbot> ISSUE-2339 -- Last Call Comment: definition of azimuth,
    elevation for feDistantLight -- open

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

      [24] http://www.w3.org/Graphics/SVG/WG/track/issues/2339

    <anthony>
    [25]http://lists.w3.org/Archives/Public/www-svg/2009Jul/0102.html

      [25] http://lists.w3.org/Archives/Public/www-svg/2009Jul/0102.html

    anthony: this was Dr. Olaf's email

    <anthony>
    [26]http://www.w3.org/TR/SVG11/filters.html#feDistantLightElement

      [26] http://www.w3.org/TR/SVG11/filters.html#feDistantLightElement

    anthony: it regards this part of the spec

    <anthony>
    [27]http://commons.wikimedia.org/wiki/File:Azimuth_%28PSF%29.svg

      [27] http://commons.wikimedia.org/wiki/File:Azimuth_%28PSF%29.svg

    anthony: this diagram is useful to understand it
    ... Dr. O points out that our spec is incorrect and a bit unclear

    <anthony> New wording: "Direction angle for the light source on the
    XY plane (clockwise), in degrees [from the X axis]"

    anthony: still figuring out what to write for elevation
    ... I'd like to discuss it with Eric

    heycam: I've been working on this lately, and without other
    implementations to reference, it's hard to figure out the degrees

    anthony: elevation might be a bit more of a headache

    <anthony>
    [28]http://dev.w3.org/SVG/modules/filters/master/SVGFilter.html#feDi
    ffuseLightingElement

      [28] 
http://dev.w3.org/SVG/modules/filters/master/SVGFilter.html#feDiffuseLightingElement

    anthony: our formula for diffuse lighting is related our formula for
    distance lighting
    ... we need change the origin point of the angle for the elevation
    property

    heycam: is it simply not pointing in the right direction?

    anthony: yes, I think that's right

    heycam: I think I've run into this before for a script
    implementation

    anthony: I'll try to have this done by tomorrow

    <anthony>
    [29]http://en.wikipedia.org/wiki/File:Azimuth_%28PSF%29_2.svg

      [29] http://en.wikipedia.org/wiki/File:Azimuth_%28PSF%29_2.svg

    anthony: might be good to have a diagram

    ISSUE-2384?

    <trackbot> ISSUE-2384 -- Order of rx / ry computation for rounded
    rects -- pending review

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

      [30] http://www.w3.org/Graphics/SVG/WG/track/issues/2384

    <scribe> ACTION: ChrisL to edit spec for ISSUE-2384 [recorded in
    [31]http://www.w3.org/2011/01/19-svg-minutes.html#action02]

    <trackbot> Created ACTION-2926 - Edit spec for ISSUE-2384 [on Chris
    Lilley - due 2011-01-26].

    <heycam> ACTION-2926: this is my suggested wording change:
    [32]http://lists.w3.org/Archives/Public/public-svg-wg/2010OctDec/009
    8.html

      [32] 
http://lists.w3.org/Archives/Public/public-svg-wg/2010OctDec/0098.html

    <trackbot> ACTION-2926 Edit spec for ISSUE-2384 notes added

    <ed>
    [33]http://dev.w3.org/SVG/profiles/1.1F2/test/svg/shapes-rect-03-t.s
    vg needs to be updated to align with that

      [33] 
http://dev.w3.org/SVG/profiles/1.1F2/test/svg/shapes-rect-03-t.svg

    <heycam> ACTION-2926: but with this correction:
    [34]http://lists.w3.org/Archives/Public/public-svg-wg/2010OctDec/012
    2.html

      [34] 
http://lists.w3.org/Archives/Public/public-svg-wg/2010OctDec/0122.html

    <trackbot> ACTION-2926 Edit spec for ISSUE-2384 notes added

test suite updates

    <ed>
    [35]http://dev.w3.org/SVG/profiles/1.1F2/test/status/implementation_
    matrix.html

      [35] 
http://dev.w3.org/SVG/profiles/1.1F2/test/status/implementation_matrix.html

    ed: here is an updated implementation matrix
    ... we're down to 43 tests that don't have 2 passes

    ChrisL: and I still have some checking to do

    shepazu: I'm going to see if Dirk could test WebKit

    heycam: I could do some of them

    ChrisL: would it be possible to highlight the ones which don't have
    2 passes?

    heycam: I can make that change to the script

Test Suite issues

    <heycam>
    [36]http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/000
    7.html

      [36] 
http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0007.html

    <ChrisL> animate-elem-81-t

    heycam: animate-elem-81-t seems to be incorrect
    ... the text assumes some particular way transforms are accumulated,
    but it's not clearly specified in the spec, and is different to what
    SVGT1.2 does
    ... the specs don't say, but the tests have different assumptions
    ... Brian Birtles analyzed the differences between the SMIL tests
    and SVG tests, and concluded that the SVGT tests are correct
    ... I've found that there are 3 different ways that implementations
    handle accumulation
    ... for transform animations

    <heycam>
    [37]http://people.mozilla.org/~cmccormack/tests/cumulative-transform
    .svg

      [37] 
http://people.mozilla.org/~cmccormack/tests/cumulative-transform.svg

    heycam: this test shows the 3 different ways, and what each browser
    does
    ... firefox and opera follow what SVGT does, and I think that's
    correct... webkit and batik are different (and incorrect)

    ed: I agree

    ChrisL: yes, and we should clarify this in the spec

    <scribe> ACTION: heycam to make proposed wording for transform
    animation accumulation, and make the tests [recorded in
    [38]http://www.w3.org/2011/01/19-svg-minutes.html#action03]

    <trackbot> Created ACTION-2927 - Make proposed wording for transform
    animation accumulation, and make the tests [on Cameron McCormack -
    due 2011-01-26].

    ed: does this effect other parts of this test?

    heycam: yes, I think so

    ed: the pass criteria on this test are not clear

    heycam: this would make abbra fail, but we would still have 2 passes

    ChrisL: I'm sure Abbra would change their implementation

    <ed> interact-pevents-04-t

interact-pevents-04-t

    <ed>
    [39]http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/000
    3.html

      [39] 
http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0003.html

    ed: the reference image shows space characters, and space characters
    are not supposed to be visible per Unicode

    ChrisL: you've documented it well, we should clarify this in the
    spec
    ... if you provide a glyph, it should not be rendered, but the
    advance should be applied
    ... at least by default... you can have some special cases where the
    glyph can be rendered

    heycam: maybe that would be good to have in WOFF, a way to specify
    that

    shepazu: it would be handy for some proofing cases

    heycam: yeah, when the spaces stretch and so forth

    <scribe> ACTION: ed to add a note to the text chapter to describe
    what happens with space glyphs, and fix interact-pevents-04-t, and
    email the CSS mailing list proposing a way to control visibility of
    space glyphs [recorded in
    [40]http://www.w3.org/2011/01/19-svg-minutes.html#action04]

    <trackbot> Created ACTION-2928 - Add a note to the text chapter to
    describe what happens with space glyphs, and fix
    interact-pevents-04-t, and email the CSS mailing list proposing a
    way to control visibility of space glyphs [on Erik Dahlström - due
    2011-01-26].

conform-viewers-12-f

    ChrisL: I think this is incorrect

    [41]http://www.w3.org/mid/1801756505.20110119200752@w3.org

      [41] http://www.w3.org/mid/1801756505.20110119200752@w3.org

    <ChrisL> And I think the test is wrong, because the data UIR scheme
    allows for a content-type but not a content-encoding; thus the test
    conflicts with

    <ChrisL>
    [42]http://dev.w3.org/SVG/profiles/1.1F2/publish/conform.html#Confor
    mingSVGServers

      [42] 
http://dev.w3.org/SVG/profiles/1.1F2/publish/conform.html#ConformingSVGServers

    ChrisL: this was a big point of contention in the IETF review of the
    svg media type
    ... a dataURI has a mime-type, but not content-encoding
    ... only way to change that would be to change dataURI spec

    <scribe> ACTION: heycam to mark conform-viewers-02-f as unapproved
    [recorded in
    [43]http://www.w3.org/2011/01/19-svg-minutes.html#action05]

    <trackbot> Created ACTION-2929 - Mark conform-viewers-02-f as
    unapproved [on Cameron McCormack - due 2011-01-26].

painting-marker-05

    <ed>
    [44]http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/000
    2.html

      [44] 
http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0002.html

    <ChrisL> abbra fails text-text-05-t.svg (may not do markers at all
    actually)

    <ed>
    [45]http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectAppr
    oved/painting-marker-05-f.html

      [45] 
http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectApproved/painting-marker-05-f.html

    heycam: I think overflow:auto at the moment is the same as visible,
    but to be consistent with CSS, dbaron and ROC would rather it would
    mean the same as hidden

    ChrisL: didn't we give a special value to the root?

    <ed> [46]http://www.w3.org/TR/SVG11/masking.html#OverflowProperty

      [46] http://www.w3.org/TR/SVG11/masking.html#OverflowProperty

    ChrisL: implementations for symbols are different for for different
    browsers for different quadrants

    <ChrisL> in practice markers need to have overflow:visible if the
    marker goes outside the first quadrant

    heycam: overflow:auto in HTML content means there will never be
    content outside the box, which is different from SVG, where it means
    overflow:visible

    ed: strange to me that this is not the default
    ... in Opera, having it visible is less costly than hidden

    heycam: maybe good to talk about at f2f, but need resolution on this
    test

    ed: IE9 gets this right, according to the reference

    heycam: FF can't be changed right away to pass this test

text-align-07

    ed: should this test be skipped?

    <ed>
    [47]http://dev.w3.org/SVG/profiles/1.1F2/test/svg/text-align-07-t.sv
    g

      [47] http://dev.w3.org/SVG/profiles/1.1F2/test/svg/text-align-07-t.svg

    ChrisL: it's not clear to me that there's a requirement to draw the
    missing glyph
    ... sometimes it's a box, sometimes a hex code
    ... for arabic, should it be joined, all sorts of issues

    heycam: my opinion on this keeps changing
    ... I've heard different arguments for how this should be resolved
    ... FF doesn't treat the group baselines as the reference image
    does, but each group is self-consistent
    ... there's some XSL-FO behavior here

    ChrisL: yes, the dominant-baseline

    heycam: it wasn't clear to me what the requirements are from the SVG
    perspective
    ... and I'm also not sure which is preferred, which is more sensible

    <scribe> ACTION: heycam to research clarifications from i18n people
    and mozilla testers [recorded in
    [48]http://www.w3.org/2011/01/19-svg-minutes.html#action06]

    <trackbot> Created ACTION-2930 - Research clarifications from i18n
    people and mozilla testers [on Cameron McCormack - due 2011-01-26].

    ACTION-2930?

    <trackbot> ACTION-2930 -- Cameron McCormack to research
    clarifications from i18n people and mozilla testers -- due
    2011-01-26 -- OPEN

    <trackbot> [49]http://www.w3.org/Graphics/SVG/WG/track/actions/2930

      [49] http://www.w3.org/Graphics/SVG/WG/track/actions/2930

    <anthony>
    [50]http://www.w3.org/Graphics/SVG/WG/wiki/How_to_determine_dominant
    _baseline

      [50] 
http://www.w3.org/Graphics/SVG/WG/wiki/How_to_determine_dominant_baseline

    shepazu: I suggest we not include this test
    ... and clarify it in SVG 2

    trackbot, end telcon

Summary of Action Items

    [NEW] ACTION: ChrisL to contact Ishida about bidi examples in the
    spec to simplify and clarify [recorded in
    [51]http://www.w3.org/2011/01/19-svg-minutes.html#action01]
    [NEW] ACTION: ChrisL to edit spec for ISSUE-2384 [recorded in
    [52]http://www.w3.org/2011/01/19-svg-minutes.html#action02]
    [NEW] ACTION: ed to add a note to the text chapter to describe what
    happens with space glyphs, and fix interact-pevents-04-t, and email
    the CSS mailing list proposing a way to control visibility of space
    glyphs [recorded in
    [53]http://www.w3.org/2011/01/19-svg-minutes.html#action04]
    [NEW] ACTION: heycam to make proposed wording for transform
    animation accumulation, and make the tests [recorded in
    [54]http://www.w3.org/2011/01/19-svg-minutes.html#action03]
    [NEW] ACTION: heycam to mark conform-viewers-02-f as unapproved
    [recorded in
    [55]http://www.w3.org/2011/01/19-svg-minutes.html#action05]
    [NEW] ACTION: heycam to research clarifications from i18n people and
    mozilla testers [recorded in
    [56]http://www.w3.org/2011/01/19-svg-minutes.html#action06]
Received on Wednesday, 19 January 2011 21:09:18 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:47 GMT