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 <joel-AT-boost-consulting.com> 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
data.

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

<snip>

> 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
http://www.boostpro.com