[NTG-pdftex] Patch 391: Extending \pdfliteral

Hans Hagen pragma at wxs.nl
Mon Jul 18 00:51:34 CEST 2005


Hartmut Henkel wrote:

>Currently the \pdfliteral can be used with "direct" option, or without.
>In "direct" mode, the \pdfliteral text goes directly into the stream,
>wherever, without any coordinate transform. Without "direct" there is
>always an ET, and a transform.
>  
>
whow, i'm impressed by your testing of patches -)

>It seems that Acrobat does not allow grouping q...Q inside BT...ET
>sections (xpdf tolerates it). There is currently no way to guarantee
>that a literal text does not end up in a BT...ET section without using
>the plain \pdfliteral {} mode (without "direct"). But then one has
>the matrix transform, which precludes grouping; well, here is a funny
>counter-example:
>  
>
q Q deals with the graphic state only (mostly characteristics of line 
drawing, not that this is an excuse for acrobat fo rnot handling them -)

>\pdfcompresslevel=0
>\newbox\marbox
>\setbox\marbox\hbox{\qquad Hello}
>A%
>\pdfliteral {q}%
>  \rlap{%
>    \box\marbox
>  }%
>\pdfliteral {Q}%
>B
>\bye
>
>This gives:
>
>BT
>/F1 9.9626 Tf 91.9253 759.9271 Td[(A)]TJ
>ET
>1 0 0 1 99.3973 759.9271 cm
>q
>1 0 0 1 -99.3973 -759.9271 cm
>BT
>/F1 9.9626 Tf 119.3226 759.9271 Td[(Hello)]TJ
>ET
>1 0 0 1 99.3973 759.9271 cm
>Q
>1 0 0 1 -99.3973 -759.9271 cm
>BT
>/F1 9.9626 Tf 99.3973 759.9271 Td[(B)]TJ 204.112 -654.7472 Td[(1)]TJ
>ET
>
>It even comes out right :-) But when one could guarantee that the grouping
>does not end up in a BT...ET section, one could have such a simpler PDF
>output instead:
>
>BT
>/F1 9.9626 Tf 91.9253 759.9271 Td[(A)]TJ
>ET
>q
>BT
>/F1 9.9626 Tf 119.3226 759.9271 Td[(Hello)]TJ
>ET
>Q
>BT
>/F1 9.9626 Tf 99.3973 759.9271 Td[(B)]TJ 204.112 -654.7472 Td[(1)]TJ
>ET
>
>That's what the new "et" option of the appended tiny experimental patch
>does; it forces an ET if required, but without transform. In the patch
>also the internal literal() function interface is slightly changed to
>make a little more transparent what happens.
>  
>
maybe use 'text' instead of 'et'

>With this patch it seems to be roughly like the following:
>
>1. any color change without q/Q grouping just put into \pdfliteral direct
>{}. No transform will happen, resulting in minimum amount of PDF code.
>And this should hopefully be safe after bug 389 has gone.
>  
>
ok; q Q grouping does not make sense with colors anyway

>2. for grouping around TeX stuff use pairs of \pdfliteral et {}, or
>\special{pdf:et:...}. Grouping will be done outside BT...ET, no transform
>will happen.
>
>  
>
ok, so \pdfliteral et {Q}  % or \pdfliteral text {Q} -)

>3. for positioning of raw PDF graphics at the current point put it into
>\pdfliteral {} as usual.
>
>4. for positioning of raw PDF graphics with absolute positioning on the
>page relative to its lower left corner from everywhere on the page put
>it into \pdfliteral et {}.
>  
>
eh ... doesn't that mark it as BT ET ?

maybe add \pdfliteral graphics {...} as explicit variant for positioning 
relative to the lower leftcorner (i.e. obscure what happens with et)

>This is low-level stuff, should not interfere with a color stack.
>
>Would such an "et" option have its use?
>  
>
sure; we really need full control over that part (we should also make sure that dvipdfmx supports a similar model) 

Hans 

-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                             | www.pragma-pod.nl
-----------------------------------------------------------------



More information about the ntg-pdftex mailing list