Re: Miterclip and Arcs joins, and the future of SVG 2 generally

Hi Skef,

As someone who really liked these join styles when I first found out about
them, I'm personally very glad to see someone diving forward on them.

But in doing so, you've run into some of the tricky inter-dependency issues
in SVG standardization. Standards depend on browser implementations depend
on rendering engine capabilities depend on browser demand depend on
standards!  And there just haven't been enough people able & willing to do
the work at each step.

The only way to move forward on new graphics capabilities is to try to push
all three sides at the same time.

Starting with Skia was a great choice for an issue like this, so it's
disappointing to hear that you're being told it won't be reviewed. I'm not
seeing those comments on the patch review page [1], but maybe it's worth
emphasizing that this is something in the SVG spec. Also mention that there
are experimental implementations in Inkscape.

The next step is to make some noise on the Chromium bug [2] about the Skia
patch being available and waiting for review. Also mention it on the
Firefox bug [3], since Firefox uses Skia on some platforms. If there are
any font rendering libraries that use it, get feature requests in their
trackers. If you can get artists / web developers / font designers excited
about this feature & upvoting / posting about these feature requests, that
helps, too.

You could also open an issue on the SVGWG repo [4] asking for the “at risk”
to be removed because of the Skia implementation plus the Inkscape
implementation. It won't happen right away (not until it's in at least one
browser, with tests) but the discussion might get a few more people looking
at the patch. And of course, cross-reference the issues you posted (thank
you!) about ambiguities in the spec, so those can also get more discussion.

Finally, if you're able to work with the Inkscape devs on creating test
cases for Web Platform Tests — to prove interoperability between the two
implementations — that also helps move everything forward.

I'll try to make a little noise myself, and hopefully get the right people
paying attention. For myself, thank you for doing this work — even if you
didn't realize how much work it would be when you started! (Isn't that how
we all get involved in open source… sigh.)

Best,
Amelia BR

[1]: https://skia-review.googlesource.com/c/skia/+/303483
[2]: https://crbug.com/366618
[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1239142
[4]: https://github.com/w3c/svgwg/issues



On Tue, 28 Jul 2020 at 21:27, Skef Iterum <github@skef.org> wrote:

> Whatever else happens, you're welcome!
>
> The Chromium project was represented in the "chat" so that angle may be a
> dead end, but I guess it's worth a try. I'm not the appropriate person to
> do that update, though.
>
> Skef
> On 7/28/20 4:08 PM, Paul LeBeau wrote:
>
> Awesome work Skef.  Thank you for doing that.
>
> I have no power myself, but the first step would presumably be to update
> 266618 with this info.  Then we can hope that we can get some of the
> Chromium/Opera/Edge folks here to push it over the line.
> Merging this change (and the small changes to implement attribute/CSS
> support) will presumably instantly give it the 2+ browser implementations
> it needs to lose its "at risk" status.
>
> Paul
>
>
> On Wed, 29 Jul 2020 at 06:01, Skef Iterum <github@skef.org> wrote:
>
>> A while back I implemented Miterclip and Arcs joins in FontForge because
>> I thought they were a good idea (and I didn't realize at first that they
>> weren't implemented much of anywhere else).
>>
>> And because I thought they were a good idea, and I was familiar with the
>> algorithms, I decided to try to get them off the "at risk" list by
>> implementing them in Skia and then a browser. Hence, after a large amount
>> of work:
>>
>> https://skia-review.googlesource.com/c/skia/+/303483
>>
>> It's very hard to defend code quality in words but anyone who wants to
>> (and has a machine capable of compiling Skia) can pull this over and run viewer
>> --slide StrokeJoins to verify the general lack of "glitches" for
>> themselves.
>>
>> I've now chatted briefly with some of the Skia folks and they say it's
>> unlikely they'll review this CR, let alone integrate it, for the expected
>> "this isn't coming from the product side" reasons. Code quality is
>> therefore not at issue -- it's just an issue of perceived demand.
>>
>> So, two things:
>>
>>    1. If anyone is in a position to prompt advocacy for this feature
>>    from any group maintaining a browser that uses Skia, now is the time.
>>    Opera, maybe? Anyone?
>>    2. If no one is in that position it may be time to rethink this part
>>    of the standard.
>>
>> Obviously no one asked me to do this work so the time that I've wasted is
>> entirely on me. However, if this is the reality there's a point where
>> standards groups need to ask themselves whether what they've specified
>> amounts to more than an attractive nuisance (like a pool without a fence).
>>
>> Skef Iterum
>>
>