problem of acrobat reader 4.0 or pdftex?
Hi, while viewing the microtype manual (from texlive2007) using acr4.0 on linux, I found some oddities as shown here: http://www.sendspace.com/file/25thl2 But the problem doesn't occur with acr7.0, xpdf or gv. So it's likely a bug of acr4 on linux? Thanh
On Wed, 7 Feb 2007, Thanh Han The wrote:
while viewing the microtype manual (from texlive2007) using acr4.0 on linux, I found some oddities as shown here:
http://www.sendspace.com/file/25thl2
But the problem doesn't occur with acr7.0, xpdf or gv. So it's likely a bug of acr4 on linux?
the file looks ok. Indication that it could be an acr4.0 problem are Notes 57 and 58 in Appendix H of the PDFRef 5th ed. Maybe it doesn't like these interspersed color changes. I guess they were formerly done without "direct" option. Would be interesting to see if without "direct" the problem goes away. Regards, Hartmut
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. 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). Regards, Robert
On Thu, 8 Feb 2007, w.m.l@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.
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 Regards, Hartmut
On Thu, Feb 08, 2007 at 11:16:02PM +0100, Hartmut Henkel wrote:
On Thu, 8 Feb 2007, w.m.l@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@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@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
participants (4)
-
Hartmut Henkel -
Heiko Oberdiek -
Thanh Han The -
w.m.l＠gmx.net