Re: [O] [PATCH] Improve usage of odt content templates
Detlef Steuer writes: >> 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. IMO, it just shouldn't set title in LaTeX. When I use author:nil \author{·} is simply not set and could be loaded via another file. I would also remove the \maketitle command. I don't have any particularly good argument for this, other than it feels right. . . Alternatively, there could be a yet another option maketitle:if-title, maketitle:always. . . With the text backend. I would make the banner dependent on the presence of a title. I.e. I'd probably go for no title, no banner. Though it's less clear here to what extend a title-less banner makes sense here. —Rasmus -- When in doubt, do it!
Re: [O] [PATCH] Improve usage of odt content templates
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, >
Re: [O] [PATCH] Improve usage of odt content templates
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? It seems that you answered to that question regarding ODT back-end though. WDYT? Regards, -- Nicolas Goaziou
Re: [O] [PATCH] Improve usage of odt content templates
Hi Nicolas, Nicolas Goaziou writes: > 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. +1! -- Bastien
Re: [O] [PATCH] Improve usage of odt content templates
Am Tue, 20 May 2014 16:37:45 +0800 schrieb Eric Abrahamsen : > Rasmus writes: > > > Nicolas Goaziou writes: > > > >> 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. > > > > That's nicer than a blank title ("#+TITLE: "). > > > > I prefer the earlier ox-behavior where no title would be printed if > > title was missing, rather than using the file-name. The file name > > is never interesting in my work flow. If introducing a title > > option it would be nice if an option is "print title if present" so > > that this can be set by default. > > +1 +2 Have fought with "set filename as title" before, would like and use such an option. Detlef > > I'm forever deleting the title because I forget to insert an empty > string #+TITLE option. If there was an `org-export-with-title' option > I'd set it to nil and be happy 80% of the time. > > E > > > -- Detlef Steuer --- Dr. Detlef Steuer Helmut-Schmidt-Universität Fakultät WiSo Holstenhofweg 85 22043 Hamburg Tel: 040/6541-2819 mail: ste...@hsu-hh.de
Re: [O] [PATCH] Improve usage of odt content templates
Rasmus writes: > That's nicer than a blank title ("#+TITLE: "). > > I prefer the earlier ox-behavior where no title would be printed if > title was missing, rather than using the file-name. The file name is > never interesting in my work flow. If introducing a title option it > would be nice if an option is "print title if present" so that this > can be set by default. I can second this, the filename never looks nice when doing an export. Kind regards, Christian
Re: [O] [PATCH] Improve usage of odt content templates
Rasmus writes: > Nicolas Goaziou writes: > >> 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. > > That's nicer than a blank title ("#+TITLE: "). > > I prefer the earlier ox-behavior where no title would be printed if > title was missing, rather than using the file-name. The file name is > never interesting in my work flow. If introducing a title option it > would be nice if an option is "print title if present" so that this > can be set by default. +1 I'm forever deleting the title because I forget to insert an empty string #+TITLE option. If there was an `org-export-with-title' option I'd set it to nil and be happy 80% of the time. E
Re: [O] [PATCH] Improve usage of odt content templates
Hi! * Nicolas Goaziou [140519 18:16]: > It is already possible to override the varible file-wise with: > > #+BIND: org-odt-content-template-file "somefile" > > I'm not sure it is worth adding another keyword. OTOH, there's also > ODT_STYLES_FILE and they are quite symmetric, so one could expect to be > able to set both. But then, `org-odt-content-template-file''s docstring > needs to be updated, and the feature should be documented in the manual. 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. > > Also, it should be > > (:odt-content-template-file "ODT_CONTENT_TEMPLATE_FILE" nil > org-odt-content-template-file t) Ah of course. > > > * Avoid inserting the document title as the first thing in the > > document contents, as there already is a title set in a title page > > in the template. As org-mode already sets the title data tag this > > can be used in the template to generate the correct title. However > > inserting the title as text is not desireable in that scenario. > > 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. Thanks for your review! Regards, Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease.
Re: [O] [PATCH] Improve usage of odt content templates
Nicolas Goaziou writes: > 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. That's nicer than a blank title ("#+TITLE: "). I prefer the earlier ox-behavior where no title would be printed if title was missing, rather than using the file-name. The file name is never interesting in my work flow. If introducing a title option it would be nice if an option is "print title if present" so that this can be set by default. —Rasmus -- El Rey ha muerto. ¡Larga vida al Rey!
Re: [O] [PATCH] Improve usage of odt content templates
Hello, Christian Kellermann writes: > I have been using org-mode's odt exporter heavily for the last days > with the attached patches. These scratch an itch I have and I submit > them to this list in the hope of being useful to others. Thank you for your patches. > * Possibility to override the globally defined > org-odt-content-template-file variable in the document It is already possible to override the varible file-wise with: #+BIND: org-odt-content-template-file "somefile" I'm not sure it is worth adding another keyword. OTOH, there's also ODT_STYLES_FILE and they are quite symmetric, so one could expect to be able to set both. But then, `org-odt-content-template-file''s docstring needs to be updated, and the feature should be documented in the manual. Also, it should be (:odt-content-template-file "ODT_CONTENT_TEMPLATE_FILE" nil org-odt-content-template-file t) > * Avoid inserting the document title as the first thing in the > document contents, as there already is a title set in a title page > in the template. As org-mode already sets the title data tag this > can be used in the template to generate the correct title. However > inserting the title as text is not desireable in that scenario. 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. Regards, -- Nicolas Goaziou