emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [ox, patch] Add #+SUBTITLE


From: Melanie Bacou
Subject: Re: [O] [ox, patch] Add #+SUBTITLE
Date: Wed, 25 Mar 2015 22:38:06 -0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

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 <address@hidden> writes:

Nicolas Goaziou <address@hidden> 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 address@hidden
Visit www.harvestchoice.org




reply via email to

[Prev in Thread] Current Thread [Next in Thread]