[pdftex] AR5 "Fit visible" bug

Heiko Oberdiek oberdiek at ruf.uni-freiburg.de
Sun May 26 03:02:48 CEST 2002


look at the following simple LaTeX file:

\section{Hello World}
The begin of the line\hfill the end of the line

run it through pdflatex and view the result
in the new version 5 of AcrobatReader/Unix.
With the view mode "Fit visible" the result
is very poor. The visible area is misplaced
by a large amount.

Because "Fit visible" is my favourite view mode,
this misbehaviour would prevent me from using
AcrobatReader 5.  Therefore I experimented to detect
the cause of the problem:

* If there are lines (in the header, box around
  the page), then the right margin is correct
  calculated by AR, but the left margin is
* A box without any text is correctly displayed.

The start of the pdf page stream:

1 0 0 1 124.802 706.129 cm
/F17 14.346 Tf 0 0 Td
  [(1)-1125(H)1(ell)1(o)-375(W)94(orld)]TJ ...

The problem seems, that AR does not take the current
transfer matrix (CTM) into account, if it scans the
first Td operator in a BT..ET block while calculating
the visible area.

So the following fixes the problem in horizontal direction:

1 0 0 1 0 706.129 cm
/F17 14.346 Tf 124.802 0 Td
  [(1)-1125(H)1(ell)1(o)-375(W)94(orld)]TJ ...

Some experiments (switching the view in AR) show
that also the vertical component has to be

Therefore I have written a suggestion for a patch
of pdfTeX, TeX/texk/web2c/pdftexdir/pdftex.ch:

The "cm" command before "BT" is written
by pdf_begin_text in pdftexdir/pdftex.ch
by pdf_set_origin.  So the patch sets
the current position to the lower left
corner during the call of pdf_set_origin,
so that the "cm" commands moves to 0,0
before "BT". Then the parameter values
of the first "Td" will not be calculated
as "0 0", but contain the distance
to the lower left corner, so that AR5 is
  There remains some obscure calculation
errors, eg. the detection of the right
margin, if there is only a few words,
but for normal pages the AR5 should now
usable in "Fit visible" view.

If the example above is compiled with
dvips/ps2pdf or VTeX, then the pdf file
shows no such displacement.  So users will
think, that pdfTeX is not able to generate
code that can be viewed properly and not
consider this as clear bug of AR5.
Therefore I see no way to avoid such a fix.

Here my suggestion:

*** pdftex.ch.org       Sun May 26 00:04:44 2002
--- pdftex.ch   Sun May 26 00:04:53 2002
*** 1519,1527 ****
--- 1519,1534 ----

  procedure pdf_begin_text; {begin a text section}
+ var temp_cur_h, temp_cur_v: scaled;
      if not pdf_doing_text then begin
+         temp_cur_h := cur_h;
+         temp_cur_v := cur_v;
+         cur_h := 0;
+         cur_v := cur_page_height;
+         cur_h := temp_cur_h;
+         cur_v := temp_cur_v;
          pdf_doing_text := true;
          pdf_f := null_font;

Yours sincerely
  Heiko <oberdiek at uni-freiburg.de>

More information about the pdftex mailing list