SVG overflowing margins of HTML output from author tools.

[woobagooba]

Sample SVG ... https://github.com/woobagooba/draft-ietf-is-csmp/blob/main/RegistrationConfigurationMetrics.svg

Margins are fine in the PDF output from author tools.

HTML output from author tools extends SVG far beyond the right margin.

[becarpenter]

I believe this is a side effect of the height and width attributes of the \

[kesara]

@becarpenter suggestion of deleting height and width works for me. Maybe this is a tip that should be in https://authors.ietf.org/en/diagrams ?

[becarpenter]

The problem is that most drawing tools include these elements. I don't know whether they are useful for the PDF generation. My private tool for fixing up SVG files includes this (a bit crude but it usually works...):

def nowh(l):
    """Remove width and height to allow scaling"""
    if 'viewBox' in l:
        print("Seen viewbox")
        if ' width="' in l:
            l1,l2 = l.split(' width="',1)
            _,l3 = l2.split('"',1)
            lout= l1 + l3
            print("Removed width")
        else:
            lout = l
        if ' height="' in lout:
            l1,l2 = lout.split(' height="',1)
            _,l3 = l2.split('"',1)
            lout= l1 + l3
            print("Removed height")
        return(lout)
    else:
        return(l)

[woobagooba]

A few additional comments.

If it matters, the source draft is authored in kramdown.

What happened to the online version of svgcheck? https://xml2rfc.tools.ietf.org/experimental is now landing on https://author-tools.ietf.org/.

Should/is svgcheck issuing a warning when height and width are encountered? Can it / should it automatically remove height and width?

Should 7996 be corrected to address the height and width issue?

I make these points because my tool vendor did their best to adhere to the RFC and author tools.

We should not depend on an ever lengthening list of manual edits required to make SVG source work for IETF drafts. The goal should be direct export from the SVG drawing tool and unaltered import into the draft.

Cheers

[rjsparks]

Paul:

What happened to the online version of svgcheck? https://xml2rfc.tools.ietf.org/experimental is now landing on https://author-tools.ietf.org/.

All of tools.ietf.org was taken down, per the plan announced over a year ago.

We haven't added svgcheck to author-tools as it was clear the community expected the 7996 restrictions to change. We'll look at adding it for people like you who are still attempting to conform to what turned out to be really bad dance steps.

Should 7996 be corrected to address the height and width issue?

No, 7996 should be replaced with a document that specifies a more reasonable profile of SVG allowed to appear in published RFCs. This has been discussed quite a lot on rfc-i, the xml2rfc list, the lead-up to the creation of the new editorial stream, and is now being at least pointed to strongly in RSWG.

This is very frustrating for the tools team - the community is not ok with the tooling continuing to make non-consensus changes to what the vocabulary allows, so until 7996 changes or we get strong and clear direction that we should work ahead of publication of its replacement, we are stuck at the current behavior.

From your early comments, it looked like you chose to push into this pain-point aware of what you were getting into. If not, the situation isn't the best, and it would serve everyone well for you to (re)skim the discussion on 7996 so far (or read one of Brian's summaries). If you are fully aware of the corners, then help push where it will matter - help the RSWG to approve a replacement for 7996.

[woobagooba]

My tool vendor had been using experimental svgcheck until it disappeared only a few days ago (?), thus the question. I guess now they will have to pull the source and build locally. NBD

I agree that 7996 (or its replacement) should be the authoritative spec for IETF SVG and non consensus changes should be prohibited. I do strongly advise any overhaul of 7996 reflect the reality of SVG diagramming tools available today. I was fortunate in that my tool vendor added an IETF special SVG export. That will not always be the case.

Unlikely that I will be resourced to assist untangling the IETF SVG knot. I might be able to rally other assistance. I will check.

You are probably already aware of this, but I will underline it anyway. I am able to take SVG from any number of drawing tools and have yet to find a viewer that is unable to display the SVG ... except the IETF RFC tools.

[woobagooba]

Please point me to Brian's 7996 SVG issues summary. Cheers

[becarpenter]

All I can speak to is the issues I discovered personally. I'm not sure I did write a summary but what I've learned is captured in https://github.com/becarpenter/misc/blob/main/fixupSVG.py. Jim Schaad did some fixes a while before his final illness. The RSWG is probably going to do RFC7991bis first, I think. I suspect that we won't get peoples' attention for SVG until that is done.

[rjsparks]

Apologies that I misremember, but I thought you had a shortlist of the things that whatever format we should move to should/shouldn't do to avoid the issues that our custom profile landed us in. Nevil made some changes too I think (at least he suggested he would at https://mailarchive.ietf.org/arch/msg/tools-discuss/yR78l9xZ4doOWDHUgkpJO56HyuI/). And if its still worth us making that checker reflect 7996 where it doesn't, we can work to do so. But I wonder if that's the better use of time.

[becarpenter]

It's possible that I am the one misremembering. This is a discussion we do need to start over at RSWG, I think.

[cabo]

On 2022-08-15, at 03:18, pbduffy @.***> wrote:

Should/is svgcheck issuing a warning when height and width are encountered? Can it / should it automatically remove height and width?

Should 7996 be corrected to address the height and width issue?

Oh, and by the way: this discussion is NOT theoretical.

