From: Melanie Bacou <mel@mbacou.com>
To: emacs-orgmode@gnu.org
Subject: Re: [ox, patch] Add #+SUBTITLE
Date: Wed, 25 Mar 2015 22:38:06 -0400 [thread overview]
Message-ID: <mevrej$soj$2@ger.gmane.org> (raw)
In-Reply-To: <551370B3.1000709@mbacou.com>
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 <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
next prev parent reply other threads:[~2015-03-26 2:40 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
2015-03-26 2:38 ` Melanie Bacou [this message]
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='mevrej$soj$2@ger.gmane.org' \
--to=mel@mbacou.com \
--cc=emacs-orgmode@gnu.org \
/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).