Re: Re: unnumbered subsections in latex export

[Aankhen <aankhen@gmail.com>]

Hi Sébastien,

2011/4/5 Sébastien Vauban <wxhgmqzgwmuf@spammotel.com>:
> Aankhen wrote:
>> [snip]
>> Acronyms are natively supported in HTML. That is all.
>
> Thanks for reporting this. Wasn't aware of it. Though, that does not alter the
> need (at least, what I consider so) for acronyms handling in/from Org.
>
> Let's clarify what I'm talking about -- I know, I should have done it earlier.
>
> I want to be able to say, in my Org file, that DNS is an acronym, for example.
> I'm thinking -- brainstorming! -- at a solution _such as_ adding accolades
> around the acronyms:
>
> --8<---------------cut here---------------start------------->8---
> This paper talks about {DNS} clients and {DNS} servers...
> --8<---------------cut here---------------end--------------->8---
>
> In LaTeX, this should have to be translated to:
>
> --8<---------------cut here---------------start------------->8---
> This paper talks about \acro{DNS} clients and \acro{DNS} servers...
> --8<---------------cut here---------------end--------------->8---
>
> And the effects would be that:
>
> 1. the first occurrence of the acronym would be expanded in the PDF, while
>   others not -- this is customizable!
>
> 2. every occurrence would be a link to the list of acronyms, at the end of the
>   document.
>
> In HTML, I would expect internal links to a list of acronyms at the end of the
> document.
>
> I was thinking at preprocessing, because some smart things need to be done:
>
> - expanding the first occurrence of the acronym (if wished) with its
>  definition, not the following;
>
> - in the list, at the end of the document, only list acronym definitions for
>  the acronyms that have been used in the document.

Thank you for the clarifications.  I’m going to talk a bit more about
HTML as that’s where I have the most experience.  I am in agreement
with you when you say that builtin support for acronyms would be
useful (although I feel it would be good to generalize it to
abbreviations, if that can also be supported in other backends).  When
you have the following markup:

,----
| <acronym title="Hypertext Markup Language">HTML</acronym> is a
| language for marking up documents.  The most current version
| of <acronym title="Hypertext Markup Language">HTML</acronym> is 4.01.
| The successor to <acronym title="Hypertext Markup
| Language">HTML</acronym>, HTML5, is currently under development.
`----

The expansion is invisible by default; it shows up in a tooltip when
you hover over the text.  You can try a live example to see for
yourself.[1] In this way, the expansion is always there when you need
it (and you can distinguish between multiple terms sharing the same
acronym, should the need ever arise), but it takes up no space if you
don’t.

I would suggest that, were Org to gain support for acronyms and/or
abbreviations, they be exported in HTML using ‘abbr’ (‘acronym’ is
deprecated thanks to HTML5) with the ‘title’ defined for each
occurrence, and with CSS to ensure consistent rendering, along these
lines:

,----
| abbr { font-variant: small-caps; border-bottom: 1px dashed; cursor: help; }
`----

I can see the argument for having a list at the end and linking each
definition instead.  I feel that’s less convenient, however, as (a) it
means temporarily losing your place in the document and (b) bunched-up
anchors at the end of a document are a pain.  Of course,
alternatively, each acronym/abbreviation could be marked up only at
the first occurrence; that seems like it would be easy to implement as
a configuration option.

> For the readability of the Org buffer, and for the behavior that we could
> expect, maybe a new link type would make it?

The only thing is, links can’t be nested, can they?  I’m thinking of a
situation like ‘read the HTML 4.01 specification online’, where the
entire text is a link and ‘HTML’ is an abbreviation.  I suppose this
might not be a particularly important use case.

> I would expect a similar treatment for the bibliography: having some built-in
> representation for that in Org, and have the exporters make it to both LaTeX
> and HTML (and ...).

I have no experience or opinions when it comes to bibliographies, so
I’ll abstain from commenting beyond saying that it seems logical to
have a centralized database at least within an Org file. :-)

Aankhen

[1]: https://developer.mozilla.org/en/HTML/Element/acronym