From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aankhen Subject: Re: Re: unnumbered subsections in latex export Date: Wed, 6 Apr 2011 00:37:21 +0530 Message-ID: References: <20110322051038.21655c80@kuru.homelinux.net> <80d3lj9wj6.fsf@somewhere.org> <20110322053134.669127e9@kuru.homelinux.net> <8999.1300804510@alphaville.dokosmarshall.org> <20110322160814.227fc53f@bhishma.homelinux.net> <27844.1300836065@alphaville.usa.hp.com> <8162r9hgxm.fsf@gmail.com> <87bp11dk4h.fsf@gnu.org> <3553.1300994702@alphaville.usa.hp.com> <80ipuut70z.fsf@somewhere.org> <80mxk5t340.fsf@somewhere.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from [140.186.70.92] (port=40180 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q7BbN-0004Uw-O3 for emacs-orgmode@gnu.org; Tue, 05 Apr 2011 15:07:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q7BbK-00074K-Qb for emacs-orgmode@gnu.org; Tue, 05 Apr 2011 15:07:45 -0400 Received: from mail-vw0-f41.google.com ([209.85.212.41]:60542) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q7BbK-000745-Jp for emacs-orgmode@gnu.org; Tue, 05 Apr 2011 15:07:42 -0400 Received: by vws4 with SMTP id 4so722648vws.0 for ; Tue, 05 Apr 2011 12:07:42 -0700 (PDT) In-Reply-To: <80mxk5t340.fsf@somewhere.org> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: =?UTF-8?Q?S=C3=A9bastien_Vauban?= , Org-mode ml Hi S=C3=A9bastien, 2011/4/5 S=C3=A9bastien Vauban : > 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 alte= r 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 ear= lier. > > I want to be able to say, in my Org file, that DNS is an acronym, for exa= mple. > I'm thinking -- brainstorming! -- at a solution _such as_ adding accolade= s > 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, whil= e > =C2=A0 others not -- this is customizable! > > 2. every occurrence would be a link to the list of acronyms, at the end o= f the > =C2=A0 document. > > In HTML, I would expect internal links to a list of acronyms at the end o= f the > document. > > I was thinking at preprocessing, because some smart things need to be don= e: > > - expanding the first occurrence of the acronym (if wished) with its > =C2=A0definition, not the following; > > - in the list, at the end of the document, only list acronym definitions = for > =C2=A0the acronyms that have been used in the document. Thank you for the clarifications. I=E2=80=99m going to talk a bit more abo= ut HTML as that=E2=80=99s 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: ,---- | HTML is a | language for marking up documents. The most current version | of HTML is 4.01. | The successor to HTML, 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=E2=80=99t. I would suggest that, were Org to gain support for acronyms and/or abbreviations, they be exported in HTML using =E2=80=98abbr=E2=80=99 (=E2= =80=98acronym=E2=80=99 is deprecated thanks to HTML5) with the =E2=80=98title=E2=80=99 defined for ea= ch 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=E2=80=99s 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=E2=80=99t be nested, can they? I=E2=80=99m th= inking of a situation like =E2=80=98read the HTML 4.01 specification online=E2=80=99, w= here the entire text is a link and =E2=80=98HTML=E2=80=99 is an abbreviation. I sup= pose this might not be a particularly important use case. > I would expect a similar treatment for the bibliography: having some buil= t-in > representation for that in Org, and have the exporters make it to both La= TeX > and HTML (and ...). I have no experience or opinions when it comes to bibliographies, so I=E2=80=99ll 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