Archived-At: https://mailarchive.ietf.org/arch/msg/auth48archive/nZXEC8ORpZycdmcFjuvUsSQg_6s

Grüße, Carsten

[becarpenter]

@cabo, I agree, it seems that each case needs to be checked for weird behaviour.

[martinthomson]

My experience with this is that width and height are extremely useful attributes for ensuring that things don't get scaled up. @cabo's example is something we had to fix with width and height attributes in RFC 9113. Without them, the diagram is - just like Carsten's example - disproportionately large.

If your diagram is too wide, then removing width and height will allow it to be scaled down to fit, but that probably isn't the right answer. If the image is getting cropped because it is too wide for the HTML (or PDF) view, then perhaps the problem is that the diagram is indeed too wide. A reasonable width for HTML is about 600px; the default xml2rfc stylesheet has a width of 724px; @woobagooba's example is 992px wide.

The @woobagooba includes here has text that essentially too small to read at 600px width[^1]. On a smaller screen it is totally unreadable; I can only imagine what it is like for someone with worse eyesight than mine.

[^1]: Even at its native font size of 13.3333px it's still arguably too small. Sure, the default xml2rfc stylesheet has body text at 14px, but that is also too small already.

[woobagooba]

I've massaged the width on https://github.com/woobagooba/draft-ietf-is-csmp/blob/e9c763102bee617e4f6f6a526d39de081660a25f/RegistrationConfigurationMetrics.svg and also split one of the longer diagrams into two. They all now render nicely in the PDF, still spill over the right HTML margin.

[woobagooba]

Folks, I've noted that there is a desire (requirement?) that drafts/RFCs adequately display on small screens? By that I assume IETF means cell phone? IMO any serious user of these documents is not developing on a cell phone. I would not let the small screen tail wag this dog. Cheers

[jrlevine]

I don't develop on a cell phone but I definitely look at RFCs on my phone now and then. They don't have to look fabulous but they do need to be readable. I also don't think it is a great idea to make designs starting with "nobody I know does X."

[woobagooba]

The requirements need to be crystal clear for priority use cases. We should not be optimizing for "now and then" readability on "small screens" (whatever that means). Is an Apple watch a small screen?

[becarpenter]

IMHO, we shouldn't mix an editorial judgment issue ("Is this diagram too busy/complex/big for an RFC") with a technical issue ("is scaling for any screen size a required or optional property?"). The former can only be answered case by case but the latter needs to be clearly resolved in 7996bis and in the toolset.

[martinthomson]

@becarpenter is right, there are two issues here.

The number of characters might be an editorial issue that can be decided on a per-document basis, though probably in a style guide.

Ensuring that this renders - if not well - but reasonably on a small screen is a technical problem. Though the technical solution might be informed by the bounds set by editorial policy. For instance, if editorial policy only needs 75 characters per line and SVG diagrams are created that fit that bound, they will look pretty good on a small screen, with only a modest reduction in text size or scrolling needed. Of course, if the goal is to include very large and complex images, we might need to look into something more advanced. I don't think we need anything advanced, but that is based on my opinion of what an appropriate editorial policy might be.

---

As for what editorial policy is reasonable, a two column diagram with >50 characters on the left and 75 characters on the right - more than 125 on a line - is probably going to blow right past any reasonable line length limit. The best advice I have says line length should be less than 75 characters. Unsurprisingly, the text format is almost ideal at 69 characters per line.

On a phone, you get slightly less than 75 characters, even with a small-ish font you only get around 50 (and there is good advice that suggests that the default RFC stylesheet uses too small a font size). But small screens are often high DPI and we don't need a perfect rendering for diagrams, just a good-enough one. People are able to scroll or zoom to get to details.

Here is what Paul's draft looks like on a phone (scaled down 4x, which is a fair representation of its readability):

That picture is several screens wide and more than a screen high. It's pretty comprehensible, but hard to work with. To see all of it, it is a bit squinty. It could probably be simplified a fair bit so that the important and structural parts are conveyed by the image, leaving the details to text.

[woobagooba]

Let me add that the PDF generated by author tools is fully legible on an IPhone in Adobe Reader. I hope the equivalent PDF generation will be made available by Datatracker.

[cabo]

First of all, I don't understand why datatracker offers PDFized plaintext where it should offer proper PDF.

Second, I'm trying to mine this conversation for the controls an authoring tool (such as kramdown-rfc) should provide.

Generally, authors don't want small figures to expand to full-width (see my example), and these are quite likely to occur, so scaling up needs to be default-off (as it is in kramdown-rfc now). But we never want parts of the figure to become inaccessible, so scaling down should be automatic. This needs to interact properly with any default CSS that is applied to SVG for both HTML and PDF-through-HTML (I don't know yet why the latter has a different effect). This CSS might change any week, and I don't think we have good test cases so people changing the CSS get to know when they have broken the scaling.

[cabo]

On 2022-08-17, at 16:44, John L @.***> wrote:

I don't develop on a cell phone but I definitely look at RFCs on my phone now and then. They don't have to look fabulous but they do need to be readable.

+1.
I’m forced by random circumstances to do this way more often than I’d like to. (It actually works very well with HTMLized…)

I also don't think it is a great idea to make designs starting with "nobody I know does X."

Related to the concept of “Proof by lack of imagination” :-)

Grüße, Carsten