SVG Working Group Teleconference -- 09 Apr 2015

<trackbot> Date: 09 April 2015

zakim ??P7 is me

<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 in http://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

- DRAFT -

SVG Working Group Teleconference

09 Apr 2015

Attendees

Contents

Update on Telcon Time Survey

SVG 2 Open Issues Discussion

more SVG 2 issues

Summary of Action Items

Scribe.perl diagnostic output