TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to extract table data from a PDF. To this end, I need the precise locations of the beginning and end of a piece of text, and that's where my question comes in. For testing, I generated some text using LaTeX. Consider the following minimal example:


When compiled via latex -> dvips -> ps2pdf, I get (after decompression) the following PDF code, which looks fine:

10 0 0 10 0 0 cm          # concat to transformation matrix
BT                        # begin text mode
/R8 9.96264 Tf            # select font
1 0 0 1 148.68 657.24 Tm  # set text matrix
# ^ print 'f', then go a little bit left, print 'o' (so f and o
# overlap a bit), go a little bit right, print 'o'. Then go right again,
# for whatever reason.

But when using xelatex, it looks like this:

 1 0 0 1 72 720 cm  # concat a DIFFERENT transformation matrix
 0 G 0 g            # set gray levels to 0
 BT                 # begin text mode
 /F1 9.963 Tf       # select font
 76.71 -62.76 Td    # move to text position (this was missing above)
 [(fo)-28(o)]TJ     # print 'fo', then go 28 right, then print 'o'

What confuses me is the last line in the second output: How come that 'f' and 'o' overlap? Where is that specified? I don't see any 'Tc' commands or the such. And then how come that the second 'o' doesn't overlap with the first one?

Thanks a lot!

share|improve this question
If you add the initial shift (72,720) to the later shift (76.71,-62.76), you get (148.71,657.24) which is pretty much the same thing so no issues on the trafo matrix. – percusse Aug 5 '12 at 12:49
Thanks for pointing this out, I already expected something like that. What bugs me the most though is how the overlapping in "fo" is created from the second piece of code. – rainmaker Aug 5 '12 at 13:24
Try the word fizz (which should be corrected in both methods and maybe it helps. – percusse Aug 5 '12 at 13:58
This seems to be a different issue to me: "fizz" produces characters 'fi', 'z', 'z' where 'fi' is a ligature character. As it has a glyph associated, one can just retrive its width from the current font. "fo" does not have its own character, though. – rainmaker Aug 5 '12 at 14:58

Generating uncompressed files

Uncompressed files can be generated via TeX commands in case of pdfLaTeX or LuaLaTeX:


With XeLaTeX uncompressed files can be generated via the command line:

xelatex --output-driver="xdvipdfmx -V4 -z0" test

Route latex/dvips/ps2pdf:

ps2pdf -dCompressPages=false test.ps

Page streams



/F8 9.9626 Tf 148.712 707.125 Td [(fo)-28(o)]TJ



/F15 9.96264 Tf 1 0 0 1 148.712 707.125 Tm [(fo)-27(o)]TJ



 q 1 0 0 1 72 769.89 cm 0 G 0 g BT /F1 9.963 Tf 76.71 -62.76 Td[(fo)-28(o)]TJ ET



q 0.1 0 0 0.1 0 0 cm
/R7 gs
0 g
10 0 0 10 0 0 cm BT
/R8 9.96264 Tf
1 0 0 1 148.68 707.14 Tm


  • In neither case I can't see any overlapping of the glyph shapes.

  • There aren't any ligatures involved.

  • Additonal space is inserted between the two os. This is called implicit kerning and the data are looked up by TeX in the TFM file (cmr10.tfm). A negative number (−28) means that space is inserted inbetween. A positive number means that the glyph bounding boxes overlap.

  • Only in the case of latex/dvips/ps2pdf the f and the next o are moved a little bit closer by 0.00387556 (unit is per mill!), introduced by Ghostscript.

  • Your case of XeLaTeX differs from the finding here: 0 G 0 g is usually added by package color several times. Perhaps you have used a different TeX file with a package for color and cleaned up the PDF outcome. Check, whether you are also using different fonts.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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