Re: [Boost-docs] The beauty of LATEX

Subject: Re: [Boost-docs] The beauty of LATEX
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-10-30 00:29:16

on Sat Oct 29 2011, Joel de Guzman <> wrote:

> On 10/28/2011 4:57 PM, Matias Capeletto wrote:
>> I am starting to think that except for very basic Quickbook to HTML
>> snippets (no footnotes, no chunking), we should drop for now the idea
>> of making a direct Quickbook to HTML or PDF generation. I agree with
>> Daniel that if this is what we are looking for, then Joel's proposal
>> will not be enough. But Joel's idea could work very well in a
>> Quickbook to Docbook or LaTeX processor and, specially for generating
>> LaTeX, it seems very attractive. I would love to have the power and
>> maturity of LaTeX with the simple and clean Quickbook syntax.
> Alright, let me make it clear. I'm presenting this in a high-level
> design:
> 1. Preprocesors:
> a. The wiki can and *should be* a preprocessor.

Why? I don't have an opinion, but your assertion lacks any supporting rationale.

> b. The syntax-highlighter is another preprocessor. It should be made
> modular and should probably make use of a regex based highlighter
> already existing in the wild. THere are lots out there.

+1, on reuse of existing technology. But saying it's a preprocessor
makes it sound like it has to come first in the chain... and you've
already called the wiki component a preprocessor. Are you sure that's
what you mean?

> c. Code inclusion can very well be another preprocessor.

I'm less and less sure what you mean by preprocessor, now.

> 2. IR:
> a. There will be an (intermediate) output, call it a DOM or an
> AST as you and Dave have been calling. It shall be patterned
> after DocBook which has a very good structure to begin with.
> b. The IR **IS A TREE**. It should be semantically rich and
> extensible.
> c. We should get rid of docbook-isms in the output.
> d. Preprocessors need not be concerned about the full structure
> of the full IR, just a subset. Preprocessors should only be
> concerned about text to text translation into a subset of
> the IR it needs to deal with.

"text-to-text into (a subset of) the IR" doesn't sound compatible with
the idea that the "IR **IS A TREE**." Text is typically unstructured

I think you need to be clearer about the terms you're using.


> Again, preprocessors should only be text to text translators,
> much like the C++ preprocessor. It definitely should not dabble
> with tree transformations.

This is getting more and more confusing.

Dave Abrahams
BoostPro Computing

This archive was generated by hypermail 2.1.7 : 2017-11-11 08:50:41 UTC