6

I believe this is related, but my issue is not math-specific. The problem is:

Output of MWE

%!TEX TS-program = xelatex
%!TEX encoding = UTF-8 Unicode

\documentclass[12pt]{article}

% PACKAGES

\usepackage{geometry}
\usepackage{fontspec}
\usepackage{xltxtra}
\defaultfontfeatures{Mapping=tex-text,Numbers=OldStyle}
\setromanfont[Mapping=tex-text]{Linux Libertine O}
\setsansfont[Scale=MatchLowercase,Mapping=tex-text]{Linux Biolinum O}
\setmonofont[Scale=MatchLowercase]{Linux Libertine Mono O}

\begin{document} % ==============================================================

\newfontfamily{\HT}{Hoefler Text}
\newfontfamily{\BV}{Baskerville}

When using  and transitioning from roman to \textit{italics} and back, \LaTeX\ appears to preserve character spacing at the baseline.

{\Huge It is more \textit{noticeable} in larger font sizes.}

{\Large\bfseries The problem persists at \textit{other} weights.}

\textsf{...also with Linux Biolinum, the {\itshape associated} sans-serif font.} {\tiny ← That one is \textit{really} noticeable!}

{\HT This does not appear to be a \textit{problem} in other typefaces.}

{\BV Where \LaTeX\ evidently \textit{preserves} character spacing at mid-ex-height or so.}

Some graphic (if contrived) examples:

Linux Libertine: l\textit{l}l

{\HT Hoefler Text: l\textit{l}l}

{\BV Baskerville: l\textit{l}l}

\end{document} 
5

When \textit{l}l is found, LaTeX adds the italic correction that should compensate for the change from a slanted font to an upright one.

Let's consider the following input:

\documentclass{article}
\usepackage{fontspec}
\setmainfont[Ligatures=TeX]{Linux Libertine O}
\newfontfamily{\HT}{Hoefler Text}
\newfontfamily{\BV}{Baskerville}


\begin{document}

\showboxbreadth=1000 \showboxdepth=1000 \tracingonline=1

\sbox0{\textit{l}l}\showbox0 \box0

\HT
\sbox0{\textit{l}l}\showbox0 \box0

\BV
\sbox0{\textit{l}l}\showbox0 \box0

\end{document}

The first line is just to turn on some diagnostic messages. Here's the relevant part of the output on the console:

> \box0=
\hbox(6.98+0.09999)x5.75
.\EU1/LinuxLibertineO(0)/m/it/10 l
.\kern 0.45
.\EU1/LinuxLibertineO(0)/m/n/10 l

! OK.
l.13 \setbox0=\hbox{\textit{l}l}\showbox0 
                                          \box0
? 
> \box0=
\hbox(7.255+0.21999)x5.93498
.\EU1/HoeflerText(0)/m/it/10 l
.\kern 0.665
.\EU1/HoeflerText(0)/m/n/10 l

! OK.
l.16 \setbox0=\hbox{\textit{l}l}\showbox0 
                                          \box0
? 
> \box0=
\hbox(6.71387+0.1367)x5.22949
.\EU1/Baskerville(0)/m/it/10 l
.\kern 0.43457
.\EU1/Baskerville(0)/m/n/10 l

! OK.
l.19 \setbox0=\hbox{\textit{l}l}\showbox0 
                                          \box0
? 

We see that for Linux Libertine the italic correction is 0.45pt, 0.665pt for Hoefler Text and 0.43457pt for Baskerville (note that the italic correction is character dependent, so it would be different if, say, ‘f’ was used instead of ‘l’).

With LuaLaTeX different figures are obtained: the italic correction turns out to be 0.65pt for Linux Libertine, 0.765pt for Hoefler Text and 0.53223pt for Baskerville.

So there's some different evaluation of the parameter in the two engines and it seems that XeTeX is less generous. The traditional TeX fonts have a specific parameter defined for each character, while XeTeX and LuaTeX must compute it from other data.

There is no “baseline spacing” or “mid-height spacing” involved; if the computed italic correction is too small, the slanted character will bump on the next one.

  • 1
    So, can it be tweaked? – commonhare Nov 17 '13 at 15:56
  • @commonhare I don't know; perhaps Khaled Hosny can say more. – egreg Nov 17 '13 at 16:32
  • The italic correction of non-TFM fonts in XeTeX is computed from glyph bounding box and is not configurable. – Khaled Hosny Nov 21 '13 at 17:56
  • @KhaledHosny That's what I suspected. It's probably an area that needs work: the computations done by luaotfload seem to give different results. – egreg Nov 21 '13 at 18:14
  • @egreg: XeTeX computation is very basic; if the glyph’s bounding box exceeds its width, then the italic correction is the difference of the two. Personally I think this info belongs to fonts themselves, but sadly there were no much interest last time (a while ago) this was proposed for OpenType. – Khaled Hosny Nov 21 '13 at 21:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.