# Inside code listing from file bad character placement

There is this problem where my native language (Lithuanian) characters don't show up in proper positions when used in code listing. This issue occurs even when listing from file. Normally used those special characters show up fine. For some reason those characters keep jumping back to start of word.

\documentclass[12pt]{article}
\usepackage{listings}
\usepackage[utf8x]{inputenc}
\usepackage[L7x]{fontenc}
\lstset{
extendedchars=false
}

\begin{document}
public KainųMatrica kainųMatrica \{ get; set; \}
\begin{lstlisting}
using System;

namespace L1
{
public class Kelias
{
public KainųMatrica kainųMatrica { get; set; }
public int Apsilankymai { get; protected set; }
private int dydis;
private int[] taškai;

public Kelias(int dydis = 1)
{
taškai = new int[dydis];
Apsilankymai = 0;
this.dydis = dydis;
}
\end{lstlisting}
\end{document}


• Pack­age list­ings does not sup­port files with multi-byte en­cod­ings such as UTF-8. The package listingsutf8 might be of interest to you. The question utf8x vs. utf8 (inputenc) might also be of interest. – Ulrich Diez Mar 6 at 20:40
• As an alternative: The package minted uses Pygments which has far superior UTF-8 support (also in highlighting). – TeXnician Mar 6 at 20:42

Quote from section 2.5 Special characters of the manual of the listings-package:

National characters If you type in such characters directly as characters of codes 128–255 and use them also in listings, let the package know it—or you’ll get really funny results. extendedchars=true allows and extendedchars=false prohibits listings from handling extended characters in listings. If you use them, you should load fontenc, inputenc and/or any other package which defines the characters.

→I have problems using inputenc together with listings. This could be a compatibility problem. Make a bug report as described in section 7 Troubleshooting.

The extended characters don’t cover Arabic, Chinese, Hebrew, Japanese, and so on—specifically, any encoding which uses multiple bytes per character.
Thus, if you use the a package that supports multibyte characters, such as the CJK or ucs packages for Chinese and UTF-8 characters, you must avoid letting listings process the extended characters. It is generally best to also specify extendedchars=false to avoid having listings get entangled in the other package’s extended-character treatment. If you do have a listing contained within a CJK environment, and want to have CJK characters inside the listing, you can place them within a comment that escapes to LATEX– see section 5.12 for how to do that. (If the listing is not inside a CJK environment, you can simply put a small CJK environment within the escaped-to-LATEXportion of the comment.) Similarly, if you are using UTF-8 extended characters in a listing, they must be placed within an escape to LaTeX. Also, section 9 has a few details on how to work with extended characters in the context of Λ.

Seems you wish to use utf8x/utf8 which is a multibyte-encoding and you wish to type national characters like "ų" directly.

You have extendedchars=false although the manual says that you need extendedchars=true for allowing the listings-package to handle such extended/national characters.

You use utf8x/utf8, which is a multibyte-encoding, although the manual says that you must avoid letting listings process characters that come from multibyte-encodings and are encoded by more than one byte.

You can do the following:

1. Don't set extendedchars=false but set extendedchars=true and
2. Make sure that the listings-package won't need to handle multibyte-characters by loading Heiko Oberdiek's listingsutf8-package which for the \lstinputlisting-command provides routines for converting from multibyte-encoding to a suitable single-byte encoding before actually feeding things to listings and
3. E.g., via the filecontents*-environment of the filecontents-package put the listing into a temporary file and insert that via the \lstinputlisting-command.

I don't have L7x-encoding on my system and I think utf8 is preferable to utf8x.

Therefore with the example below I used T1 as font-encoding and utf8 as input-encoding.

On your system you can test whether things work out with L7x and utf8x also.

\documentclass[12pt]{article}
\usepackage{listings}
\usepackage{listingsutf8}
\usepackage{filecontents}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
%\usepackage[utf8x]{inputenc}
%\usepackage{L7x]{fontenc}
\lstset{extendedchars=true}
% Don't do this as then you cannot type national characters
% in single-byte-encodings (characters 128-255) directly
% any more:
%\lstset{
%extendedchars=false
%}

\begin{document}
public KainųMatrica kainųMatrica \{ get; set; \}
\begin{filecontents*}{temp.tex}
using System;

namespace L1
{
public class Kelias
{
public KainųMatrica kainųMatrica { get; set; }
public int Apsilankymai { get; protected set; }
private int dydis;
private int[] taškai;

public Kelias(int dydis = 1)
{
taškai = new int[dydis];
Apsilankymai = 0;
this.dydis = dydis;
}
\end{filecontents*}
% ISO/IEC 8859-4 = Latin-4 is designed to cover
% Estonian, Latvian, Lithuanian, Greenlandic, and Sami.
% See: https://en.wikipedia.org/wiki/ISO/IEC_8859-4
\lstinputlisting[inputencoding=utf8/latin4]{temp.tex}%
\end{document}


Simpler (although a bit more tedious to complete, but it's a once and for all job): use literate.

\documentclass[12pt]{article}
\usepackage{listings}
\usepackage[utf8]{inputenc} % utf8x is outdated and unmaintained
\usepackage[L7x]{fontenc}
\usepackage{lmodern} % cmr doesn't support L7x

\lstset{
literate=%
{ų}{{\k{u}}}1%
{š}{{\v{s}}}1%
}

\begin{document}

public KainųMatrica kainųMatrica \{ get; set; \}

\begin{lstlisting}
using System;

namespace L1
{
public class Kelias
{
public KainųMatrica kainųMatrica { get; set; }
public int Apsilankymai { get; protected set; }
private int dydis;
private int[] taškai;

public Kelias(int dydis = 1)
{
taškai = new int[dydis];
Apsilankymai = 0;
this.dydis = dydis;
}
\end{lstlisting}

\end{document}