<AmeliaBR> present_ myles

<chris> https://www.w3.org/2004/01/pp-impl/19480/status

<chris> joining form https://www.w3.org/2004/01/pp-impl/19480/join

Everybody please make sure you're rejoined in the New and Improved SVG Working Group!

<krit> ScribeNick: myles

krit: Anything else we need to take care of, chris?

chris: We have 45 days to rejoin before you're thrown out.

krit: We can go to the next topic then

[css-masking-1] stroke-bounding-box and non-scaling-stroke

GitHub: https://github.com/w3c/fxtf-drafts/issues/279

krit: We have the stroke bounding box and for various limitations in implementations and difficulties in rendering, masking is having some heuristics for the bounding box. These heuristics don't say anything about the non scaling stroke property. In some cases it makes it smaller, and in some bigger.
... So what happens? Does it affect the bounding box?

chris: It should take it into account. CSS masking allows SVG to override it, so this affects CSS. There's a question about dashing - it takes dashing into account, then the stroke bounding box will change depending on dashing, and the bounding box can change on every iteration from, so it should take all the largest possible stroke that could be painted, and it may not be the tightest box

krit: WebKit does use tight stroke bounding box at the moment.

chris: It does the tight boudning box including the dashing?

krit: yes

chris: That's correct. It's probably easier for implementors too

krit: It's expensive to compute.
... However, the difficulty is the differences between the implementations depending on how they compute it.
... That's why we need heuristics in the first place.

chris: Is that about miter limits?

krit: yes, mostly.
... I did a patch for WebKit to include it. It is possible to compute it correctly and include it into the heuristic. It can be done. I can put it in the spec.

chris: I don't think it affects very much. You work out what the width really is, and then proceed.

AmeliaBR: It becomes an issue if you have weird transforms. In the coordinate system for the shape, your stroke that is an even width line on the screen, it isn't even in the unevenly scaled coordinate system.

myles: You would implement it by computing it and passing it through a transform.

AmeliaBR: Yes. Figure out what the shape should be in the screen coordinate system, and stroke it there. But bbox needs to be in local coordinate system. So it needs to round-trip

krit: AmeliaBR, myles, should we integrate it?

AmeliaBR: Either make it really simple or really accurate. I don't like CSS masking because it's in-between. It has weird extra heuristics that complicate things that gives you weird results that aren't what you want. Let's keep it really simple that are the fill bounding box padded by half the stroke width, or let's be accurate.

krit: What about miter?

AmeliaBR: In CSS masking, you get a different stroke bounding box for a rectangle and for a polygon with the same corners as the rectange. That's unfortunate.

krit: We can make it consistent ... <missed>

AmeliaBR: The heuristic assumes there might be a sharp corner, but there might not be. They're rough approximations.

krit: I uploaded an image that the heuristic can be wrong, depending on the miter limit.

myles: what do authors want?

krit: Heuristics are for giving the same experience in every browser.

chris: The other thing is that the bbox should include all the stroke. If it includes more, that's probably okay
... but if it includes less, then that's worse.
... you typically want to apply a filter to that region or use that region for pointer events. If you missing some, that's visually intrusive.

myles: given we're already passing these paths through transforms, we should probably just do the right thing

krit: What is the "correct thing"? The tight stroke box without dashing?

myles: no opinion
... (about dashing)

krit: You want it to entirely contain, but in some examples, the heuristic can do bad things

AmeliaBR: My main concern is that you can end up changing the bounding box by changing a shape to a path. If we can address that, so we leave room for those miter corners even on a circle that never has miter corners, that would address the issue. I don't like the idea of convering a shape to a path and the bbox changes and now your effects are no longer aligned.

krit: So, you would rather prefer to have the red box than the correct one for non-rects and symbols?

