[rfc-i] [IAB Trac] #266: Requirement for "Clear Printing"

Marc Petit-Huguenin petithug at acm.org
Fri Feb 15 13:59:34 PST 2013

Hash: SHA256

On 02/15/2013 01:48 PM, Paul Kyzivat wrote:
> 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 formats.
>>> 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[1], and provided tools to convert this to graphics[2].
>> 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[3] 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 very
> human-friendly.


> 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.

I would participate in such effort.

- -- 
Marc Petit-Huguenin
Email: marc at petit-huguenin.org
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
Version: GnuPG v1.4.12 (GNU/Linux)


More information about the rfc-interest mailing list