Re: [rfc-i] No, constraining to a custom SVG profile is not trivial

[Phillip Hallam-Baker <[e-mail]>]

Since we will be embedding the SVG in a HTML page, I fail to see the
relevance of your point.

The font example is a reach. Since the fonts in question are intended for
use inside documents to define character glyphs it is pretty clear that
some very minimal set of terms will be required and so we are not so much
defining in SVG as designing a new version of metafont that uses the same
basic constructs.

I fail to see the reason I need to write code to flatten out markers and
perform the peculiar restrictions on tail text spans following tspan
elements.


On Mon, Jan 20, 2020 at 2:41 PM Leonard Rosenthol <[e-mail]>
wrote:

> Phillip – “issues” with SVG are entirely contextual.    When used in the
> context of a full “Web Platform User Agent” (aka a browser showing a web
> page), then there aren’t any issues because (as you note) that is the
> environment it was designed for.  However, use of SVG in other environments
> (eg. SVG inside of OpenType fonts -
> https://docs.microsoft.com/en-us/typography/opentype/spec/svg) requires a
> subsetting.   As I mentioned in a previous message, you can see what the
> OpenType and SVG committees (and others) are doing so subset SVG for their
> needs at https://github.com/adobe/svg-native-viewer.
>
>
>
> Leonard
>
>
>
> *From: *rfc-interest <[e-mail]> on behalf of
> Phillip Hallam-Baker <[e-mail]>
> *Date: *Monday, January 20, 2020 at 2:33 PM
> *To: *Brian Carpenter <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *Subject: *Re: [rfc-i] No, constraining to a custom SVG profile is not
> trivial
>
>
>
> It is not just the greyscale that is the issue. There are numerous issues
> in the diagrams that result from the chosen profile.
>
>
>
> Compare the diagrams in:
>
> https://tools.ietf.org/id/draft-hallambaker-mesh-architecture-12.html
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fid%2Fdraft-hallambaker-mesh-architecture-12.html&data=02%7C01%7Clrosenth%40adobe.com%7C2f501838df364303804008d79ddf8e6b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151455836674875&sdata=RhykyuDd9T435cIKVPW7yG1PbcLPtdlZkTkCCfxya1Y%3D&reserved=0>
>
>
>
>
> With the originals in:
>
> https://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmathmesh.com%2FDocuments%2Fdraft-hallambaker-mesh-architecture.html&data=02%7C01%7Clrosenth%40adobe.com%7C2f501838df364303804008d79ddf8e6b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151455836684868&sdata=yLpwP9rq1EOyeTrt2c3E8sd7LcC%2FMODhLRv%2FqzSzQpU%3D&reserved=0>
>
>
>
> Getting the diagrams to present properly is at least two weeks work for me
> on top of the weeks already spent. And I am probably not going to be the
> last person making this set of complaints. I am just the first person who
> developed specs that depend on having good diagrams in them.
>
>
>
> On Wed, Jan 15, 2020 at 10:21 PM Brian E Carpenter <
> [e-mail]> wrote:
>
> > Attached is a simple XSLT script that I created that simply rips out
> invalid elements.
>
> The problem with colour/greyscale is that this isn't enough. If you have
> very dark blue text on a very pale pink background, what happens? svgcheck
> makes this black on black; my heuristic makes it black on white. What would
> your script do?
>
> But I do agree with Phill, this is a non-trivial issue. Currently I think
> doing new drawings with a simple tool like DIA is the only practical way.
>
>
>
> It is my opinion that a standards organization should stick to existing
> standards rather than inventing its own. Deviation from W3C standards
> should only happen with an incredibly good reason. I do not see one.
>
>
>
> Telling people to use one particular tool looks like bullying behavior to
> me. Forcing people top jump through hoops to produce the old plaintext
> format was bullying which was one of the reasons I was so opposed to it.
>
>
>
> SVG is ubiquitously supported in current generation browsers. There are
> tens, probably hundreds of thousands of person years worth of effort
> invested in creating SVG content using today's tools. There is a published
> spec that is widely distributed and at least as certain to survive whatever
> apocalypses might occur as RFCs.
>
>
>
> RFCs are merely tools for making the Internet change. We are not writing
> holy scripture here. All RFCs that have the slightest importance are going
> to have errors. The question is not how to eliminate the errors but to
> minimize them.
>
>
>
> Moving to HTML greatly reduces the number of errors in interpretation.
>
>
>
>
>
> Allowing unrestricted SVG has plenty of issues too.
>
>
>
> Nobody ever gives a specific issue. That is not how a standards
> organization should behave. If there is a need to vary any standard, either
> our own or someone else's there should be a clearly articulated reason
> given.
>
>
>
> Please state specific issues.
>

_______________________________________________
rfc-interest mailing list
[e-mail]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest