[NTG-pdftex] problem of acrobat reader 4.0 or pdftex?

Heiko Oberdiek oberdiek at uni-freiburg.de
Thu Feb 8 23:57:19 CET 2007


On Thu, Feb 08, 2007 at 11:16:02PM +0100, Hartmut Henkel wrote:

> On Thu, 8 Feb 2007, w.m.l at gmx.net wrote:
> 
> > On 07.02.2007 10:45, Thanh Han The wrote:
> > > while viewing the microtype manual (from texlive2007) using
> > > acr4.0 on linux, I found some oddities as shown here:
> >
> > Same under Windows, Acrobat Reader 4.05. Additionally, the page numbers
> > on the right-hand side in the TOC are completely mis-aligned.
> >
> > It appears fine when created with (miktex's) pdftex 1.30.
> 
> this still uses \pdfliteral {} without "direct", so you find (lengthy)
> coordinate transforms like this around color change commands in the PDF:
> 
> 1 0 0 1 498.65 487.517 cm
> 0 g 0 G
> 1 0 0 1 -338.982 -13.027 cm
> 0.02 0.04 0.48 rg 0.02 0.04 0.48 RG
> 1 0 0 1 -159.668 -474.49 cm
> 
> With pdftex-1.40 now hyperref seems to use the more compact \pdfliteral
> direct {} version.

You mean pdftex.def? If pdfTeX 1.40 is detected the color stack
is used. The default main color stack is using "direct".

> > With 1.40, it looks OK if I set hyperref's colorlinks option to false
> > (ie., have the links surrounded by boxes instead of coloured).
> 
> then the color change commands between the []TJ sections go away. It
> appears that acro4.0 doesn't like legal PDF like this:
> 
> 0 g 0 G
> /F51 8.9664 Tf 22.908 -11.955 Td [([)]TJ
> 0.02 0.04 0.48 rg 0.02 0.04 0.48 RG
>  [(Protrusion)]TJ
> 0 g 0 G
>  [-343(\025)-342(49])-370([)]TJ
> 0.02 0.04 0.48 rg 0.02 0.04 0.48 RG  % <--- acro4.0 bug with these lines
>  [(Expansion)]TJ
> 0 g 0 G
>  [-343(\025)-342(56])-371([)]TJ
> 0.02 0.04 0.48 rg 0.02 0.04 0.48 RG
>  [(In)29(terw)28(ord)-342(Spacing)-343(\050Glue\051)]TJ

\documentclass{article}
\usepackage{color}
\begin{document}
Hello \textcolor{red}{World}!
\end{document}

stream
0 g 0 G
0 g 0 G
BT
/F8 9.9626 Tf 148.712 657.235 Td [(Hello)]TJ
1 0 0 rg 1 0 0 RG
 [-333(W)83(orld)]TJ
0 g 0 G
 [(!)]TJ
0 g 0 G
 154.421 -567.87 Td [(1)]TJ
0 g 0 G
ET
endstream

Without direct:

\documentclass{article}
\usepackage{color}
\makeatletter
\chardef\main at pdfcolorstack=\pdfcolorstackinit page{0 g 0 G}\relax
\makeatother

stream
1 0 0 1 133.768 692.105 cm
0 g 0 G
1 0 0 1 343.711 0 cm
0 g 0 G
1 0 0 1 -477.479 -692.105 cm
BT
/F8 9.9626 Tf 148.712 657.235 Td [(Hello)]TJ
ET
1 0 0 1 174.449 657.235 cm
1 0 0 rg 1 0 0 RG
1 0 0 1 -174.449 -657.235 cm
BT
/F8 9.9626 Tf 174.449 657.235 Td [(W)83(orld)]TJ
ET
1 0 0 1 201.044 657.235 cm
0 g 0 G
1 0 0 1 -201.044 -657.235 cm
BT
/F8 9.9626 Tf 201.044 657.235 Td [(!)]TJ
ET
1 0 0 1 133.768 89.365 cm
0 g 0 G
1 0 0 1 -133.768 -89.365 cm
BT
/F8 9.9626 Tf 303.133 89.365 Td [(1)]TJ
ET
1 0 0 1 477.479 89.365 cm
0 g 0 G
endstream

A lot of senseless positioning. Probably "\pdfliteral page"
would be better. Unhappily I wasn't aware of this implementing
the color stack. Keyword "page" after \pdfcolorstackinit does mean
a different issue. Only "direct" is supported:

  \pdfcolorstackinit [page] [direct] ...

"page" means that the stack emits the current stack value at start of
a new page. "direct" means the same behaviour as "\pdfliteral direct".

pdf_colorstack_init_code:
  begin
    bool := scan_keyword("page");
    if scan_keyword("direct") then
        cur_val := direct_always
    else
        if scan_keyword("page") then
            cur_val := direct_page
        else
            cur_val := set_origin;

This would also support:

  \pdfcolorstackinit [page] [page] ...

\pdfcompresslevel=0
\documentclass{article}
\usepackage{color}
\makeatletter
\chardef\main at pdfcolorstack=\pdfcolorstackinit page page{0 g 0 G}\relax
\makeatother

\begin{document}
Hello \textcolor{red}{World}!
\end{document}

stream
0 g 0 G
0 g 0 G
BT
/F8 9.9626 Tf 148.712 657.235 Td [(Hello)]TJ
ET
1 0 0 rg 1 0 0 RG
BT
/F8 9.9626 Tf 174.449 657.235 Td [(W)83(orld)]TJ
ET
0 g 0 G
BT
/F8 9.9626 Tf 201.044 657.235 Td [(!)]TJ
ET
0 g 0 G
BT
/F8 9.9626 Tf 303.133 89.365 Td [(1)]TJ
ET
0 g 0 G
endstream

However, the second page cannot be given without the first, thus
I suggest renaming the second page:

\pdfcolorstackinit [page] [direct|directpage] ...

page: see above
direct: see above
directpage: same behaviour as "\pdfliteral page"

pdf_colorstack_init_code:
  begin
    bool := scan_keyword("page");
    if scan_keyword("direct") then
        cur_val := direct_always  
    else
        if scan_keyword("directpage") then
            cur_val := direct_page  
        else
            cur_val := set_origin;

This can be done safely, because it doesn't change the documented
behaviour.

And if the default color stack should be using direct_page instead
of direct_always, then utils.c is the right place:

-    colstacks[0].literal_mode = DIRECT_ALWAYS;
+    colstacks[0].literal_mode = DIRECT_PAGE;

(But using DIRECT_ALWAYS isn't a bug, the PDF code is correct.)

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


More information about the ntg-pdftex mailing list