On 2002-05-26 02:02:48 +0200, Heiko Oberdiek wrote:
look at the following simple LaTeX file:
\documentclass[a4paper]{article} \begin{document} \section{Hello World} The begin of the line\hfill the end of the line \end{document}
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 zero. * A box without any text is correctly displayed.
The start of the pdf page stream:
stream 1 0 0 1 124.802 706.129 cm BT /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 BT /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 fixed.
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 happy. 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 ---- end;
procedure pdf_begin_text; {begin a text section} + var temp_cur_h, temp_cur_v: scaled; begin 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; pdf_set_origin; + cur_h := temp_cur_h; + cur_v := temp_cur_v; pdf_print_ln("BT"); pdf_doing_text := true; pdf_f := null_font;
I'm just scanning through my pdftex mailbox and found this. What became of it? It certainly isn't in the source yet. Best regards Martin -- Martin Schröder, MS@ArtCom-GmbH.DE ArtCom GmbH, Grazer Straße 8, D-28359 Bremen Voice +49 421 20419-44 / Fax +49 421 20419-10