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.