Hi,
There has been a report
https://github.com/CTeX-org/ctex-kit/issues/286
(in Chinese)
in summary, fonts such as Source Han Sans/Serif encoded U+5B50 and
U+2F74 using the same glyph so that our reverse ToUnicode CMap
building seems to prefer U+2F74 which is not the expected result.
(U+2F74 is
Dear Jiang,
There has been a report
https://github.com/CTeX-org/ctex-kit/issues/286
% XeTeX
\XeTeXgenerateactualtext=1
\font\1="Source Han Sans SC"
\font\2="Source Han Serif SC"
\font\3="Microsoft YaHei"
{\1 孤立子 ABC} \par
{\2 孤立子 ABC} \par
{\3 孤立子 ABC} \par
\bye
I tested the above example
2017-06-12 9:38 GMT+02:00 Akira Kakuto :
> Dear Jiang,
>
> There has been a report
>>
>> https://github.com/CTeX-org/ctex-kit/issues/286
>>
>
> % XeTeX
> \XeTeXgenerateactualtext=1
> \font\1="Source Han Sans SC"
> \font\2="Source Han Serif SC"
> \font\3="Microsoft YaHei"
>
> {\1 孤立子 ABC} \par
> {\
% luatex-plain test.tex
% luatex-plain is in the ConTeXt
\font\1="SourceHanSansSC-Regular.otf"
\font\2="SourceHanSerifSC-Regular.otf"
\font\3="msyh.ttf"
{\1 孤立子 ABC} \par
{\2 孤立子 ABC} \par
{\3 孤立子 ABC} \par
\bye
In the case of "luatex-plain" in the ConTeXt package,
copy&paste was OK by Adobe Re
On Mon, Jun 12, 2017 at 12:38 AM Akira Kakuto
wrote:
> Dear Jiang,
>
> > There has been a report
> >
> > https://github.com/CTeX-org/ctex-kit/issues/286
>
> % XeTeX
> \XeTeXgenerateactualtext=1
> \font\1="Source Han Sans SC"
> \font\2="Source Han Serif SC"
> \font\3="Microsoft YaHei"
>
> {\1 孤立子
Hi Akira,
Let me quote the originator:
> I have tried some PDF viewers. With \XeTeXgenerateactualtext=1,
> Adobe Reader DC, Adobe Acrobat DC will give the correct result, while
> SumatraPDF v3.1.2, Windows Reader App (阅读器), Microsoft Edge and Microsoft
> Word 2016 will not.
> My OS is Windows
Hi Jiang,
So there might still be value to fix the ToUnicode map, don't you think?
I have an experimental patch at
https://github.com/jjgod/texlive/commit/f01557d549aaf27584f624fa540f6b4b05349bf3
in case you would like to build a w32tex binary for him to test.
I confirmed that after applying
Thank you for building this. I'm not familiar with w32tex, can users
replace the same file from their TexLive 2017 installation?
On Mon, Jun 12, 2017 at 3:31 PM, Akira Kakuto wrote:
> Hi Jiang,
>
>> So there might still be value to fix the ToUnicode map, don't you think?
>>
>> I have an experimen
Hi Jiang,
Thank you for building this. I'm not familiar with w32tex, can users
replace the same file from their TexLive 2017 installation?
Yes, I think that dvipdfmx.dll in the TeX Live 2017 can be replaced by
the new dvipdfmx.dll.
Best,
Akira
--
