Subject: [xml2rfc] Large I-D and large artwork

From: "Patrik Fältström" <[email-masked]>
Date: Wed, 27 Jun 2018 15:41:22 -0500

Hi,

I have a draft, draft-faltstrom-unicode11-00.txt, which shortly is to become -01. I might have made many mistakes because I do not write I-D every week any longer. I have in fact not used the new version of xml2rfc :-)

Yes, the pip install works. Local xml2rfc tool (the new one) is great!

But...three issues.

A. Large XML

This creates timeouts both in the submission tool and ID-nit tool. Requires me to fall back to manual submission (which worked).

B. Artwork left column

If you look in the draft, you see most of the artwork that is longer than one page end up being left aligned with the left column. This except beginning of Appendix E.

It is created like other artworks like this:

<section title="Changes from Unicode 10.0.0 to Unicode 11.0.0">
  <t>
    Changes from derived property value DISALLOWED to PVALID.
  </t>
<figure><artwork>
111C9       ; PVALID      # SHARADA SANDHI MARK
</artwork></figure>
  <t>
    Changes from derived property value UNASSIGNED to either
    PVALID or DISALLOWED.
  </t>
<figure><artwork>
0560        ; PVALID      # ARMENIAN SMALL LETTER TURNED AYB
0588        ; PVALID      # ARMENIAN SMALL LETTER YI WITH STROKE
05EF        ; PVALID      # HEBREW YOD TRIANGLE
:
:

C. Artwork and page breaks

If you look at Appendix D, you see a page break after the initial leading text.

It is created like this:

<section title="Changes from Unicode 9.0.0 to Unicode 10.0.0">
  <t>
    Changes from derived property value UNASSIGNED to either
    PVALID or DISALLOWED.
  </t>
<figure><artwork>
0860..086A  ; PVALID      # SYRIAC LETTER MALAYALAM NGA..SYRIAC LETTER M
09FC..09FD  ; PVALID      # BENGALI LETTER VEDIC ANUSVARA..BENGALI ABBRE
:
:

   Patrik

---

From: Julian Reschke <[email-masked]>
Date: Wed, 27 Jun 2018 23:01:31 +0200

On 2018-06-27 22:41, Patrik Fältström wrote:
> ...

It's too wide, thus getting outdented.

Warnings from rfc2629.xslt:

> WARNING: artwork line too long: '0528..052F  ; DISALLOWED  # CYRILLIC CAPITAL LETTER EN WITH LEFT HOOK..C' (72 characters) (at line 577)

etc. Warnings from xml2rfc:

> WARNING: artwork outdented 3 characters to avoid overrunning right margin around input line 639)
> WARNING: artwork outdented 3 characters to avoid overrunning right margin around input line 786)
> WARNING: artwork outdented 3 characters to avoid overrunning right margin around input line 851)
> WARNING: artwork outdented 3 characters to avoid overrunning right margin around input line 909)
> WARNING: artwork outdented 3 characters to avoid overrunning right margin around input line 961)
> WARNING: artwork outdented 3 characters to avoid overrunning right margin around input line 1022)

> 09FC..09FD  ; PVALID      # BENGALI LETTER VEDIC ANUSVARA..BENGALI ABBRE

Don't worry about vertical whitespace. Until we switch to the v3 format 
the RFC Production Center will probably take care of it; once we *have* 
switched it'll (IMHO) be irrelevant because the primary output format 
will not be paginated anyway.

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 27 Jun 2018 23:06:18 +0200

Hi Patrik,

> This creates timeouts both in the submission tool and ID-nit tool. Requires me to fall back to manual submission (which worked).

Huh.  I'll have to spend some debugging time on that; a trial conversion
shows an xml2rfc conversion time of 2.16 seconds, which does not seem
objectionable in itself.  The hiccup is somewhere else.

> If you look in the draft, you see most of the artwork that is longer than one page end up being left aligned with the left column. This except beginning of Appendix E.

This is an effect of the provided artwork having a width of 72 characters,
which forces it to the left, in order to not exceed the column width limit.

If you reduce the artwork width to 69 characters, it should be rendered with
a regular left-hand margin.

...

> If you look at Appendix D, you see a page break after the initial leading text.

Yes.  There isn't room for the provided artwork on that page, so it's started
on a new page.  If you want it split across pages, you'll have to split it
manually into two separate <artwork> elements.

It's probably just as well to leave it as is.

Regards,

	Henrik

---

From: "Patrik Fältström" <[email-masked]>
Date: Wed, 27 Jun 2018 16:20:22 -0500

>> WARNING: artwork line too long: '0528..052F  ; DISALLOWED  # CYRILLIC CAPITAL LETTER EN WITH LEFT HOOK..C' (72 characters) (at line 577)

Ok, thanks!

Question: I like it being outdented... :-) Can I force this to happen?

> Don't worry about vertical whitespace. Until we switch to the v3 format the RFC Production Center will probably take care of it; once we *have* switched it'll (IMHO) be irrelevant because the primary output format will not be paginated anyway.

Ok, thanks!

   paf

---

From: Julian Reschke <[email-masked]>
Date: Thu, 28 Jun 2018 07:29:26 +0200

> Question: I like it being outdented... :-) Can I force this to happen?

Ouch. Probably not, unless xml2rfc groks trailing nbsp (U+0160)...

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 28 Jun 2018 07:37:57 +0200

> It's probably just as well to leave it as is.

In general, large artwork will always be problematic for paginated 
output, because the processor doesn't have sufficient information where 
page breaks make sense.

So, my recommendation would be to avoid it :-)

Otherwise, grouping into individual figure elements can help. In V3, we 
also allow a figure to contain multiple artwork element.

Best regards, Julian

---

From: "Patrik Fältström" <[email-masked]>
Date: Thu, 28 Jun 2018 00:59:32 -0500

> So, my recommendation would be to avoid it :-)

Tell the Unicode Consortium to not have more than 75 code points in their standard :-D

   paf

---

From: Julian Reschke <[email-masked]>
Date: Thu, 28 Jun 2018 08:21:28 +0200

> Tell the Unicode Consortium to not have more than 75 code points in their standard :-D

:-). I meant: avoid using artwork for that purpose. Maybe a table?