From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: [PATCH] latex export - title placement Date: Wed, 01 Jun 2011 18:05:28 -0400 Message-ID: <11174.1306965928@alphaville.dokosmarshall.org> References: <87wrhbdmjk.wl%sebhofer@gmail.com> Reply-To: nicholas.dokos@hp.com Return-path: Received: from eggs.gnu.org ([140.186.70.92]:38708) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRtY6-0002FT-RF for emacs-orgmode@gnu.org; Wed, 01 Jun 2011 18:06:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QRtY4-0006YQ-PS for emacs-orgmode@gnu.org; Wed, 01 Jun 2011 18:05:58 -0400 Received: from vms173013pub.verizon.net ([206.46.173.13]:59046) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRtY4-0006Xz-6x for emacs-orgmode@gnu.org; Wed, 01 Jun 2011 18:05:56 -0400 Received: from alphaville.dokosmarshall.org ([unknown] [173.76.32.106]) by vms173013.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LM400A9VTD55A60@vms173013.mailsrvcs.net> for emacs-orgmode@gnu.org; Wed, 01 Jun 2011 17:05:42 -0500 (CDT) In-reply-to: Message from tsd@tsdye.com (Thomas S. Dye) of "Sat, 28 May 2011 07:27:11 -1000." List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: "Thomas S. Dye" Cc: Sebastian Hofer , nicholas.dokos@hp.com, emacs-orgmode@gnu.org Thomas S. Dye wrote: > Sebastian Hofer writes: > > > Hi all, > > > > This patch addresses the problem of ambiguous conventions for the > > placement of the title related macros (\author, \date,...) with > > respect to the main document body in different latex classes. It > > introduces the following changes: > > > > * org-exp.el: > > - added the following options: > > - title-position (tpos) > > - with-title (wtitle) > > - with-author (wauth) [This is mostly addressed to Sebastian even though I'm replying to Tom's reply.] An empty #+AUTHOR: disables the insertion of author (assuming that TITLE is not empty - see below.) > > - with-date (wdate) An empty #+DATE: disables the insertion of date (same assumption.) > > - with-maketitle (wmtitle) An empty #+TITLE: disables the insertion of \maketitle. So if TITLE is not empty, you can get what you want with existing machinery. I could not find a way to make the title empty and still have author and/or date fields. Given all this, I think the only things you need is title-position and with-title, the latter in the unlikely event that you want a title page with author or date but without a title. Personally, I'd consider this last one unimportant and not worry about it, but you may disagree. > > > > * org-latex.el: > > - implemented handling of new options (see above): > > - title-position controls placement of \title, \author, \date; > > possible values are "b" = before \begin{document}, > > any other values default to after \begin{document} > > - with-* controls if the corresponding macro is exported at all > > this can be convenient for more complex titles (e.g. several > > authors including affiliations,...) > > > > The patch seems to work for me so far. What do you all think? IMO it > > would be useful to integrate this, as it gives slightly more control > > over the export process. Of course one might want to think about > > better option names. The diff is done against commit > > bc161ded3693f752616dcd247fc9d638789025ee. > > > > Let me briefly describe my current use case: > > I disable all commands except \title, use babel to created a title.tex > > file (including several authors and affiliations) by tangling latex > > code and then include the file (into the main body of the document, > > not the preamble). That's the only decent way I've found to do this, > > if anyone knows an easier way (I have the feeling that I might be > > overlooking an obvious solution) please let me know! > > I'm not sure what problem you are trying to solve here: can you explain? It seems to me that all this can be done in standard ways. > > Cheers > > Sebastian > > > > > Aloha Sebastian, > > Your patch should prove useful in the situation where one has to use a > particular class file that requires \title and friends to be declared in > the body of the document rather than the preamble. That functionality > is a welcome addition to the LaTeX exporter, IMO. > IIUC, the only remaining thing is the position of the \title etc macros in the preamble or the body (or both). There are three categories of LaTeX classes: the ones that implement Lamport's dictum that \title etc can come anywhere before \maketitle, the ones like RevTeX that insist on having them in the body and the ones like the thesis document class at Suvayu's university, that insist on having them in the preamble. I consider both of the latter two as buggy: has anybody submitted a bug report on them? Has anybody researched the prevalence of these bugs? Are there lots of classes in one or the other of the buggy categories? Be that as it may, it seems that org needs a patch to work around these bugs. Personally, since it is a class problem, I'd rather have this kind of information in the class template. You set it once for each class that needs it and you forget about it. Assuming the maintainers agree, any chance of reworking the patch along these lines? Maybe make it extensible as well: a property list that can accumulate all the junk in one place perhaps. That way the RevTeX class can be configured appropriately and the rest of the world can live in blissful ignorance of the problem. You might detect a bias here: I prefer these things in the preamble by default. > Another way to achieve your current use case, IIUC, which might or might > not seem easier, is to redefine \maketitle along the lines suggested by > Nick Dokos (see > http://orgmode.org/worg/org-tutorials/org-latex-export.html#sec-11_2). > As I mentioned, I'm not really sure what Sebastian is looking for, so I can't really say whether the above would help, but if it can be done this way, I think it would be preferable to introducing new user options for the exlusive use of the org latex exporter. There are legitimate uses for user options but working around bugs in downstream packages is not one of them. IMO, of course. Nick