Re: [Cellar] [Tools-discuss] expressing both svg graphics and ascii-art fallback within an rfc2xml version 3 file?

Henrik Levkowetz <henrik@levkowetz.com> Sun, 01 September 2019 16:47 UTC

Return-Path: <henrik@levkowetz.com>
X-Original-To: cellar@ietfa.amsl.com
Delivered-To: cellar@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEB212007C; Sun, 1 Sep 2019 09:47:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCeL_WEiYBbD; Sun, 1 Sep 2019 09:47:21 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E294D120025; Sun, 1 Sep 2019 09:47:21 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:57811 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <henrik@levkowetz.com>) id 1i4Szt-0007qP-1j; Sun, 01 Sep 2019 09:46:59 -0700
To: Michael Richardson <mcr+ietf@sandelman.ca>, Dave Rice <dave@dericed.com>, tools-discuss@ietf.org
References: <3AAAEED4-87A9-4F5B-9910-55BABBDBBB15@dericed.com> <16851.1567355345@dooku.sandelman.ca>
Cc: Codec Encoding for LossLess Archiving and Realtime transmission <cellar@ietf.org>
From: Henrik Levkowetz <henrik@levkowetz.com>
Message-ID: <7b4e6a16-0b2b-a6f9-2ae6-5b1ddd3c05f8@levkowetz.com>
Date: Sun, 01 Sep 2019 18:46:17 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <16851.1567355345@dooku.sandelman.ca>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="feswXRjrCknn6Me9upJ1L4VxvLept2Jri"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: cellar@ietf.org, tools-discuss@ietf.org, dave@dericed.com, mcr+ietf@sandelman.ca
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/GSmQwN4D6PmvuNnsVESh6ua4JOw>
Subject: Re: [Cellar] [Tools-discuss] expressing both svg graphics and ascii-art fallback within an rfc2xml version 3 file?
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Codec Encoding for LossLess Archiving and Realtime transmission <cellar.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cellar>, <mailto:cellar-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cellar/>
List-Post: <mailto:cellar@ietf.org>
List-Help: <mailto:cellar-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cellar>, <mailto:cellar-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Sep 2019 16:47:24 -0000

Hi David,

Response at the bottom:

On 2019-09-01 18:29, Michael Richardson wrote:
> 
> {reposting to tools-discuss}
> 
> Hello cellar,
> 
> The draft of FFV1 now uses xml2rfc version 3 as defined at
> https://tools.ietf.org/html/rfc7991
> <https://tools.ietf.org/html/rfc7991>. Presently in the markdown source of
> the FFV1 draft, the math is maintained in both LaTeX expressions (which are
> converted to SVG for inclusion in the RFC XML) as well as an Ascii Art
> representation (heavily reliant on functions defined within the draft). For
> example: 
> 
> vs
> 
> r_{i} = floor( ( R_{i} * S_{i,C_{i}} ) / 2^8 )
> 
> Whether in SVG or ascii art, this data is contained by the <artwork> node in
> rfc2xml version 3. In https://tools.ietf.org/html/rfc7991#section-2.5
> <https://tools.ietf.org/html/rfc7991#section-2.5> it states, 
> 
>    Alternatively, the "src" attribute allows referencing an external
>    graphics file, such as a vector drawing in SVG or a bitmap graphic
>    file, using a URI.  In this case, the textual content acts as a
>    fallback for output representations that do not support graphics;
>    thus, it ought to contain either (1) a "line art" variant of the
>    graphics or (2) prose that describes the included image in sufficient
>    detail.
> 
> A bit later it says that SVG data may be encoded and stored within the
> <artwork>’s @src attribute such as  
> 
>    o  As a data: URI, such as: <artwork type="svg" src="data:image/
>       svg+xml,%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3…">
> 
> So from this I was hoping we could work on one draft rfc2xml version 3 file
> that could use the SVG image data or use the ascii art as a fallback; however
> when I try to craft the <artwork> node with both such as: 
> 
>    <artwork type="svg" src="data:image/svg+xml,ENCODED_SVG_MATH_IMAGE_HERE”>FALLBACK_ASCII_ART_HERE</artwork>
> 
> then the output “v3-plaintext” output of the conversion tool at
> https://xml2rfc.tools.ietf.org/experimental.html
> <https://xml2rfc.tools.ietf.org/experimental.html>, does not use the textual
> content of the <artwork> node as a fallback but instead places a warning such
> as 
> 
>    (Artwork only available as svg: No external link available, see
>    draft-ietf-cellar-ffv1-08.html for artwork.)
> 
> Is it feasible (recommended?) to have one rfc2xml XML document that could be
> a source for both plaintext formats (using an ascii art fallback) and
> non-plaintext formats such as HTML and PDF which would use the embedded SVG
> data?

Yes.  The specification of how to handle the text fallback in the RFC 799x
documents was in part contradictory, and also not as extensible and easily
editable as one could wish.  It currently looks like rfc7991bis largely will
follow the proposal discussed on the xml2rfc-dev list earlier this year, and
captured in the xml2rfc implementation notes draft here:

https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-09#section-3.1.1

which introduces an <artset> element which can contain multiple <artwork>
elements with different type attributes, for instance (artwork and some
details omitted:

  <artset>
    <artwork type="svg" src="..."/>
    <artwork type="ascii-art" ...>
	# ascii art
    </artwork>
  </artset>

For more on this, and for a light introduction to the v3 schema, check:
http://tools.ietf.org/src/xml2rfc/trunk/cli/doc/xml2rfc3.html#artwork-alternatives


Best regards,

	Henrik


> 
> Kind Regards,
> Dave Rice
> 
> 
> 
> 
> ___________________________________________________________
> Tools-discuss mailing list
> Tools-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/tools-discuss
> 
> Please report datatracker.ietf.org and mailarchive.ietf.org
> bugs at http://tools.ietf.org/tools/ietfdb
> or send email to datatracker-project@ietf.org
> 
> Please report tools.ietf.org bugs at
> http://tools.ietf.org/tools/issues
> or send email to webmaster@tools.ietf.org
>