[tex-live] Missing Ligatures after 'dvips -Ppdf'

George N. White III gnwiii at gmail.com
Mon May 4 11:45:25 CEST 2009

On Mon, May 4, 2009 at 4:27 AM, Uwe Siart <uwe.siart at tum.de> wrote:
> Dear all,
> in recent texlive with kpfonts v3.02 all ff-Ligatures are missing in the
> .ps output when the 'Ppdf' option is used with dvips. A minimal example
> to reproduce the defect is
> % ---------------------------
> \documentclass{scrartcl}
> \usepackage[latin1]{inputenc}
> \usepackage[T1]{fontenc}
> \usepackage{kpfonts}
> \begin{document}
>  Koffer
> \end{document}
> % ---------------------------
> It appears that this is due to character shifting enabled in config.pdf
> (option "G"). Comparison to MiKTeX shows that this option has been
> disabled there hence the problem does not appear in MiKTeX.

Character shifting was needed in the early days of PDF because acrobat
reader didn't handle some glyphs encoded with low values (the most
common example was math "minus", which is encoded as ASCII <NUL>
in the original TeX fonts.    For T1 encoding use:

dvips -Ppdf -G0 ...

See <http://www.tex.ac.uk/cgi-bin/texfaq2html?label=charshift>, which
addresses the appearance of incorrect glyphs when -G is used with fonts
using other than the original tex encodings, and says:

"The problem has been corrected in dvips v 5.90 (and later versions), which
should be available in any recent TeX distribution. "

Does this mean "dvips -G0 ..." currently produces output that works with
buggy viewers or that shifting is somehow turned off for fonts that aren't
OT1 encoded?

The dvips manual has:

‘-G*’ Shift non-printing characters (ASCII 0-32, 127) to
higher-numbered positions.
      This may be useful sometimes.

in dvipsk, output.c has:

 *   moving chars 0-32 and 127 to higher positions
 *   is desirable when using some fonts
int T1Char P1C(int, c)
  int tmpchr = c;
  if (shiftlowchars && curfnt->resfont) {
    if ((tmpchr <= 0x20)&&(tmpchr>=0)) {
      if (tmpchr < 0x0A) {
        tmpchr += 0xA1;
      else {
        tmpchr += 0xA3;
    else if (tmpchr == 0x7F) {
      tmpchr = 0xC4;
  if (curfnt->chardesc[tmpchr].flags2 & EXISTS)
    tmpchr = c ;
  return tmpchr;

> I'm unable to assess whether this is an issue with kpfonts 3.02 or
> whether character shifting is (in general) a risky action which should
> be avoided at all. Therefore I'd like to encourage you to check whether
> texlive should follow MiKTeX's modality and disable character shifting
> in config.pdf.

I doubt it is the fonts.  As for whether to change the default --
there may still
be buggy PDF viewers out there.  If you leave -G in, and use a T1 (cork) font,
then everyone sees problems in the output and the author will be reminded to
add -G0.  If you use OT1, only the few people using duff viewers would see
problems.   Perhaps by now the number of buggy viewers is so small that the
chances anyone will encounter problems is remote.

It seems to me the appropriate thing is to enable shifting only for appropriate,
e.g., OT1, encodings.

George N. White III <aa056 at chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia

More information about the tex-live mailing list