From mboxrd@z Thu Jan 1 00:00:00 1970 From: Achim Gratz Subject: Re: unnumbered subsections in latex export Date: Thu, 24 Mar 2011 19:27:13 +0100 Message-ID: <8739mcnzlq.fsf@Rainer.invalid> References: <20110322051038.21655c80@kuru.homelinux.net> <80d3lj9wj6.fsf@somewhere.org> <20110322053134.669127e9@kuru.homelinux.net> <8999.1300804510@alphaville.dokosmarshall.org> <20110322160814.227fc53f@bhishma.homelinux.net> <27844.1300836065@alphaville.usa.hp.com> <8162r9hgxm.fsf@gmail.com> <87bp11dk4h.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from [140.186.70.92] (port=35946 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q2pFq-0003yD-Fk for emacs-orgmode@gnu.org; Thu, 24 Mar 2011 14:27:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q2pFp-0003gD-2n for emacs-orgmode@gnu.org; Thu, 24 Mar 2011 14:27:30 -0400 Received: from lo.gmane.org ([80.91.229.12]:53192) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q2pFo-0003fv-ON for emacs-orgmode@gnu.org; Thu, 24 Mar 2011 14:27:29 -0400 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Q2pFn-0005f3-D2 for emacs-orgmode@gnu.org; Thu, 24 Mar 2011 19:27:27 +0100 Received: from p57aace84.dip.t-dialin.net ([87.170.206.132]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 24 Mar 2011 19:27:27 +0100 Received: from Stromeko by p57aace84.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 24 Mar 2011 19:27:27 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Bastien 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. Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds