German umlauts are OK, but ß appears as "SS"

Question

I'm writing a paper in German, and these are my settings for font:

\usepackage[utf8]{inputenc} % Required for inputting international characters
\usepackage[T1]{fontenc} % Use 8-bit encoding
\usepackage{zi4} % Pretty font for Source Code
\usepackage{kpfonts} % Use the Adobe Utopia font for the document
\usepackage{tgadventor}  % Font for the title page
\renewcommand\ttdefault{lmtt}
\renewcommand\familydefault{\rmdefault}

All ä, ö, ü appear OK, but the ß does not. The phrase in my TeX source code is "...eine größere API ...", but in PDF it looks like this:

I'm using XeTex version 3.14159265-2.6-0.999991 (TeX Live 2019/Debian) (preloaded format=xelatex), \write18 enabled.

==== Update ======

Just to answer @wipet and @Mico's questions:

Basically I'm pretty naive about LaTeX environment settings. Many years ago I used Eclipse on Windows for editing and building my papers. MikTex was in use, and that is why pdfTeX came into play.

Now I'm using Visual Studio Code + Latex Workshop on a Linux Mint box for building papers. The manual of that "LaTeX Workshop" says it works best with TeX Live, so I used TeX Live. But I did not know pdfTeX and TeX Live are two different things and they are not compatible. So you see the funny mix of settings.

Come on professors and classmates, why are we not using Markdown for papers...?

Ah, speaking of "palatino clone", I think the font "tgpagella" is more appropriate for that reputation? I used tgpagella for my Diplomarbeit, and I really liked it. But now I guess I'm not as sharp as before, and now I prefer the roundness and airy-ness of the kpfonts....

Answer 1

Since you're using XeLaTeX, you shouldn't be loading the fontenc, inputenc, and kpfonts packages. Instead, you should be loading the fontspec and kpfonts-otf packages.

The code below selects the packages to be loaded based on whether either pdfLaTeX, XeLaTeX, LuaLaTeX is in use. (If either XeLaTeX or LuaLaTeX is in use, care is also taken to match the x-heights across the serif, sans-serif, and monospaced fonts.) With this precaution in place, umlauts and the ß character are typeset correctly in all three cases.

Oh, I wouldn't run \renewcommand*\ttdefault{lmtt} under pdfLaTeX since it nullifies loading the zi4 package.

The following screenshot was obtained by executing the code below under XeLaTeX:

\documentclass{article} % or some other suitable document class
\usepackage{iftex}
\ifpdftex
  \usepackage[utf8]{inputenc}   
  \usepackage[T1]{fontenc} 
  \usepackage{kpfonts} % Palatino clone text (serif) and math font
  \usepackage{zi4}        % monospaced font (Consolas/Inconsolata)
  \usepackage{tgadventor} % sans-serif font (clone of ITC Avantgarde Gothic)
\else
  \usepackage{fontspec}
  \usepackage{kpfonts-otf}
  \setmonofont{Consolas}[Scale=MatchLowercase] % or some other suitable font
  \ifxetex
    \setsansfont{texgyreadventor}[%
      % Set the path as needed for your OS and TeX distribution:
      Path =/usr/local/texlive/2022/texmf-dist/fonts/opentype/public/tex-gyre/,
      Scale=MatchLowercase,
      Extension     = .otf,
      UprightFont   = *-regular,
      BoldFont      = *-bold,
      ItalicFont    = *-italic,
      BoldItalicFont= *-bolditalic]
  \else
    \setsansfont{TexGyre Adventor}[Scale=MatchLowercase] 
  \fi
\fi
%\renewcommand\ttdefault{lmtt} % why?? 
%\renewcommand\familydefault{\rmdefault}  % serves no discernible purpose
\begin{document}
das größere Übel
\sffamily
das größere Übel
\ttfamily
das größere Übel
\end{document}

Answer 2

The problem is in the fact, that first 256 slots of Unicode (which is roughly speaking the same as iso-latin1 encoding) differs from TeX 8bit encoding used in 90s, agreed at the conference in Cork, and named T1. The T1 encoding includes SS at the slot 223 but Unicode declares ß here. The reason for T1 was: the SS is uppercase of ß and the ß itself is at the slot 255 in T1: the difference of all slots of uppercase/lowercase letters in T1 is constant: 32.

There was special methods how to convert ß (slot 223) from iso-latin1 input encoding to the slot 255 from T1 encoding. A huge of fonts for TeX were created in T1 encoding in 90s. For example in LaTeX, the [latin1]{inputenc} package sets the ß as active character and converts it to \ss. The [T1]{fontenc} package defines the \ss macro as slot 255. If you have Unicode input (represented by UTF-8), then ß is two-byte character and [utf8]{inputenc} sets the first byte as active and converts these two bytes to \ss macro. But when you are using Unicode TeX engines (XeLaTeX or LuaLaTeX) then the [utf8]{inputenc} is ignored with the message:

Package inputenc Warning: inputenc package ignored with utf8 based engines.

so, ß isn't converted to \ss and it cannot be converted to T1 encoding. This is the core of your problem.

But now, we have Unicode engines: luatex, xetex, Unicode fonts and we need not to carry about this problem because ß on input is equal to ß in font.

The problem is visible very clearly when you use OpTeX without loading the Unicode font:

hello: ß
\bye

The result is hello: SS, because the T1 encoded font is preloaded into the format. And the log file and the terminal report the warning:

WARNING l.2: Unicode font was not loaded.

If you select Unicode font family, then the problem disappear:

\fontfam[adventor]
hello: ß
\bye

because ß on the input is ß in the font.