From mboxrd@z Thu Jan 1 00:00:00 1970 From: Detlef Steuer Subject: Re: [PATCH] Improve usage of odt content templates Date: Thu, 22 May 2014 10:00:53 +0200 Message-ID: <20140522100053.673d483f@gaia> References: <20140519104254.GX15335@pestilenz.org> <87zjidd9pn.fsf@gmail.com> <20140519164117.GA15335@pestilenz.org> <87bnur1eom.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54857) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WnNwF-00062B-RI for emacs-orgmode@gnu.org; Thu, 22 May 2014 04:01:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WnNw9-0004ZO-Pq for emacs-orgmode@gnu.org; Thu, 22 May 2014 04:01:19 -0400 Received: from plane.gmane.org ([80.91.229.3]:45747) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WnNw9-0004ZG-Jc for emacs-orgmode@gnu.org; Thu, 22 May 2014 04:01:13 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WnNw7-0007cl-4c for emacs-orgmode@gnu.org; Thu, 22 May 2014 10:01:11 +0200 Received: from gaia.unibw-hamburg.de ([139.11.181.103]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 May 2014 10:01:11 +0200 Received: from detlef.steuer by gaia.unibw-hamburg.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 May 2014 10:01:11 +0200 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: emacs-orgmode@gnu.org Am Wed, 21 May 2014 14:47:37 +0200 schrieb Nicolas Goaziou : > Hello, > > Christian Kellermann writes: > > > I first thought about using ODT_STYLES_FILE in the list form and > > pick out the content.xml from there, but maybe that's a bit > > unexpected as one might use a different content than from the style. > > > > But the control flow as it is now would need to be refactored to > > make this a nice patch too. > > > > I shall resend this patch with proper docstrings and manual patches > > if you like. > > Please do. > > >> I think this is a more general issue: should we implement an > >> > >> #+OPTIONS: title:nil > >> > >> feature? I think it makes some sense since we already have > >> date:nil and author:nil. In any case, keywords are not meant to be > >> used for booleans. This should be an OPTIONS item. > > > > I don't feel qualified to decide on this. I can provide the needed > > patches though. > > Introducing the item is easy, but making something out of it in each > back-end is not, as it requires to define what title:nil means there. > In particular, should it be "an empty title" or something else? > > For example, ascii back-end provides a banner as its title. Should > title:nil remove the title from the banner or should it remove the > banner altogether, thus overriding date:t and author:t items. > > Likewise, should title:nil insert "\title{}" in a LaTeX document > header, remove the "\maketitle{}" line, or perhaps, both? To be consistent over backends I think it should be implemented as an empty title string. If date:t or/and author:t are specified these should show up somewhere. \maketitle{} should be removed only, if a titlepage would appear empty in the exported document. Just the usual 2c worth of opinion. Detlef > > It seems that you answered to that question regarding ODT back-end > though. > > WDYT? > > > Regards, >