# odd displays of accentuated characters in lstlisting environment

when i try to write accentuated characters (éà...) in a lstlisting environment,

hence :

\documentclass{article}

\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}

\usepackage{xcolor}
\usepackage{listings}

\lstset{
language=bash,
extendedchars=\true,
inputencoding=utf8,
classoffset=0,
keywords={arg1},
keywordstyle=\color{red}\bfseries,
classoffset=1,
keywords={arg2},
keywordstyle=\color{blue}\bfseries,
}

\begin{document}

\begin{lstlisting}[title={syntaxe}]
\$ ln -s arg1 arg2
arg1 : chemin (relatif ou absolu) du répertoire ou du fichier pointé
arg2 : chemin (relatif ou absolu) du lien à créer
\end{lstlisting}

\end{document}


here's what i get :

note : it seems like the accentuated letters are placed before the non-accentuated ones.

My document uses UTF-8 encoding (from texworks settings)

I've tried to setup lstset setting extendedchars to \true and inputencoding to utf8. But this doesn't seem to apply any effects to the current code..

-
The accented à seems correct. Does the problem appear with any other character than é? –  T. Verron Feb 21 '13 at 9:42
@T.Verron eèéàe is rendered as èéàee (it seems like the accentuated letters are placed before non-accentuated ones) –  발렌탕 Feb 21 '13 at 9:48

The listings package doesn't handle UTF-8, only one-byte characters. You have to use the listingsutf8 package, which works only with the \lstinputlisting command, not with the lstlisting environment.

You'll have to change the inputencoding option in your \lstset command such as:

\lstset{inputencoding=utf8/latin9}


This is needed by the listingsutf8 package to convert multibyte UTF-8 characters to one-byte characters. As I suspect you're French, latin9 is a good choice. For other languages, other one-byte character sets might be more appropriate.

Check listingsutf8 documentation for details.

-
the same trouble occurs using this package. –  발렌탕 Feb 21 '13 at 10:09
You also need in your preamble: \lstset{inputencoding=utf8/latin9} –  Marc Baudoin Feb 21 '13 at 10:12
According to listings documentation, utf8 encoding should be usable with extendedchars=false, that is by letting inputenc handle these chars instead of listings. While it indeed doesn't work in this very case, I wouldn't say it is a design choice. –  T. Verron Feb 21 '13 at 10:16