Hi, On Sat, Jul 19, 2014 at 3:12 PM, Akira Kakuto <[email protected]> wrote: > Dear Jiang Jiang , > > >> I will take a look at the warnings for non-CJK fonts. > > > Thanks. > In addition, I think it is necessary to refine for dvipdfmx. > The patched sources do not compile as "dvipdfmx".
Right, I can look into that. > My friend says that the present dvipdfmx can handle > Source Han Sans JP by translating the CMap > UniSourceHanSansJP-UTF32-H into UniSourceHanSansJP-UTF16-H. Yes, if you look at the logic there, it was trying to resolve the ToUnicode CMap by first attempting to load SourceHanSansJP-UTF16-H in texmf tree (with kpathsea), if this couldn't be found it will try SourceHanSansJP-UCS2-H instead, if that couldn't be found it will have to bail out. What I changed there is adding yet another fallback to use reverse SFNT CMap lookup (otf_create_ToUnicode_stream) to find the matching Unicode code points for used glyphs. It will certainly be better if SourceHanSansJP-UTF16-H can be found, or UniSourceHanSansJP-UTF32-H can be loaded by dvipdfm-x directly (it should support that anyway). But I just think this font should work out of the box, without requiring external mapping files to be present. I suppose we can't find such SourceHanSansJP-UTF16-H file embedded in the font itself? Then fallback to the brute force method (otf_create_ToUnicode_stream) is the only way I can think of. Of course I'm not familiar with CID-keyed fonts at all so I can be wrong. I'm always curious what would be the better way to gather such information, do you think I should just ask Dr. Ken Lunde about it? - Jiang -------------------------------------------------- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
