emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Melanie Bacou <mel@mbacou.com>
To: Rasmus <rasmus@gmx.us>, emacs-orgmode@gnu.org
Subject: Re: [ox, patch] Add #+SUBTITLE
Date: Wed, 25 Mar 2015 22:36:35 -0400	[thread overview]
Message-ID: <551370B3.1000709@mbacou.com> (raw)
In-Reply-To: <87vbhqn4u4.fsf@nicolasgoaziou.fr>

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 <meta content=""> tags. 
ODT and DOCX can support all using templates.

--Mel.



On 3/24/2015 5:05 AM, Nicolas Goaziou wrote:
> Rasmus <rasmus@gmx.us> writes:
>
>> Nicolas Goaziou <mail@nicolasgoaziou.fr> 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

  parent reply	other threads:[~2015-03-26  2:36 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-20 23:23 [ox, patch] Add #+SUBTITLE Rasmus
2015-03-21  2:26 ` Marcin Borkowski
2015-03-21  2:32   ` Melanie Bacou
2015-03-22 14:02 ` Nicolas Goaziou
2015-03-22 15:29   ` Rasmus
2015-03-22 20:47     ` Marcin Borkowski
2015-03-22 21:21       ` Thomas S. Dye
2015-03-22 21:23       ` John Williams
2015-03-22 22:43       ` Rasmus
2015-03-22 23:19         ` Marcin Borkowski
2015-03-23  0:05           ` Rasmus
2015-03-23  8:32             ` Marcin Borkowski
2015-03-23  9:00       ` Sebastien Vauban
2015-03-24  9:05     ` Nicolas Goaziou
2015-03-24  9:37       ` Rasmus
2015-03-28 15:17         ` Nicolas Goaziou
2015-03-26  2:36       ` Melanie Bacou [this message]
2015-03-26  2:38         ` Melanie Bacou
2015-03-26 10:10         ` Rasmus
2015-03-22 14:34 ` Eric Abrahamsen
2015-03-22 15:32   ` Rasmus
2015-03-23  1:17     ` Eric Abrahamsen
2015-03-26  2:47       ` Melanie Bacou
2015-03-26  9:52         ` Rasmus
2015-03-26 10:42           ` Rasmus
2015-03-28  8:26             ` Melanie Bacou

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=551370B3.1000709@mbacou.com \
    --to=mel@mbacou.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=rasmus@gmx.us \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).