From mboxrd@z Thu Jan 1 00:00:00 1970 From: Melanie Bacou Subject: Re: [ox, patch] Add #+SUBTITLE Date: Wed, 25 Mar 2015 22:38:06 -0400 Message-ID: References: <87a8z7z20k.fsf@gmx.us> <87vbht2kri.fsf@nicolasgoaziou.fr> <87sicx6of8.fsf@gmx.us> <87vbhqn4u4.fsf@nicolasgoaziou.fr> <551370B3.1000709@mbacou.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41553) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YaxiM-0007fg-3k for emacs-orgmode@gnu.org; Wed, 25 Mar 2015 22:40:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YaxiI-0008LT-RZ for emacs-orgmode@gnu.org; Wed, 25 Mar 2015 22:40:10 -0400 Received: from plane.gmane.org ([80.91.229.3]:47915) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YaxiI-0008Jp-LB for emacs-orgmode@gnu.org; Wed, 25 Mar 2015 22:40:06 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YaxiG-0008MO-Mh for emacs-orgmode@gnu.org; Thu, 26 Mar 2015 03:40:04 +0100 Received: from c-69-137-228-217.hsd1.dc.comcast.net ([69.137.228.217]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Mar 2015 03:40:04 +0100 Received: from mel by c-69-137-228-217.hsd1.dc.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Mar 2015 03:40:04 +0100 In-Reply-To: <551370B3.1000709@mbacou.com> 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 I forgot: #+COPYRIGHT On 3/25/2015 10:36 PM, Melanie Bacou wrote: > I would indeed go further and suggest adding the following once and for > all as common ox features: > > #+TITLE > #+SUBTITLE > #+DATE > #+AUTHORS (support multiple) > #+EMAILS (1 per author) > #+AFFILIATIONS (1 per author) > #+CLASSIFICATION (e.g. "ACM", "JEL", "Dublin Core", "your corporate > classification", etc.) > #+KEYWORDS > #+DESCRIPTION > #+REVISION > > This is not so much about what back-ends currently support (that's > irrelevant in my view), it's about what minimum meta information is > needed to publish and maintain meaningful documents. The use of these > meta fields encourage good publishing practices, and all back-ends > should eventually support all or a subset of these. Most LaTeX journal > classes do. HTML would support these at least as tags. > ODT and DOCX can support all using templates. > > --Mel. > > > > On 3/24/2015 5:05 AM, Nicolas Goaziou wrote: >> Rasmus writes: >> >>> Nicolas Goaziou writes: >>> >>>> However, I think porting this feature to back-ends that do not support >>>> it out of the box is pushing too hard. >>> >>> In the patch there's ox-latex where e.g. KOMA-Script has as >>> subtitle-macro. ox-html, ox-ascii, ox-odt all are pretty liberate >>> formats >>> in terms of what elements are supported. >> >> My concern is not technical. You can indeed tweak "ox-html", "ox-ascii" >> and "ox-odt" to support many things. >> >> I just don't want to make it too difficult for back-end developers, and >> maintainers, to keep up with compatibility with other back-ends, while >> still allowing existing back-ends to extend (almost) freely. >> >> E.g., when creating a new export back-end, it is quite obvious that one >> will need to handle TITLE, DATE, AUTHOR and EMAIL somehow. Now, if you >> request handlers for SUBTITLE, KEYWORDS and DESCRIPTION, it becomes more >> tedious to achieve the task. >> >> This is not really about SUBTITLE, but, sooner or later, we will have to >> draw a line between common features ensuring compatibility between >> back-ends and specific ones. The cost of the former is some orders of >> magnitude higher. >> >>>> This is why I suggested to move KEYWORD and DESCRIPTION outside of >>>> "ox.el", as they cannot be ported to all back-ends without relying on >>>> dubious markup. >>> >>> Yeah, I still have a patch for that... I still have to do the >>> documentation changes. >> >> Unless we decide that KEYWORD and DESCRIPTION should move to the "common >> features" discussed above. In this case, they stay in "ox.el" and all >> major back-ends are expected to handle them. WDYT? >> >>>> Now, if SUBTITLE is a feature desperately needed everywhere, which can >>>> be discussed, it should be moved to "ox.el" and probably >>>> `org-element-document-keywords'. IMO, this is not necessary. SUBTITLE >>>> should be kept for back-ends that can handle it. >>> >>> IMO it is. >> >> See above. I don't mind much, as long as we eventually stop >> compatibility hell at some point. >> >> If you think it's important, then go ahead. >> >>> The only place where there's a "hack" is in ox-latex and >>> that's cause article is the default class. If you prefer, it can just >>> output to the \subtitle{ยท} by default and say it's KOMA-script only. >>> That >>> seems harsh, though. >> >> I agree it would be harsh. >> >>>> As a side note, "ox-texinfo" doesn't parse SUBTITLE. You might want to >>>> change it and update manual accordingly. >>> >>> The patch doesn't touch ox-texinfo. I don't mind fixing that bug, >>> though. >> >> It isn't a bug at the moment, since that feature is documented in the >> manual. However, it will become inconsistent if other back-ends parse >> SUBTITLE. >> >> >> Regards, >> >> > -- Melanie BACOU International Food Policy Research Institute Snr. Program Manager, HarvestChoice E-mail m.bacou@cgiar.org Visit www.harvestchoice.org