From: Marcin Borkowski <mbork@wmi.amu.edu.pl>
To: Rasmus <rasmus@gmx.us>
Cc: emacs-orgmode@gnu.org
Subject: Re: [ox, patch] Add #+SUBTITLE
Date: Mon, 23 Mar 2015 00:19:04 +0100 [thread overview]
Message-ID: <87lhiotyc7.fsf@wmi.amu.edu.pl> (raw)
In-Reply-To: <87384w7iwy.fsf@gmx.us>
On 2015-03-22, at 23:43, Rasmus <rasmus@gmx.us> wrote:
> Marcin Borkowski <mbork@wmi.amu.edu.pl> 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
next prev parent reply other threads:[~2015-03-22 23:19 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 [this message]
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
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=87lhiotyc7.fsf@wmi.amu.edu.pl \
--to=mbork@wmi.amu.edu.pl \
--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).