xdvipdfmx-20200116 : additional q/Q bracket around BT...ET
David Carlisle
d.p.carlisle at gmail.com
Sun Mar 1 19:25:33 CET 2020
On Sun, 1 Mar 2020 at 18:03, Shunsaku Hirata <shunsaku.hirata74 at gmail.com>
wrote:
nice explanation, thanks:-)
Would it work if instead of relying on literal pdf \special
\special{pdf:code q 7 Tr}
dvipdfmx has a specific
\special{pdf:startclippingsomething}
TEXT
\special{pdf:code -88888 -88888 99999 99999 re}
\special{pdf:endclippingsomething}
that way the driver would ""know" about the clip path and be responsible
for adding the q .... f Q so could then not add the inner q ... Q around
text in that case, perhaps....
David
Dear Zdenek,
>
> > > Adding an extra "Q..q" (I assume it is not a typo) does not help.
> (rather it
> > > makes generated PDFs corrupt)
> > > Let me explain the original problem: My version of fake-bold patch
> adds a
> > > q-Q block around the text section BT-ET, but as this q-Q block
> recovers the
> > > graphics state saved by "q" at the execution of "Q" operator, clipping
> path
> > > added in the BT-ET section is discarded. This is why my patch broke the
> > > ocgx2 package.
> >
> > It should work. You start by Q which pops out the state pushed by q.
> > You know that after your code Q will be added, hence your code must
> > end with q so that the added Q can pop anything. It is necessary to
> > pair correctly q a Q in order not to corrupt the graphic stack.
>
> Maybe you are talking about the trick to cancel out the effect of q-Q
> bracket
> which is automatically inserted for "pdf:put" command?
>
> I guess the change I made for fixing the fake-bold bug is misunderstood.
>
> Let me explain the problem reported by Alexander and the change I made
> for fixing the fake-bold bug which is the cause of the problem.
> Note that the behavior of "pdf:code" has not been changed at all.
>
> Input:
> \special{pdf:code q 7 Tr}
> TEXT
> \special{pdf:code -88888 -88888 99999 99999 re f Q}
>
> The old behavior (before the fake-bold bug fix) is to convert them to
> q 7 Tr
> BT --PDF code for drawing "TEXT"-- ET
> -88888 -88888 99999 99999 re f Q
>
> But after the fake-bold fix it became
> q 7 Tr
> q BT --PDF code for drawing "TEXT"-- ET Q
> -88888 -88888 99999 99999 re f Q
>
> The only change here is q-Q bracket inserted around BT-ET but the
> behavior of "pdf:code" has never changed.
>
> The change of "text rendering mode" via "7 Tr" should be there as before
> but the problem here is that the change of "clipping path" done in the
> block
> enclosed by BT and ET is lost due to q-Q bracket recently added.
>
> This addition of q-Q bracket around text block BT-ET does not affect
> graphics state chages such as color change which come into effect
> immediately when a graphics drawing operator is invokded but it affects
> clipping path construction. At the time when the fill operator "f" is
> executed,
> the clipping path should be that of "TEXT". But due to the "Q" operator
> added immediately after "ET" (after the fake-bold fix), it is lost.
> Due to which the whole page is filled with the current color. (for the
> original
> example it is explicitly blue)
>
>
> Thanks,
> Shunsaku Hirata
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tex-live/attachments/20200301/652fe9b7/attachment.html>
More information about the tex-live
mailing list.