SVG Working Group Telcon, 9 April 2015

The minutes can be found, nicely formatted, here:
http://www.w3.org/2015/04/09-svg-minutes.html

Pasted below for easy search-ability in the email archives.

------------------------

- DRAFT -

SVG Working Group Teleconference

09 Apr 2015

Agenda

See also: IRC log

Attendees

Present[IPcaller], ed, heycam, AmeliaBR, Rossen, Thomas_Smailus, stakagi,
Tav, birtles, Doug_SchepersRegretsNikosChairCameronScribeAmeliaBR

Contents

Topics

Update on Telcon Time Survey
SVG 2 Open Issues Discussion
more SVG 2 issues

Summary of Action Items

________________________________

<trackbot> Date: 09 April 2015

<heycam>
http://www.w3.org/blog/news/archives/4585?pk_campaign=feed&pk_kwd=three-drafts-published-by-the-svg-working-group

<scribe> Scribenick: AmeliaBR

Update on Telcon Time Survey

Cam: Brian had asked if we could maybe have same day but different time.

Rossen: Thursday works best for us (at MS) Tuesday I have a number of
standard meetings

Cam: Well, I can send out another straw poll and we'll see what people's
availability is.

SVG 2 Open Issues Discussion

Cam: I though we could start with the painting chapter, which I've made
significant changes to

<heycam>
https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assessment#Needing_discussion_10

Cam: Some of these we may have discussed face-to-face, but never got
integrated in the spec
... First is issue 18, re stroke on text. We now have a detailed
implementation instructions on stroking, we may need to define it better
... in particular with respect to stroke dashing. Where do the dashes start?
... I don't think browsers implement this interoperably.

Rossen: This is also one of the issues on our sheet. Our proposal was to
leave it up to the implementation.
... There are different primitive graphics programs that can be used
cross-platform, any sort of restrictions will go against the potential for
optimization.

Cam: To be clear, you want flexibility in the stroking implementation even
for basic shapes like ellipse?

Rossen: Yes, because many of the primitive libraries do not even provide
that information to the web platform. In some cases, basic shapes are
available from the GPU, and this would affect that.
... We should leave this up to implementations. Unless we impose strict
requirements that will invalidate all the potential optimizations, we
cannot force interoperability about where the dashes start.

Tav (?): Are there differences in implementations for basic shapes?

Rossen: In some cases, and especially for text.
... We're 20 years into a web platform with different behaviors for CSS
borders, because of different platform behaviors for rectangles.

Tav: Are there any differences for basic lines and paths?

Bogdan: For lines, there isn't a problem, because there is a clear start
and end.
... What we're talking about is basic shapes -- rectangles, circles,
ellipse -- where they are implemented by the underlying graphics libraries.
There are no guarantees made, today, by implementations as to where the
stroke on those shapes starts.
... We could add normative text here to make it a requirement, but I don't
think implementations will put much effort into making this interoperable.
So then there would be implementation gaps relative to the spec.

Cam: It's interesting the comparison with CSS dashed borders. I wonder how
much we can define this without affecting optimization.

Bogdan: We have no problem about clearly defining the behavior when the
shape is defined by custom points (e.g. path).

Tav: For Inkscape, we draw the basic shapes by implementing them as paths,
so there is no difference.

Bogdan: But that is incredibly inefficient if basic shapes already exist in
the underlying graphics library. You *can* always represent shapes as
paths, but that doesn't work in all cases, for best optimization.
... We could define it as a MAY be done this way, but I would not want it
to be a MUST.

Tav: I think everyone can agree that trying to define the start of dash
patterns on *text* is useless. Basic shapes are still a matter of debate.

Bogdan: I would argue that defining the start of an ellipse is also
useless. If it is important, you can define it with a path with a specific
start path. In that case, the start of dashing would be clearly defined and
you'd go from there.

Tav: We have already resolved on path-equivalent definitions for all the
shapes, for other purposes.

ED: There are certainly use cases. E.g., to stroke some sides of a
rectangle by explicitly setting the dash array. But you need to know where
those dashes start.

Bogdan: But anyone who really needs that control could use a path
themselves.

ED: But why would it be difficult for an implementation to adjust the
offset of the dash pattern to match a defined start point?
... Not for text, we agreed on that, but for basic shapes I think we can
and should define where a stroke starts.

Rossen: As I said before, we could add a specific requirement to the spec,
but I think that would increase the likelihood of non-conforming
implementations, since I don't think implementations will make the
necessary changes.

ED: I don't see this as a major implementation problem. But you're saying
it would be a problem on Windows.

Rossen: I'm saying I'm not sure we won't *not* have a problem

Cam: OK, so we've all agreed that we won't specify it for text. For basic
shapes, the question is *how* much variability is acceptable.

<Smailus> not me... still noisy when I muted

Cam: I think the next step is to do testing to see how much difference
between the implementations currently exists.

<Rossen> there you go

<Smailus> Ed it is.

Cam: I can take the action to test existing implementations on stroke
dashing, or maybe Tav could help?

