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 -----------------------------------------------------------------