Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org

From: "John R Levine" <[email-masked]>
Date: 26 Sep 2010 16:17:00 -0400

>> It's hard to say whether it's easier to intuit the necessary semantics
>> from the XML or the XHTML. If we get someone to rewrite xml2rfc, I think
> 
> The step from XML->XHTML already does everything *except* formatting into 
> plain text, this includes computing the boilerplate, doing the various 
> reference and list formats, etc.

That should be fine so long as the tagging in the XHTML is adequate to 
recognize what each kind of feature is.

> Indeed. The problem is that the RFC production center apparently likes the 
> ability to micromanage vertical space and line breaks. That is a problem. I'm 
> not convinced that they'd switch to any tool that gives them less control 
> than nroff does today.

Well, if we hire someone to rewrite it, there's something to put in their 
checklist.  It would probably be possible to use stylized comments to give it 
hints to control line spacing or whatever else they're fussing about while not 
screwing up the semantics of the XML.  Based on the experiments Paul H and I 
did when we were applying to be the RFC Ed, it shouldn't be hard to make the 
tool smart enough to get the spacing right on its own, although it would take a 
long time for the RFC Ed to believe that.

>>> XML --> (X)HTML --> TXT
>>> Would it be just as easy to produce PDF?
>>> XML --> (X)HTML --> PDF
>>> Or, would we continue to produce the PDF from the TXT?
>> 
>> That's more a political than a technical question. A PDF made from the
>> TXT produces a printable version of the canonical text. A PDF made from
>> the XHTML makes a document that's a lot easier to read.
> 
> Right.
> 
> Just keep in mind that we already have a way to produce a printable version 
> from TXT (via Henrik's rfcmarkup tool).

Huh?  rfcmarkup creates simple minded html with clickable links, not PDF. If 
you want to turn paginated text into PDF that looks like the paginated text, 
you can easily use enscript or a2ps to produce postscript, and ps2pdf (a 
wrapper around ghostscript) to turn it into PDF.  The more interesting path is 
from XHTML to PDF, with pages formatted like what a browser does with XHTML.

R's,
John

---

From: Julian Reschke <[email-masked]>
Date: Sun, 26 Sep 2010 23:07:50 +0200

On 26.09.2010 22:17, John R Levine wrote:
>> The step from XML->XHTML already does everything *except* formatting
>> into plain text, this includes computing the boilerplate, doing the
>> various reference and list formats, etc.
>

Yes. We could add this when we need it (hardwired class names, extension 
attributes, or PIs).

>> Indeed. The problem is that the RFC production center apparently likes
>> the ability to micromanage vertical space and line breaks. That is a
>> problem. I'm not convinced that they'd switch to any tool that gives
>> them less control than nroff does today.
>
> Well, if we hire someone to rewrite it, there's something to put in
> their checklist. It would probably be possible to use stylized comments
> to give it hints to control line spacing or whatever else they're
> fussing about while not screwing up the semantics of the XML. Based on
> the experiments Paul H and I did when we were applying to be the RFC Ed,
> it shouldn't be hard to make the tool smart enough to get the spacing
> right on its own, although it would take a long time for the RFC Ed to
> believe that.

That's what I fear. Giving up control never is easy :-).

>> Just keep in mind that we already have a way to produce a printable
>> version from TXT (via Henrik's rfcmarkup tool).
>
> Huh? rfcmarkup creates simple minded html with clickable links, not PDF.

It creates HTML that prints like the original TXT was intended to print.

That being said; printing is totally overrated, and we really should 
focus on what matters today (reflowable text, accessibility, display on 
ebooks come to mind).

> ...

Best regards, Julian