xdvipdfmx-20200116 : additional q/Q bracket around BT...ET

[Shunsaku Hirata]

Dear David,

Putting aside its feasibility, I believe having dedicated commands which is
carefully constructed is always better for every purpose.

As I mentioned before, relying on "pdf:code" is not good idea since it is
very fragile. The following "slightly different" example can give totally
different results depending on the actual implementation of the btrans/etrans
transformation command. It currently doesn't work "as expected".


\special{pdf:code q 7 Tr} % add text path to clipping path
\special{pdf:btrans scale 1.01}
Text in rendering mode `for clipping'.
\special{pdf:etrans}
\special{pdf:code 0 0 1 RG 0 0 1 rg -88888 -88888 99999 99999 re f Q}
% fill text clipping path

Normal Text (rendering mode `fill').

\bye


However, as I expect normal users would spend most of their time for
writing sentences instead of clipped text, blinking text, and other funny
graphics, we should carefully consider what is essentially required to
avoid unnecessarily increasing maintenance cost.

For clipped text, it might be difficult to manage so that it always work
even when other special commands are combined.


Thanks,
Shunsaku Hirata

2020年3月2日(月) 3:25 David Carlisle <d.p.carlisle at gmail.com>:
>
>
>
> 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