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. 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: \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. 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. 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. 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 {}. This is low-level stuff, should not interfere with a color stack. Would such an "et" option have its use? Regards, Hartmut
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 -----------------------------------------------------------------
On 2005-07-18 00:51:34 +0200, Hans Hagen wrote:
Hartmut Henkel wrote:
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 -)
I'm not sure I understand Hartmut correctly: "BT q Q ET" is not allowed, but "q BT ET Q" is (see Figure 4.1 and Table 4.1 in the PDF reference: special graphic state operators (q Q cm) are not allowed in Text objects). Are we talking about "BT q Q ET" or "q BT ET Q"? The first would be a pdfTeX bug. Best Martin -- http://www.tm.oneiros.de
Martin Schröder wrote:
On 2005-07-18 00:51:34 +0200, Hans Hagen wrote:
Hartmut Henkel wrote:
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 -)
I'm not sure I understand Hartmut correctly: "BT q Q ET" is not allowed, but "q BT ET Q" is (see Figure 4.1 and Table 4.1 in the PDF reference: special graphic state operators (q Q cm) are not allowed in Text objects). Are we talking about "BT q Q ET" or "q BT ET Q"? The first would be a pdfTeX bug.
not so much a pdftex bug as well as that users can use literals in such ways that make q Q's end up in BT ET's 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 -----------------------------------------------------------------
On Mon, 18 Jul 2005, Martin Schröder wrote:
On 2005-07-18 00:51:34 +0200, Hans Hagen wrote:
Hartmut Henkel wrote:
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 -)
I'm not sure I understand Hartmut correctly: "BT q Q ET" is not allowed,
this is what \pdfliteral et {} avoids
but "q BT ET Q" is
this is the new stuff that can be done with \pdfliteral et {} Regards, Hartmut
On Mon, 18 Jul 2005, Hans Hagen wrote:
Hartmut Henkel wrote:
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.
maybe use 'text' instead of 'et'
why "text"? it should _not_ put anything into a text object, so it's more a "notext". Would be "notext" better than "et"?
sure; we really need full control over that part (we should also make sure that dvipdfmx supports a similar model)
this should be rather easy once it's settled and tested. The \special stuff is there. Regards, Hartmut
Hartmut Henkel wrote:
maybe use 'text' instead of 'et'
why "text"? it should _not_ put anything into a text object, so it's more a "notext". Would be "notext" better than "et"?
probably, but it also takes more mem so maybe 'bet' from 'bt et' -) 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 -----------------------------------------------------------------
On Mon, 18 Jul 2005, Hans Hagen wrote:
That's what the new "et" option of the appended tiny experimental patch does; it forces an ET if required, but without transform.
maybe use 'text' instead of 'et'
ah, after Martin's hint to Figure 4.1 in the PDf ref. it means that \pdfliteral et {} puts stuff within the "page description level" so maybe another name for it could be \pdfliteral page {}? Regards, Hartmut
Hartmut Henkel wrote:
On Mon, 18 Jul 2005, Hans Hagen wrote:
That's what the new "et" option of the appended tiny experimental patch does; it forces an ET if required, but without transform.
maybe use 'text' instead of 'et'
ah, after Martin's hint to Figure 4.1 in the PDf ref. it means that \pdfliteral et {} puts stuff within the "page description level" so maybe another name for it could be \pdfliteral page {}?
makes sense 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 -----------------------------------------------------------------
participants (3)
-
Hans Hagen -
Hartmut Henkel -
Martin Schröder