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: Marcin Borkowski
Subject: Re: [O] [ox, patch] Add #+SUBTITLE
Date: Mon, 23 Mar 2015 00:19:04 +0100

On 2015-03-22, at 23:43, Rasmus <address@hidden> wrote:

> Marcin Borkowski <address@hidden> writes:
>
>> [TL;DR: imho, the right way to do LaTeX export is to prepare a dedicated
>> package for Org-mode generated files (easy/medium), arrange for it to be
>> included in all major TeX distros (easy) and simplify the LaTeX exporter
>> to comply with it (easy).  This could greatly enhance the quality of
>> PDFs produced by Org-mode and make modifying their look easier on the
>> Org side.  I could do the LaTeX side of the work.  Now the question is:
>> does the community /want/ it.]
>
> I have a couple of initial concerns that you could address if your
> spin-off thread if you like.

Good questions!

> - Sat you can envision better code for a particular piece of org syntax.
>   Why is a better to have it in an external latex-package than directly in
>   the org files?  If it lives somewhere else, I have to bug you when I
>   want to change something.  What if you get bored of this?

The point would be to provide user-level ways to change the look.
Currently e.g. tags are hardcoded into the section titles, which is ugly
both in the LaTeX source and in the LaTeX output.  (Also, see below.)

> - What happens when you cannot maintain it any longer?  Note also that the

Either the project dies, or someone takes it over.  The latter seems to
be quite common in the LaTeX community, so I wouldn't be very worried.

>   scope is somewhat different as a typical latex package solves a problem
>   like "provide good tables" or "enhance itemize 2e" (ei2e).  Such
>   packages are fairly easy to replace (e.g. sugfigure → subcaption).

Fair enough.  Not a problem imho, though.  A “package” has a very wide
definition in the LaTeX world, and I explained why a package would be
better than a class (even though doing it as a package would be a bit
more work with ensuring that it works with wide range of classes).

> - I don't want latex code generated by org to a "special flavor" like with
>   LyX.

But the whole point is to have LaTeX code which is human-readable (and
human-modifiable).  Also, currently you have "special flavor" anyway -
just look at the preamble of Org-generated LaTeX files.  In my vision,
the huge preamble is replaced by \usepackage{orglatex} or something like
this, and instead of, say,

: \section{{\bfseries\sffamily TODO} hello\hfill{}\textsc{world}}

(how is that not a “special flavor”?) you would have

: \section{\orgtodo{TODO}hello\orgtags{world}}

or, if we decide to do a major surgery on LaTeX’s sectioning mechanism
(which is debatable), even

: \section[orgtodo=TODO,orgtags=world]{hello}

or something like this.  Note that I assume that the package would be
included in all major TeX distros, so the average LaTeX user wouldn't
even notice any change, apart from better markup.

> - Why can the issues you have in mind not be solved by a specialized
>   derived backend?  Such as ox-beamer or ox-koma-letter.

This seems to bug you enough that you basically asked twice;-).

As I said, people use Org-mode in various ways.  For some people, the
LaTeX export is something they use to produce a PDF.  For other people,
Org may be a quick authoring tool (faster and more comfortable than
AUCTeX, possibly), but after e.g. making a draft in Org they continue
their work in LaTeX (because LaTeX is just more powerful than Org when
it comes to typesetting proper).  For them, human-readable (and
editable) LaTeX code is a nice thing.

Also, adding some options in a LaTeX package seems to have less friction
than in Org.  In the former, you just code it and make a pull request to
the package maintainer (or send a patch, or even just file a feature
request).  In the latter, you bug Nicolas, and he has to think about the
impact of your feature request for other backends (because Org is not
LaTeX-centric!).

Probably most importantly, Org-mode is much more about the content, and
delegates the presentation issues to backends.  In case of HTML, you
have CSS, and it seems that everyone agrees that generating a suitable
CSS is outside Org-mode’s scope.  What I’m proposing here is very much
analogous to the HTML/CSS division: let Org produce a somewhat generic
LaTeX markup (like HTML), and let a LaTeX package (like CSS) decide what
to do with that visually.  Currently, due to hard-coding of things like
in the above example, it is plainly impossible.  And while HTML has ways
of “extending itself” built-in (thanks to element classes and divs and
spans), LaTeX does not have anything like that.  What I’m proposing is
(more or less) filling this gap.

Also, due to (sorry to repeat that) insane licensing requirements of
Org, making changes is much more frictionless on the LaTeX side of
things.

>
> Thanks,
> Rasmus


-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University



reply via email to

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