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

[Shunsaku Hirata]

Dear Hironobu,

2020年3月1日(日) 8:36 Hironobu Yamashita <h.y.acetaminophen at gmail.com>:
>
> Hi all,
>
> SH> if we try to fix the fake-bold issue by explicitly specifying Text Rendering
> SH> Mode it may happen to overwrite the setting done by
> SH>
> SH>   \special{pdf:code q 7 Tr} % add text path to clipping path
>
> First we should note that the behavior depends heavily
> on which PDF viewer to use.

It should not be. If some viewers behave differently then it can simply mean
that there is a bug in such viewers.

> Let's call two different xdvipdfmx as follows:
>
>   * [xdvipdfmx-A] with text enclosing with q..Q
>       (= r53972, before the revert)
>   * [xdvipdfmx-B] with adding 0 Tr
>       (= r53973 + proposed patch)
>
> Then, with the "combined example for XeTeX" proposed by Shunsaku:
>
>   * [xdvipdfmx-A]
>     -> Apple Preview app: whole blue page
>     -> Adobe Reader: whole blue page
>   * [xdvipdfmx-B]
>     -> Apple Preview app: OK
>     -> Adobe Reader: whole blue page

I can't confirm Apple Preview app's rendering but Adobe Reader's behavior
looks correct as far as I can see from the generated PDF.

> Interestingly, Ulrike's example for pdfTeX is similar to [xdvipdfmx-B]:
>
>   * [pdfTeX]
>     -> Apple Preview app: OK
>     -> Adobe Reader: whole blue page

I think Adobe Reader's rendering is correct again. This example is more
complicated than Alexander's one and is not just for text path clipping.
Apple Preview app seems having one more problem here...

> though this example contains addition of "embolden text" to clipping path
> which shoule be "forgotten" according to Shunsaku.
> (All three PDF files are attached)

I mean it is not possible to add clipping path of "embolden text outline" by
doing

  7 Tr 2Tr 1 w BT ...text description goes here... ET

When "emblolden text" is requested, dvipdfmx reset the TR mode to 2 by
inserting "2 Tr" without knowing the existence of "7 Tr".

> SH> It's OK if the proposed patch is meant to work only for the case where
> SH> the ocgx2 package is never used together with the fake-bold feature,
>
> Yes, my patch is meant as such.

OK, we should warn everyone not to use fake-bold (embolden text) together
with the ocgx2 package.

> I agree that it is difficult to have those two at the same time;
> actually I know that my proposal [xdvipdfmx-B] will break ocgx2 package
> after any occurrence of fake-bold.  However, even with [xdvipdfmx-A],
> ocgx2 package would need revised to add an extra Q..q to make "7 Tr"
> work again; moreover, we would get into a mess as the package can't say
> which version of xdvipdfmx is in use.

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.

> As Shunsaku said before:
>
> SH> Just my personal opinion but as I don't like this fake-bold feature
> SH> although it was added by myself, I rather want to make this feature
> SH> obsolete...
>
> I see your point; from this point of view, I'd like to take [xdvipdfmx-B]
> as its behavior is similar to pdfTeX and it would not get another mess.
> Shunsaku, what do you think?

I don't oppose to choose similar behavior to pdfTeX but replying on such
feature like pdf:code itself is a mess: Whenever internal behavior of dvipdfmx
is changed the reslts can be quite different.

The fake-bold feature was added about 15-years back when there is virtually
no (freely) available Japanese font with multiple weight. I don't know if there
still is any need for this nowadays.


Thanks,
Shunsaku Hirata