[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[O] Re: unnumbered subsections in latex export

From: Achim Gratz
Subject: [O] Re: unnumbered subsections in latex export
Date: Thu, 24 Mar 2011 19:27:13 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

Bastien <address@hidden> writes:
> I fully agree with Nick and Thomas (and others who also agreed): Org's
> export facilities need some real love and new export features need to be
> introduced as complete and as consistent accross exporters as possible.
> I hope we'll make progress on this for 7.6.

That would be very welcome news.  I'm not sure at what level you want to
tackle that problem -- just cleaning up some glaring inconsistencies or
a full tear-down and re-build?  I suspect that a (formal) document model
for orgmode documents would be required.  This ties neatly into a formal
syntax for orgmode documents that Dominik has been asked for at FOSDEM.

> Here is a list of difficulties:
> 1. the syntax of the backends vary, and this means that all Org options
>    are not meaningful in all target formats;

This actually is meta-data for the export process.  It would be neat if
it were the same for each backend, but that probably doesn't make much
sense.  But at least the various backends shouldn't require different
metadata for the same purpose as long as the capabilities are the same.

> 2. exporters use various methods to export the file (e.g. the HTML
>    exporter goes line by line, the LaTeX exporter parses the file and
>    render each section);

This is a question of the supported document model(s).  Formally HTML
doesn't support a lot of what the exporter may spit out, even if it
renders as intended on many browsers.

> 3. exporters are maintained by various people: I know the HTML exporter
>    and the LaTeX one, others know the other exporters, etc.

This wouldn't be much of a problem (I think...) if there was a way to
specify which parts of the org document model are supported by the
exporter and have a generic exporter hook into the export backend with
just the parts that the backend supports.  Or the other way around,
although I suppose it would be more efficient if the generic exporter
didn't need to build structures that the backend doesn't then export due
to lack of support anyway.

+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]