[pdftex] [NTG-pdftex] different rendering of pdftex-generated document in AR4 and AR7

Heiko Oberdiek oberdiek at uni-freiburg.de
Fri Jun 1 08:46:26 CEST 2007


On Thu, May 31, 2007 at 07:16:59PM -0700, Vladimir Volovich wrote:

> i'm reporting a problem (found not by me). consider this document:
> 
> =====================================
> \documentclass{article}
> \usepackage{color}
> \begin{document}
> 
> \makebox[2cm][r]{c}\hspace{-2cm}ab
> 
> \makebox[2cm][r]{c}\hspace{-2cm}a\textcolor{red}{b}
> 
> \end{document}
> =====================================
> 
> when processed with pdflatex, the generated PDF file is rendered
> differently by Acrobat Reader 4 and 7 - see the attached files
> acro4.png and acro7.png.
> 
> Acrobat 4's rendering seems to be buggy, but i wonder whether it is a
> real bug in Acrobat 4 or it is caused by a buggy PDF generated by pdftex?

It's a bug in AR4. See thread `problem of acrobat reader 4.0 or pdftex?'
in mailing list `ntg-pdftex' in February 2007.

pdftex.def now writes the color directly without ending
text blocks and positioning -> "\pdfliteral direct{}" instead
of "\pdfliteral{}". Thus the page streams are smaller.
The outcome of the thread was that nowadays the people should
rather update their AR.

You can drop the keyword "direct" by:

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

"page" doesn't not have same meaning of \pdfliteral's keyword,
only the behaviour of "\pdfliteral{}" and "\pdfliteral direct{}"
are available for the color stack. I have suggested a new
keyword `directpage' for \pdfcolorstackinit to get the
behaviour of "\pdfliteral page{}" in the thread, but an answer
of the pdfTeX maintainers is still missing.

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


More information about the pdftex mailing list