including graphics/image as artwork in binary format fails

[DDvO]

When trying to embed a PNG or JPG image, e.g., like this:

<figure title="foo">
   <artwork src="foo.png">
[ Cannot render graphics - please view foo.png ]
    </artwork>
</figure>

xml2rfc version 3.11.1 fails like this:

Error: Discarded unexpected <artwork> content with type='png': ''utf-8' codec can't decode byte 0x89 in position 0: invalid start byte'
Warning: No image data found in source file foo.png

This may be due to a bug in xml2rfc or some Python 3 hick-up
and appears related to https://stackoverflow.com/questions/27219301/utf-8-codec-cant-decode-byte-0x89

A workaround is to use a graphics file in SVG format, yet it may be hard to obtain
and xml2rfc appears pretty picky about the structure of the SVG input.
What worked best for me was to convert/save the source graphics in PDF format
and then use https://www.zamzar.com/convert/pdf-to-svg/

[jrlevine]

Although rfc 7991 is somewhat unclear on this point, we only allow text and SVG in artwork, not anything else.
This is a reasonable idea for an enhancement in the future.

[DDvO]

Although rfc 7991 is somewhat unclear on this point, we only allow text and SVG in artwork, not anything else. This is a reasonable idea for an enhancement in the future.

Hmm, but for instance
http://xml2rfc.tools.ietf.org/authoring/README-dev.html
gives an example including PNG input, yet this document appears outdated -
would be good if it was updated or at least a link to the current version added.

https://mailarchive.ietf.org/arch/msg/xml2rfc/hIbNt7PeJ9v-FYQgaCbgK4uNZ1Y/
seems to have succeeded using JPG input.

[jrlevine]

That was in 2015 using xml2rfc version 2 which we did not use to publish RFCs.
Things have changed in the past seven years.

[toerless]

We would simply like to use the same mechanism that for example rfc7893 uses to include PNG graphics.

…

On Wed, Mar 30, 2022 at 09:44:07AM -0700, John L wrote: Although rfc 7991 is somewhat unclear on this point, we only allow text and SVG in artwork, not anything else. This is a reasonable idea for an enhancement in the future. -- Reply to this email directly or view it on GitHub: #751 (comment) You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

[jrlevine]

As you are surely aware, RFC 7893 was a one-off using the old toolchain.

[toerless]

No, i am not aware. Can you please point me to the IETF policies and when they changed ? Last i was aware, it was welcome to produce the highest visual quality RFCs, including PNG images into PDF renderings. It seems counterproductive if that option was eliminated by new rules.

…

On Wed, Mar 30, 2022 at 10:47:05AM -0700, John L wrote: As you are surely aware, RFC 7893 was a one-off using the old toolchain. -- Reply to this email directly or view it on GitHub: #751 (comment) You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

[jrlevine]

Oh, my. You can start with RFCs 7990, 7991, 7992, 7993, 7994, 7995, 7996, 7997, and 7998. Particularly 7996.

[toerless]

If the answer why something as IMHO obviously useful/simple and needed AND previously working is not possible today is a list of 9 RFC, then you surely can imagine how lost one may feel trying to figure out how to improve this.

What is the suggestion to undo this regression bug of RFCXMLv3 and re-allow what was allowed in before with png files when rendering to PDF RFC. Or better yet of course allowing such PNG also not only for PDF but html renderings.

Small proposed RFC update to any specific of those RFCs, such as RFC7996 ?

Or is this like some of the other enhancements requests i think i have seen in the recent past something that can be done with less process overhead ?

Really struggling with the process, but surely not doing anything and just hoping for it to happen anyhow doesn't seem like a good option, right ?

[cabo]

And 6949.

      8.  Graphics may include ASCII art and a more complex form to be
          defined, such as SVG line art [SVG].  Color and grayscale will
          not be accepted.  RFCs must correctly display in monochromatic
          black-and-white to allow for monochrome displays, black-and-
          white printing, and support for visual disabilities.

Where were you 2013?

Welcome to the wonderful world of RFCXMLv3.

[jrlevine]

To be clear, I think PNG is a reasonable candidate as an enhancement, give or take accessibility issues, but it's not going to happen any time soon.