Re: [Rfc-markdown] [rfc-i] Problem with Kramdown tooling and figures?

Carsten Bormann <cabo@tzi.org> Wed, 08 June 2022 13:08 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: rfc-markdown@ietfa.amsl.com
Delivered-To: rfc-markdown@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEA7C14CF17; Wed, 8 Jun 2022 06:08:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URRBbULWV61i; Wed, 8 Jun 2022 06:08:43 -0700 (PDT)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D325C14CF08; Wed, 8 Jun 2022 06:08:41 -0700 (PDT)
Received: from [192.168.217.118] (p5089ad4f.dip0.t-ipconnect.de [80.137.173.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4LJ6wz4hQ5zDCl1; Wed, 8 Jun 2022 15:08:35 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <MN2PR11MB375776E0FFAA1023CFE4334AB9A49@MN2PR11MB3757.namprd11.prod.outlook.com>
Date: Wed, 08 Jun 2022 15:08:35 +0200
Cc: Jay Daley <exec-director@ietf.org>, "rfc-markdown@ietf.org" <rfc-markdown@ietf.org>, RFC Interest <rfc-interest@rfc-editor.org>
X-Mao-Original-Outgoing-Id: 676386515.16529-01e9cb8bde9e701d158a2bdff59382da
Content-Transfer-Encoding: quoted-printable
Message-Id: <CBE99342-C08C-4799-8A11-07B4DC66D6D6@tzi.org>
References: <MN2PR11MB37570F4603464349B5DFFE5AB9A59@MN2PR11MB3757.namprd11.prod.outlook.com> <5E5D4003-E3D8-49B2-B14D-5D4AC7ADA0A3@tzi.org> <MN2PR11MB3757F2B3467FA1B188A1294DB9A49@MN2PR11MB3757.namprd11.prod.outlook.com> <7FFFF173-7D5F-4000-BDD1-9B407767C48E@ietf.org> <MN2PR11MB375776E0FFAA1023CFE4334AB9A49@MN2PR11MB3757.namprd11.prod.outlook.com>
To: "Paul Duffy (paduffy)" <paduffy=40cisco.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc-markdown/DJfshLBJRdVterr1mvBAZWH0sks>
Subject: Re: [Rfc-markdown] [rfc-i] Problem with Kramdown tooling and figures?
X-BeenThere: rfc-markdown@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "rfc-markdown is a discussion list for people writing I-Ds and RFCs in Markdown and the authors of the tools used for that." <rfc-markdown.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rfc-markdown>, <mailto:rfc-markdown-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfc-markdown/>
List-Post: <mailto:rfc-markdown@ietf.org>
List-Help: <mailto:rfc-markdown-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rfc-markdown>, <mailto:rfc-markdown-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jun 2022 13:08:48 -0000

Quick status on using XML subtrees for figures:

— one problem in kramdown-rfc found and fix developed: figure tag, will be fixed in 1.6.11
— one problem in upstream kramdown (CDATA handling)
  Workaround: Don’t use CDATA
  Eventually: Fix upstream
— one problem in kramdown-rfc: svg subtree behaves differently from RFCXML main tree; standard conversions (e.g., id➔anchor) don’t work in SVG subtree

So there is some work needed to support what Paul is trying; I’m sure we will get to this in the next couple of weeks.

Alternatively/additionally to the XML subtrees, the code block (artwork) support in kramdown-rfc could be extended to directly do what Paul wants to do.
I’d need to know what that is to put in the support.

Grüße, Carsten