[rfc-i] In the vein of LaTeX, but better and live: LyX
nico at cryptonector.com
Thu Dec 6 16:26:10 PST 2012
On Thu, Dec 6, 2012 at 2:58 PM, Ted Lemon <mellon at fugue.com> wrote:
> On Dec 6, 2012, at 3:34 PM, Nico Williams <nico at cryptonector.com> wrote:
> You're still not getting my point. Yes, fine, right now you can get TeX because Ubuntu does the work for you. What happens when they stop doing the work for you?
That's silly. The work's been done and the rate of change in that
space is very low, so why would I worry about that packaging rotting?
>> That's true of xml2rfc too! The Tcl version is... not exactly the
>> most maintainable software. If you don't want any part of that
>> problem then let's go back to nroff (hmmm, no one really maintains
>> nroff anymore either, do they?) or just manual typesetting of text
>> (this will never break, though it's a waste of time and effort).
> This is a false dichotomy. I agree that xml2rfc in tcl is the wrong solution, but that doesn't mean that LyX is the right solution, or that nroff is the right solution (although nroff at least is pretty easy to build). XML is easy to parse, and xml2rfc could easily be rewritten in python (or $LANGUAGE, for nearly every value of $LANGUAGE), because standard tools exist to parse it.
No, but should we really be in the business of writing or funding
typesetting software when there's plenty out there that might fit the
bill? Has anyone actually looked at this? Or is it all just a matter
Someone mentioned Word, which evidently is what OASIS uses. Even Word
can fit the bill if we relax/change the typesetting requirements and
do away with text, and we might even be able to produce text after all
by exporting to (X)HTML and them applying elinks and friends. Of
course, I'd not be happy with Word because it's not freely available
to IETF participants, but that's another story.
If a lot of change is on the table, then we should really consider not
going to the expense of building and maintaining our own typesetting
tools. Instead we should look at templating/styling existing tools.
>> We only typeset RFCs once too.
> No, this is absolutely untrue. Right now we have a tendency to re-format RFCs when we update them because the canonical form is useless for updating. But this is a bug, not a feature. IMHO the canonical form should be editable, which .txt files are not. Otherwise this waste of effort will be perpetuated by whatever effort occurs as a result of this discussion.
I'm not sure if you're referring here to issuing new RFCs that
update/obsolete old ones or if you mean literally that we re-format
existing RFCs, which I thought we never did.
>> list and I see people using LyX for typesetting books, not just
>> papers, and many other things besides, and I suspect they are not all
>> gray-beards (admittedly I wouldn't really know) who can't move into
>> the 21st century, but rather people of all walks who find LyX pleasant
>> and to get the job done.
> Yes, the same can be said of Word. Should we standardize on Word?
No. But for different reasons than you give.
>> You'd not edit .lyx with $EDITOR. I get to represent the metadata I
>> need, and if we typeset directly we could use all the existing
>> facilities that LyX has for formatting that xml2rfc evidently lacks.
>> OTOH, if we just fix xml2rfc then I can adapt lyx2rfc and you can
>> happily ignore all this. The point was that here's a tool that has
>> the fundamental functionality that we need and doesn't suck; perhaps
>> others will want to look at it dispassionately and see if it does fit
>> the bill.
> Okay, fair enough. My concern with this though is that if .lyx isn't the canonical form, then the canonical form will in some cases be where the changes will be made. And then we need a tool to get from the canonical form to .lyx losslessly, so that when a new version of the canonical form is generated from the .lyx, the changes will will not be complex. Alternatively, if .lyx _is_ the canonical form, then it needs to be a good canonical form.
IF LyX is usable for typesetting RFCs directly (and I'm not sure that
it is, but I suspect that yes, it is), then .lyx would be the
That said, I really do want an XML->LyX converter, partly so that
lyx2rfc could be used to work with existing .xml I-Ds. I just haven't
gotten there yet; for now I'm pretty happy with lyx2rfc working (it
More information about the rfc-interest