AmeliaBR: yes
... It's better to be overly generous. The main reason in the first place is authoring complaints that the default bounding box doesn't include the stroke (it's too small)

krit: Do people agree?
... chris?

chris: I'm fine with that.

krit: proposed resolution: Don't include non-scaling stroke in the bounding box
... proposed resolution: use the same heuristic regardless of what shape it is
... Let's start with the second one. Then we can do the first one and see if we can work out how to do it

AmeliaBR: Try to see if we can come up with a reasonable heuristic for incorporating non-scaling stroke
... Proposed resolution: Use the same heuristic as CSS masking, but modify it to make it apply equally to all shapes, and modify it to incorporate non-scaling stroke

chris: and if we can't?

AmeliaBR: If we can't do anything useful, do nothing

chris: If we can't, we can err on the side of exactness

krit: I'll make a proposal.

AmeliaBR: "Use the same heuristic as CSS masking, but modify it to make it apply equally to all shapes, and modify it to incorporate non-scaling stroke" but make it clear we will revisit when we have proposed text

RESOLUTION: Desire to use the same heuristic as CSS masking, but modify it to make it apply equally to all shapes, and modify it to incorporate non-scaling stroke. Revisit this once we have specific text

SVG Native

krit: many topics
... 1. Do we work on this in the WG or CG?
... It depends on which group is chartered first.

chris: It's already in scope. This isn't out of scratch, this has already been prototyped. We already have a concrete proposal to work from. Is that sufficient or do we want to go back to use cases, requirements, and come up with something different

<krit> https://www.microsoft.com/typography/otspec/svg.htm

myles: We should absolutely not re-do work that has already been done. I think if we went back, we would end up in the same place. I'm not aware of any design requirements or use cases that were not covered already. It Starting with the existing work would save a lot of time.

AmeliaBR: Where can I see existing documents?
... If there are use cases other than fonts, maybe we need a new document
... The end result of a use case documetn is a list of use cases, with the conclusion that we could start with what's in OT.

krit: At adobe, we use SVG for icons in most of our applications. We would like a simple SVG specification for icons so it's fast and easier to draw icons without an entire SVG implementation. Something that is small, reliable, fast
... Other use cases: Native design. Android studio already has SVG support, and it internally translates it to an internal format. They need a simple SVG spec

AmeliaBR: I don't need to be convinced. We just need to write it down, even if it's short

krit: No disagreement. It should be in the introduction of the spec.

myles: If it's short enough, it can be in the spec.

krit: Do we want to work on it in the CG or WG?

chris: Since we alreayd have a substantial document, and don't want to go back to use cases, then it should be done in the WG, because incubation is arleady done

krit: objections?

AmeliaBR: I think that makes sense, it' sjust a question of who will work on it. If there are people who want to work on it that aren't in the WG, then this would be an argumetn for doing it in a CG.
... If we have people that are active in OpenType but not in W3C, then we may want it in a CG.

chris: In this particular case, that doesn't apply. myles is here, dino is here, sairus is here, vlad is here

RESOLUTION: Start SVG Native work in the Working Group

krit: Who is going to edit it? Sairus and myles volunteered

myles: I would love to work with Sairus. he's awesome

chris: yeah!

krit: Let's resolve on those two. Anyone else?

<silence>

AmeliaBR: Can always be added in the future

RESOLUTION: Myles and Sairus are editors for this new draft

chris: myles, can you post a draft?

myles: yes, eventually

krit: Can you make sure a bikeshed file has a correct header for the SVG WG?
... When you do that, please upload it to the SVG github repo.

AmeliaBR: We need to figure out how to get it hosted
... We don't have a server to run the bikeshed build

chris: Run bikeshed locally and then run bikeshed locally on it and it will complain if anything's wrong. And ask TabAtkins if there's some problem.

AmeliaBR: Also can reach out to heycam who is our webmaster.
... We've looked inot moving the main SVG spec to bikeshed

krit: You can also ask me for help
... shortname?

AmeliaBR: svg-native

<universal agreement>

RESOLUTION: The shortname for SVG Native is svg-native

<stakagi> Does anyone have a javasript implementation of what falls under the SVG Native candidate like CANVG?

krit: Will this specification list requirements for a document or for an implementation?

chris: or both

AmeliaBR: the more effective way to address that is if we want to define SVG native is a strict subset of SVG
... so any SVG renderer can also do SVG Native

krit: Custom properties are available in implementations. The ones that don't wouldn't have anything to conform to

chris: which is an interesting question. Where are the renderers exposed? Inside OpenType engines, converting SVG to PNGs

AmeliaBR: I think it needs to be a requirement for both the document and the renderer. Requirements on the document is that it only includes the subset. But the requirements on the renderer have to go into error handling and maybe some nuances if it supports one feature but not another

krit: If we make requirements for an SVG native document, then the platform can request that the implementation just supports the subset. It would be possible.
... Do you think that any SVG native document should render the same way in the browser and as an SVG Native implementation

myles: yes

AmeliaBR: so SVG native is always a subset of svg full

chris: It will probably be a subset of SVG 2.

myles: yes

krit: Let's upload a draft spec so we can start discussing issues!

AmeliaBR: Do want to make a proper resolution that for now the scope of SVG Native is always a subset of SVG?

RESOLUTION: SVG Native is a subset of SVG

AmeliaBR: Officially, none of our resolutions are final until a week after we publish them to the mailing list

chris: In principle, someone has a week to object.

krit: It might be easier to have a list of removals of which feautres are not part of the list

AmeliaBR: I don't like the idea of having normative text duplicate in two different specs. It should be included by reference.

myles: okay, let's keep it a diff spec, then.

AmeliaBR: Someone needs to tell Sairus.

chris: he already knows, right?

krit: yes.
... Anything else?

<silence>

AmeliaBR: If people haven't already, please look at the other issues on the agenda.

<krit> present?

<chris> um, that just zeroed the attendance :)

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/cyrus/sairus/
Succeeded: s/<missed>/bikeshed locally/
Succeeded: s/of SVG is always/of SVG Native is always/
Present: ? myles chris AmeliaBR stakagi krit
Found ScribeNick: myles
Inferring Scribes: myles
Found Date: 25 Mar 2019
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)