From: Marcin Borkowski <mbork@wmi.amu.edu.pl>
To: emacs-orgmode@gnu.org
Subject: Re: Rationale for *text* -> \alert{text} for Beamer export?
Date: Thu, 2 May 2013 11:53:14 +0200 [thread overview]
Message-ID: <20130502115314.023e47db@aga-netbook> (raw)
In-Reply-To: <loom.20130502T044704-864@post.gmane.org>
Dnia 2013-05-02, o godz. 02:48:41
James Harkins <jamshark70@gmail.com> napisał(a):
> John Hendy <jw.hendy <at> gmail.com> writes:
>
> > Just wondering about the rationale behind using *bold* markup for
> > \textbf{} in LaTeX export and to \alert{} in Beamer. Was this a
> > frequently voiced request? I'm sure I can dig into this somewhere
> > and change it, but if the majority prefers bold (not saying they
> > do!), should that be the default?
> >
> > I'd prefer bold, personally. I don't like red table column titles
> > or in
> lists.
>
> I had asked the same question a while back, and I received some quite
> amusing replies about \alert being "the Beamer way"... which I
> promptly ignored and implemented my own hack to customize the LaTeX
> command for beamer to use for *bold text* (pasted as a git patch
> below).
So maybe consider \alert{...} being "the Beamer way" just like <strong>
being the HTML/CSS way.
> I'm reading Marcin's recommendations carefully, since now, for the
> first time, I need to learn more about tweaking LaTeX's output. I'm
> not sure I agree with all of that line of thought, though.
>
> ~~
> * Keeping that in mind, \alert{...} is /better/ than \textbf{...},
> just like \emph{...} is better than \textit{...}: it is semantic, not
> visual markup.
> ~~
>
> I can understand this rationale if the use case is to export from org
> to a LaTeX file, and then continue to work with the LaTeX file. In
> that case, you would want the exported LaTeX code to follow best
> practices and be "maintainable." I'd guess a more common use case for
> org export is to work exclusively with the org markup, and allow the
> exporter to use LaTeX as an intermediary, on the way to PDF. At least,
> this is how *I* use it; it doesn't really bother me if the LaTeX code
> produced by org uses semantic or visual markup. Where I need semantic
> markup (and I will, in my next article), I'll write the semantic
> markup in org.
Fair point. For me, Org-mode is more of a planner/outliner; using it
for markup/authoring seems awkward for me, since LaTeX is so
natural... But then, I've been using LaTeX for something like 12 years
(and plain TeX earlier). (One exception - for me - is authoring of
blog entries, and one day I'll play with an Oddmuse export...) And I
imagine that for quite a few people, maintainability of the LaTeX code
resulting from Org-mode export might be essential. And by
"maintainability", I mean one of two things: (1) possibility of further
work on the file by a human or (2) possibility of changing the
look-and-feel by just loading a package or a simple customization in
the preamble. For both cases, sticking as much as possible to semantic
markup in the exported code is crucial.
> I guess I look at this in a way that FAUST [1] uses c++ as an
> intermediary. You write the signal-processing graph in FAUST's own
> purely-functional language, which the FAUST compiler translates into
> c++ (with a variety of headers and wrappers for VST, OSX audio units,
> SuperCollider plug-ins etc.). The resulting c++ is a mess, from the
> standpoint of reading and maintenance, but you're not supposed to
> maintain that code by hand. You're supposed to go back to the FAUST
> code to make changes.
>
> org --> LaTeX -- PDF
> FAUST --> c++ --> DSP plugin
>
> But, going a step further, if semantic markup is what you need,
> wouldn't it be better to define a \newcommand wrapper for \textbf, and
> then tell org to export *bold* using the wrapper? That would assume
> that you can customize the string org uses for *bold*, which you can't
> at present... so maybe my hack has some use after all.
Fair point again. I think that the point is that - unlike HTML - you
have \emph{...} in LaTeX, but no \strong{...} (or \alert{...} - for
that you need beamer; strangley enough, in the beamerarticle class,
\alert{...} is mapped to \emph{...}). Now I guess I know the reason,
though it is only my suspicion and not knowledge.
You know, LaTeX is being advertised as being a "document preparation
system". But in fact it's not; it is a "scientific paper preparation
system", and more precisely a "computer science paper preparation
system". Everything else are add-ons (packages and classes in
LaTeX-speak). Even for maths publishing, pure LaTeX core is not
enough: you need at least amsmath/amssymb/amsfonts. So, with the focus
being on /printed/ documents in a scientific field, boldface in text is
a no-no; basically, the /only/ reasonable use for boldface (apart from
some vector notation, but I'm speaking about text, not formulae here)
is in titles etc., where we don't use \textbf{...} (or {\bfseries ...})
anyway, since they are already packaged in higher-level, semantic
macros like \section{...} or \title{...}/\maketitle etc.
Now with documents other than papers on computer science actually
printed on physical paper, things are different. But LaTeX (and again
- I mean core LaTeX2e, without additional packages etc.) simply does
not address that. I wouldn't be surprised, though, if LaTeX3 gets
\strong{...} or \alert{...} in the core some day.
> hjh
Best,
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University
next prev parent reply other threads:[~2013-05-02 9:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-01 14:17 Rationale for *text* -> \alert{text} for Beamer export? John Hendy
2013-05-01 15:00 ` Marcin Borkowski
2013-05-01 20:50 ` John Hendy
2013-05-01 21:41 ` Thomas S. Dye
2013-05-01 22:09 ` Marcin Borkowski
2013-05-02 10:44 ` Suvayu Ali
2013-05-02 2:48 ` James Harkins
2013-05-02 8:20 ` Nicolas Goaziou
2013-05-02 11:44 ` James Harkins
2013-05-02 9:53 ` Marcin Borkowski [this message]
2013-05-02 10:28 ` Suvayu Ali
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=20130502115314.023e47db@aga-netbook \
--to=mbork@wmi.amu.edu.pl \
--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).