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

[Hironobu Yamashita]

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.

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

Interestingly, Ulrike's example for pdfTeX is similar to [xdvipdfmx-B]:

  * [pdfTeX]
    -> Apple Preview app: OK
    -> Adobe Reader: whole blue page

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


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.
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.

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?


Kind regards,
Hironobu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20200301-pdfs.zip
Type: application/zip
Size: 26453 bytes
Desc: not available
URL: <https://tug.org/pipermail/tex-live/attachments/20200301/aba4f6c9/attachment-0001.zip>