On Sun, Aug 3, 2014 at 3:59 PM, Akira Kakuto <kak...@fuk.kindai.ac.jp> wrote: > Hi Jiang, > > >> I have committed a better fix as r34805. > > > Thanks a lot, Jiang. It works fine for the example.
Anyone feel like trying out the following patches? https://gist.github.com/jjgod/0d4b6339d761a5423f82 Patch 1 will fix the ToUnicode generation for all non-subst glyphs in a non-XeTeX generated dvi. In our case, non-subst glyphs are the glyphs that are *NOT* changed by applying OpenType vertical layout features. To fix this I merely applied the same strategy I used to fix XeTeX generated PDF documents. It's a small change and should be safe to commit. In patch 2 I tried out a more interesting approach and it supersedes the efforts in patch 1: this patch utilize the cmap we provided in the map file to do CID -> Unicode lookup. In your test case the cmap is UniSourceHanSansJP-UTF16-V. To do this reverse lookup I have to extend CMap structure a little bit to store reverse mapping information, with that it's quite easy to simply generate ToUnicode stream with all used cids. The commit message has more details. Since these patches are relatively experimental I'm hesitate to commit them right away, would be nice if any of you can try it out or review them. With my limited testing it doesn't show any problem and we can produce perfectly copyable PDF from the sample.dvi in this test case. - Jiang -------------------------------------------------- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
