Documentation format

Daniele Nicolodi daniele at
Sun Feb 7 06:47:45 CET 2016

On 06/02/16 21:59, Robert J. Hansen wrote:
>>> (For the record: yes, I know why org-mode has trouble with i18n export
>>> to LaTeX.  Yes, it's a hard problem.  Yes, fixing it might not be worth
>>> the effort.  All of this is true.  None of it changes how annoyed I am
>>> by the bug, though.)
>> Do you happen to have links to the relevant bug reports, or other
>> documentation of the issues?
> I don't; for all I know nobody's reported it yet.  (If that's the case,
> I should.)  The problem stems from how orgmode assumes that downstream
> tools can parse UTF-8.  LaTeX way predates UTF-8 and requires that
> foreign symbols be composed using TeX escape sequences.  For orgmode to
> translate UTF-8 to LaTeX reliably would require it to keep track of an
> impractically large translation table: Greek characters, French,
> Cyrillic, grave and acute accents, circumflex composition, and more.
> LaTeX is unique among document processing systems in that it can
> effortlessly represent the correct orthography for the rock group Spinal
> Tap (which uses a Turkish dotless lowercase i and a Jacaltec umlauted
> n), but that comes with a steep price: namely, its near complete
> inability to handle Unicode like the rest of the world.

LaTeX handles utf8 encoded input files with \usepackage[utf8]{inputenc}
and on my system org-mode correctly produces utf8 encoded LaTeX files
using that directive. It works just fine for the non-ascii characters
contained in your examples a couple of messages up in the thread.

Can you be more precise in describing the problem?

I would also suggest to look into the org-entities facility as a way to
handle more complex cases:


More information about the Gnupg-users mailing list