<scribe> ACTION: Tav to test browser-interoperability with respect to
stroke dashing on basic shapes [recorded inhttp://
www.w3.org/2015/04/09-svg-minutes.html#action01]

<trackbot> Created ACTION-3776 - Test browser-interoperability with respect
to stroke dashing on basic shapes [on Tavmjong Bah - due 2015-04-16].

Tav: Did we settle Issue 18, should dashing still work on text?

AmeliaBR: I think the decision was it should, but with no requirements
about where the dashes start

Tav: I think that makes sense. We (Inkscape) certainly implement it, and
I've seen it in use on the web.

Rossen: Yes, without defining a starting point. That sounds reasonable.

RESOLUTION: Stroke dashing should work as normal on text, but the
specifications will not define the starting point for a dash offset.

Cam: The other issue that I'd like to discuss in this chapter is Issue 25,
with respect to the image-rendering property. Should we require resampling
to be in the linear color space?
... I'm not sure where this issue comes from, or if it makes sense.

Tav: If you *don't* resample in a linear color space, you can get crazy
results sometimes.
... If you upsample or down-sample something, and you're not using a linear
color space, you get the wrong color.

<Tav> http://tavmjong.free.fr/SVG/COLOR_INTERPOLATION/index.html

Bogdan: Can you explain why?

Tav: The above link discusses a lot of the details of color spaces.
... In the sample on upscaling/ downscaling: as you zoom your browser out,
the black and white patterns should match the solid gray below them.

s/below them/on the bottom left/.

scribe: When you average the black and white points, in a linear space you
should get 50% gray. In an sRGB color space, you get the gray on the bottom
right, #bbbbbb instead

Tav: This is why, for filters, the basic color space is linear. The only
reason it isn't the standard for all SVG is because mobile browsers
couldn't do it.

Bogdan: But if implementations can't do it, do we really want to require it?

Tav: We could require it for "high-quality" viewers. But at this point I
would be happy just recommending it.

AmeliaBR: This is in the context of `image-rendering`. Under what value of
that hint property would this apply?

Tav: The new image-rendering CSS spec doesn't have anything to do with
color, it has to do with pixelation and the sampling algorithm you use?

AmeliaBR: Okay, well then are we removing the SVG
optimizeQuality/optimizeSpeed options? Should the color issue be taken up
with CSS?

Tav: I think it is orthogonal. We can still have a recommendation.

RESOLUTION: SVG 2 should recommend but not require that image resampling is
done in a linear color space.

<shepazu> September 23-26

shepazu: Are we likely to have a face to Face as part of the Graphical Web
conference? It's later than usual this year, so it is close to TPAC.

<shepazu> https://www.graphicalweb.org/2015/

<shepazu> September 23-26 2015

<shepazu> Pittsburgh, Pennsylvania, USA

shepazu: in Pittsburg, so it is relatively local for a lot of members
... If there are enough people who will be there, we could have an informal
mini face to face

<shepazu> shepazu, AmeliaBR, Tav, maybe Rossen

<shepazu> please submit talks for Graphical Web

more SVG 2 issues

Rossen: The `hasFeature` method. I'm not sure it has any use.

<birtles> https://dom.spec.whatwg.org/#dom-domimplementation-hasfeature

Rossen: it always returns true.

Cam: I think the DOM spec requires that now.

AmeliaBR: With the exception of the SVG feature strings, since those had
useful implementations based on switch and requiredFeature.

Rossen: But we tried it with new features, like "SVG3", and it always
returned true.

<birtles> https://lists.w3.org/Archives/Public/www-svg/2014Sep/0037.html

AmeliaBR: So, anything other than the feature strings in SVG 1.1 is useless.

shepazu: So, this is basically a broken feature.

Rossen: Can we therefore resolve to remove this appendix?

AmeliaBR: Would that mean deprecating the SVG 1.1 tests, because those
might be currently used.
... Although the only example I can think of doesn't actually use it
correctly.

Cam: Either way, the `hasFeature` belongs in the DOM spec, and this section
was just describing how it worked for SVG.
... I think we can safely just remove it.

RESOLUTION: Remove all wording suggesting that you can use the DOM
`hasFeature` method

Summary of Action Items

[NEW] ACTION: Tav to test browser-interoperability with respect to stroke
dashing on basic shapes [recorded in
http://www.w3.org/2015/04/09-svg-minutes.html#action01]

[End of minutes]
________________________________
Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/04/09 21:39:39 $
________________________________

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]

This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Ed (?)/Tav (?)/
Succeeded: s/Tam/Tav/
WARNING: Bad s/// command: s/below them/on the bottom right/.
Succeeded: s/bottom right/bottom left/
Succeeded: s/in and out/out/
Succeeded: s/ GRaphical Web/ Graphical Web/
Found ScribeNick: AmeliaBR
Inferring Scribes: AmeliaBR
Default Present: [IPcaller], ed, heycam, AmeliaBR, Rossen, Thomas_Smailus,
stakagi, Tav, birtles, Doug_Schepers
Present: [IPcaller] ed heycam AmeliaBR Rossen Thomas_Smailus stakagi Tav
birtles Doug_Schepers
Regrets: Nikos
Agenda: http://lists.w3.org/Archives/Public/www-svg/2015Apr/0007.html
Found Date: 09 Apr 2015
Guessing minutes URL: http://www.w3.org/2015/04/09-svg-minutes.html
People with action items: tav

[End of scribe.perl diagnostic output]