[rfc-i] [IAB Trac] #266: Requirement for "Clear Printing"
pkyzivat at alum.mit.edu
Fri Feb 15 13:48:04 PST 2013
On 2/15/13 3:10 PM, Marc Petit-Huguenin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> On 02/15/2013 11:41 AM, Paul Kyzivat wrote:
>> On 2/15/13 2:10 PM, RJ Atkinson wrote:
>>> On 15 Feb 2013, at 13:23 , Paul Hoffman wrote:
>>>> Yes, it does, by keeping the column limitation to 72.
>>> I have no objection to including other formats with different column
>>> limits (or other formats with no column limit).
>>> A limitation that is specific to one of several possible formats (i.e.
>>> my proposal) is (by definition) NOT a limitation to the other possible
>> Being required to provide a form of the ascii art limited to 72 columns
>> imposes a severe limitation on the sorts of figures you can use.
>> Increasing the limit to 90 columns would help a *little*.
>> Unfortunately there are lots of things I would like to put into drafts that
>> won't work with ascii art of any sort. (Right now I am looking at a UML
>> class diagram with 28 classes that have a lot of interconnections. It
>> *ought* to be in a draft, but it isn't going to be in one any time soon.
> I wonder if a simple solution to that problem would not be to use a formal
> language representation in the input format and output text format,
> representation that can be automatically converted to a graphic for some
> formats, i.e, the txt format would keep the formal language and the HTML and
> PDF would have the graphic.
> Stéphane Bortzmeyer had a draft some time ago that defined a language for
> state machines, and provided tools to convert this to graphics. I am
> sure that other kinds of structured graphics (ladder diagrams, equations,
> class diagrams, etc...) can receive the same treatment. As an implementer I
> would not mind using a text version that does not contain any ASCII art but
> only this kind of formal languages, as I would still have the possibility of
> rendering the graphics separately. And formal languages are good for coding.
> This is in fact an extension of what we have today with ABNF. The formal
> language is in the text format, but there is nothing that prevents the tool
> converting the xml file to PDF or HTML to generate syntax diagrams instead
> of duplicating the text.
Its a plausible answer when its applicable.
In the case of UML, I'm not aware of any standard textual
representation, but there might be one. If so, its unlikely that it is
It would be nice if we had an assortment of agreed-upon formats for
various sorts of diagrams, so that they could be put into drafts and
automatically rendered in forms suitable for each output format.
A most obvious one to want here is for ladder diagrams.
More information about the rfc-interest