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: http://orgmode.org/manual/Special-symbols.html
Cheers,
Daniele
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
