Bug 1020941

I am running into the same problem here. Can we please push a fix for this ASAP?

I'm able to reproduce it without problem but I'm not too much clever from what I see from xelatex output and compile log. Had a look into sources where I see the "Not a CFF/OpenType font?" message on multiple places. And the error is apparently font format related.

While googling around I found this article:
http://tug.org/TUGboat/tb34-1/tb106tennent.pdf

from Bob Tennent. Fortunately Bob uses Fedora TeX Live and is active contributor so let me ask him.

Bob, do you see anything apparently wrong or do you see which font in particular could be a culprit?

Thanks,
Jindrich

Matteo,

For now, you can use "lualatex" instead of "xelatex". LuaTeX (still) works great.

The example doesn't load any font packages so the fonts that would be used are
the default LMRoman otf variants of Computer Modern which should be in /fonts/opentype/public/lm.  But if lualatex works, the fonts must be there. I've alerted Khaled Hosny, who is the xelatex guru. 

Bob T.

Created attachment 814551 [details]
test case log

Khaled reports:  

this is an xdvipdfmx error message, so one way to diagnose this is to
run xelatex with --no-pdf option, then process the resulting xdv file
with xdvipdfmx in verbose mode and see what font is breaking it.

I sent him the xdv file and he reports that it looks okay. I've sent him
the relevant otf file (lmroman10-regular.otf) from the Fedora distribution.
You may want to check the package that provides xdvipdfmx.

If one adds \usepackage{libertine} to the test file, it produces the same error message (trying to use completely different fonts).  So I'd say the issue must be in xdvipdfm.

Unfortunately LuaLaTeX doesn't work for me (for other reasons), besides being much slower.

Anyway, I was able to make XeLaTeX work again by downgrading it:

* rpm -e --nodeps texlive-kpathsea-lib
* yum downgrade texlive-xetex-bin texlive-xdvi-bin
* updmap-sys --enable Map utopia.map

I guess the last step is due to a completely unrelated problem, utopia.map is not enabled in the map files though it's installed via the texlive-utopia package; but since I use it, I need it enabled.

Now I have the following package versions installed:

texlive-kpathsea-lib-2013-0.5.20130608_r30832.fc20.x86_64
texlive-xdvi-bin-svn30088.0-0.5.20130608_r30832.fc20.x86_64
texlive-xetex-bin-svn30634.0-0.5.20130608_r30832.fc20.x86_64

So we can restrict our search to some kind of change introduced by their update to these versions:

texlive-kpathsea-lib-2013-1.20131014_r31898.fc20.x86_64
texlive-xdvi-bin-svn30088.0-1.20131014_r31898.fc20.x86_64
texlive-xetex-bin-svn30845.0-1.20131014_r31898.fc20.x86_64

I can’t reproduce this neither with TeX Live binaries, nor with myself built ones (not using Fedora), so it seems to be a Fedora-specific issue and I can’t debug it myself.

I am seeing this as well.  Here is the end of the strace output for xelatex:

32021 open("/usr/share/texlive/texmf-dist/fonts/opentype/public/lm/lmroman10-regular.otf", O_RDONLY) = 8
32021 fcntl(8, F_SETFD, FD_CLOEXEC)     = 0
32021 fstat(8, {st_mode=S_IFREG|0644, st_size=111536, ...}) = 0
32021 mmap(NULL, 111536, PROT_READ, MAP_PRIVATE, 8, 0) = 0x7f9fdb654000
32021 close(8)                          = 0
32021 open("/usr/share/texlive/texmf-dist/fonts/opentype/public/lm/lmroman10-regular.otf", O_RDONLY) = 8
32021 fstat(8, {st_mode=S_IFREG|0644, st_size=111536, ...}) = 0
32021 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9fdb653000
32021 lseek(8, 0, SEEK_SET)             = 0
32021 read(8, "OTTO\0\v\0\200\0\3\0000CFF \2iB\307\0\0\23\270\0\0\356\324GPOS"..., 4096) = 4096
32021 lseek(8, 4096, SEEK_SET)          = 4096
32021 close(8)                          = 0
32021 munmap(0x7f9fdb653000, 4096)      = 0
32021 open("/usr/share/texlive/texmf-dist/fonts/opentype/public/lm/lmroman10-regular.otf", O_RDONLY) = 8
32021 write(2, "\n", 1)                 = 1
32021 write(2, "** ERROR ** ", 12)      = 12
32021 write(2, "Not a CFF/OpenType font?", 24) = 24

This isn't very enlightening to me, but maybe it helps others.

For some reason xdvipdfmx on Fedora is failing to recognize CFF fonts as CFF fonts, I can reproduce this here (even with the Fedora shipped files that Bob kindly sent to me), so it must be an issue that manifests only with the Fedora built binary.

Happens to me as well.

texlive-xdvi-bin-svn30088.0-3.20131021_r31961.fc20

using 

--output-driver="xdvipdfmx -v"

gives

<[/usr/share/texlive/texmf-dist/fonts/opentype/public/libertine/LinLibertine_R.otf]@17.22pt<NATIVE-FONTMAP:[/usr/share/texlive/texmf-dist/fonts/opentype/public/libertine/LinLibertine_R.otf]/H/65536/0/0>
pdf_font>> Input encoding "Identity-H" requires at least 2 bytes.
pdf_font>> The -m <00> option will be assumed for "/usr/share/texlive/texmf-dist/fonts/opentype/public/libertine/LinLibertine_R.otf".

** ERROR ** Not a CFF/OpenType font?

Created attachment 831055 [details]
Makefile.am patch

I just go the same problem trying to compile a big xelatex project.

After digging into the xdvipdfm sources, I found there is a file named "cidtype0.c" that contains some #ifdef XETEX.

This file is shared between dvipdfm and xdvipdfm, but it's included in the libutil and not recompiled, so the XETEX ifdefs are never triggered.

So this is a simple build problem, and the attached Makefile.am patch solves it.

Note that after applying this patch, Makefile.in should be regenerated.

Created attachment 831056 [details]
Same patch with regenerated Makefile.in

This patch is the same as the first one, but with a patch that updates Makefile.in (so no regeneration is needed)

I hope Fedora is not really shipping the development version directly out of SVN tree, because the dvipdfm-x re-factoring have not been released nor finished. In TeX Live 2013 release dvipdfmx and xdvipdfmx had separate sources.

Note that I'm using update-testing on Fedora19 

=> texlive-xetex-bin-svn30845.0-2.20131019_r31948.fc19.x86_64

(In reply to Khaled Hosny from comment #16)
> I hope Fedora is not really shipping the development version directly out of
> SVN tree, because the dvipdfm-x re-factoring have not been released nor
> finished. In TeX Live 2013 release dvipdfmx and xdvipdfmx had separate
> sources.

Ditto.

I am going to file a bug but is just looking for duplicate before I do so.

In fact I found that with my problem, extracting xdvipdfmx out of texlive-2013-0.1.20130608_r30832.fc19.x86_64, and do this voodoo (I need to do LD_LIBRARY_PATH as libpoppler bumped in version):

LD_LIBRARY_PATH=/tmp/usr/lib64/:$LD_LIBRARY_PATH xelatex -output-driver=/tmp/usr/bin/xdvipdfmx  a.tex

works.

Yes, as you say, the dvipdfm-x re-factoring probably isn't ready for prime time yet.

Mine is bug 1045794, and the failure message is "** ERROR ** Unrecognized CIDFont Type".

Somebody please feel free to try the "-output-driver=<old-fc19-binary>" trick.

texlive-2013-4.20131226_r32488.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/texlive-2013-4.20131226_r32488.fc20

Package texlive-2013-4.20131226_r32488.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing texlive-2013-4.20131226_r32488.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-24101/texlive-2013-4.20131226_r32488.fc20
then log in and leave karma (feedback).

I update my texlive as you said, but the problem is still there:
version: texlive-2013-4.20131226_r32488.fc20.x86_64
file:
"
\documentclass{ctexart}
\begin{document}
　　　　This is a \TeX{} test file.
\end{document}
"

part of log:

----------------

*************************************************
* LaTeX warning: "xparse/redefine-command"
* 
* Redefining document command \fontfamily with arg. spec. 'm' on line 3353.
*************************************************
(/usr/share/texlive/texmf-dist/tex/xelatex/xecjk/config/xeCJK.cfg))
(/usr/share/texlive/texmf-dist/tex/latex/ctex/engine/ctex-cjk-common.def)
(/usr/share/texlive/texmf-dist/tex/latex/ctex/fontset/ctex-xecjk-winfonts.def))
) (/usr/share/texlive/texmf-dist/tex/latex/ctex/def/ctex-caption.def)
(/usr/share/texlive/texmf-dist/tex/latex/ctex/def/ctex-class.def)
(/usr/share/texlive/texmf-dist/tex/latex/ctex/def/ctex-article.def))
(/usr/share/texlive/texmf-dist/tex/latex/ctex/def/ctex-utf8.def)
(/usr/share/texlive/texmf-dist/tex/latex/ctex/cfg/ctexcap.cfg
(/usr/share/texlive/texmf-dist/tex/latex/ctex/cfg/ctexcap-utf8.cfg))
(/usr/share/texlive/texmf-dist/tex/latex/ctex/cfg/ctex.cfg) (./test.aux)
(/usr/share/texlive/texmf-dist/tex/latex/tipa/t3cmr.fd) [1] (./test.aux)
** ERROR ** Not a CFF/OpenType font?

------------------



(In reply to Fedora Update System from comment #21)
> Package texlive-2013-4.20131226_r32488.fc20:
> * should fix your issue,
> * was pushed to the Fedora 20 testing repository,
> * should be available at your local mirror within two days.
> Update it with:
> # su -c 'yum update --enablerepo=updates-testing
> texlive-2013-4.20131226_r32488.fc20'
> as soon as you are able to.
> Please go to the following url:
> https://admin.fedoraproject.org/updates/FEDORA-2013-24101/texlive-2013-4.
> 20131226_r32488.fc20
> then log in and leave karma (feedback).

(In reply to sunkins from comment #22)
> I update my texlive as you said, but the problem is still there:
> version: texlive-2013-4.20131226_r32488.fc20.x86_64
> file:
> "
> \documentclass{ctexart}
> \begin{document}
> 　　　　This is a \TeX{} test file.
> \end{document}

This works on my updated system, as well as the initial example. However, I rather think this is a very inappropriate test case, since ctexart requires SimSun/SimHei (the microsoft simplified chinese fonts), and therefore does not work as desired on any legally configured non-microsoft platforms, buggy xdvipdfmx or not. Since TeXLive runs on windows, them shipping something microsoft-specific is not an issue. However, commenting on a fedora bug issue with explicit dependency on acquiring (against legal license) MS fonts, is a problem. Please don't do that.

Anyhow, as I said, both examples work now with the updates-testing packages.

Sorry for bothering you.
I should say that i have installed(copied) the required fonts from my Windows system. The xelatex works fine on my fedora 17 laptop while failed on my fedora 20 PC. I guess the update has not completely solve the problem. 

(In reply to Hin-Tak Leung from comment #23)
> (In reply to sunkins from comment #22)
> > I update my texlive as you said, but the problem is still there:
> > version: texlive-2013-4.20131226_r32488.fc20.x86_64
> > file:
> > "
> > \documentclass{ctexart}
> > \begin{document}
> > 　　　　This is a \TeX{} test file.
> > \end{document}
> 
> This works on my updated system, as well as the initial example. However, I
> rather think this is a very inappropriate test case, since ctexart requires
> SimSun/SimHei (the microsoft simplified chinese fonts), and therefore does
> not work as desired on any legally configured non-microsoft platforms, buggy
> xdvipdfmx or not. Since TeXLive runs on windows, them shipping something
> microsoft-specific is not an issue. However, commenting on a fedora bug
> issue with explicit dependency on acquiring (against legal license) MS
> fonts, is a problem. Please don't do that.
> 
> Anyhow, as I said, both examples work now with the updates-testing packages.

(In reply to sunkins from comment #24)
> Sorry for bothering you.
> I should say that i have installed(copied) the required fonts from my
> Windows system. The xelatex works fine on my fedora 17 laptop while failed
> on my fedora 20 PC. I guess the update has not completely solve the problem. 

The update (su -c 'yum update --enablerepo=updates-testing texlive\*') do work. Please re-test. pdfinfo on newly generated pdf says:

Creator:         XeTeX output 2014.01.01:2045
Producer:       xdvipdfmx (20130624)
CreationDate:   Wed Jan  1 20:45:27 2014
Tagged:         no
Form:           none
Pages:          1
Encrypted:      no
Page size:      595.28 x 841.89 pts (A4)
Page rot:       0
File size:      5449 bytes
Optimized:      no
PDF version:    1.5

name                                 type              encoding         emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
KEHACO+LMRoman10-Regular-Identity-H  CID Type 0C       Identity-H       yes yes yes      5  0
QZRYWP+SimSun                        CID TrueType      Identity-H       yes yes yes      7  0

showing that it is indeed using SimSun.

However, your test case is very inappropriate on *fedora* bugzilla, since it requires a customized and legally dubious fedora system to run.

FWIW, the ctex-kit shipping with even the updates-testing texlive is out-dated and wrong; it loads "SimSun" by typeface name, but "SIMFANG.TTF", "SIMHEI.TTF", "SIMKAI.TTF" by *filename*
(see /usr/share/texlive/texmf-dist/tex/latex/ctex/fontset/ctex-xecjk-winfonts.def), so you must have the *uppercase*, and *filename* versions of those 3 fonts under .fonts (or the equivalent system locations under /usr/share/fonts) to work. Current ctex-kit upstream at http://ctex-kit.googlecode.com/svn seems to be wrong in a different way also - their developers do not seem to entirely windows based and do not understand how fontspec works, and do not understand the difference and distinction between loading a font by fontname and filename. It is a very important distinction on fontconfig based (i.e. linux and Mac OS X) systems. Loading a font by typeface name means fontconfig is free to do substitution with "compatible" fonts,
while loading fonts by filename (and UPPERCASE FILE NAMES) as that means it will usually fail unless there is an exact match.

I suggest you file an issue with both texlive and upstream at http://ctex-kit.googlecode.com/ about the confusion with loading fonts by font names (i.e. typeface names) vs file names, and also request that they supply an font definition configuration based on openly available fonts.

(In reply to Hin-Tak Leung from comment #25)
> (In reply to sunkins from comment #24)
...
> I suggest you file an issue with both texlive and upstream at
> http://ctex-kit.googlecode.com/ about the confusion with loading fonts by
> font names (i.e. typeface names) vs file names, and also request that they
> supply an font definition configuration based on openly available fonts.

WTF. I looked through the history of ctex-xecjk-winfonts.def on http://ctex-kit.googlecode.com/svn/, and they always have lowercase filenames, although they do not understand the distinction between loading fonts by typeface vs filename. The uppercase file name loading (and they do distinguish loading fonts by typeface vs filename with the [] quotes as per fontspec) is a TeXLive customization. So you should go and file two issues with the two parties, and a 3rd bug for font definitions based on open fonts.

OTOH, as I wrote earlier, if you have UPPERCASE FILENAME versions of SIMFANG.TTF  SIMHEI.TTF  SIMKAI.TTF  SIMSUN.TTC, in $HOME, and because SimSun is loading by typeface, SIMSUN.TTC *must* be the genuine Microsoft font, it does work correctly.

(In reply to Hin-Tak Leung from comment #26)
 > ... in $HOME, and because...

sorry typo, should be $HOME/.fonts .

(In reply to Hin-Tak Leung from comment #26)
> and do not understand the difference and
> distinction between loading a font by fontname and filename. It is a very
> important distinction on fontconfig based (i.e. linux and Mac OS X) systems.

The distniction is the same on all systems; loading fonts by file name will cause XeTeX to ask kpathsea library for that file name so only fonts known to kpathsea will be found, while loading fonts with font name will cause XeTeX to ask the system for that fonts, so only fonts known to the system will be found. XeTeX uses FontConfig on both Windows and Linux, but not Mac where Apple-specific API is used.

> Loading a font by typeface name means fontconfig is free to do substitution
> with "compatible" fonts,

This is not true, XeTeX uses FontConfig in a way that ensure not font substitution is done by it, so either the exact font the user asked for is found or an error will be raised.

> I suggest you file an issue with both texlive and upstream at
> http://ctex-kit.googlecode.com/ about the confusion with loading fonts by
> font names (i.e. typeface names) vs file names,


TeX Live is certainly not the place for such a bug report.

> and also request that they
> supply an font definition configuration based on openly available fonts.

But this should indeed be reported to TeX Live since it has a policy against packages that is only usable with non free software.

(In reply to Khaled Hosny from comment #28)
> (In reply to Hin-Tak Leung from comment #26)

it seems that you are quoting comment #25 rather than #26...

> ...The distniction is the same on all systems; loading fonts by file name will
> cause XeTeX to ask kpathsea library for that file name so only fonts known
> to kpathsea will be found, while loading fonts with font name will cause
> XeTeX to ask the system for that fonts...

Comparing /usr/share/texlive/texmf-dist/tex/latex/ctex/fontset/ctex-xecjk-winfonts.def and http://ctex-kit.googlecode.com/svn/trunk/ctex/fontset/ctex-xecjk-winfonts.def (and its history, lower case file name for the few versions I checked), it would appear that the ctex-kit developers do not understand the distinction between loading by name and loading by typeface; the texlive developers corrected that, but also simultaneously made a irrelevant change to all the file names to UPPERCASE, and did not feed the correction, nor communicated the zealous upper-case changes upstream; and their versions is rather out-of-date and also quite a lot of irrelevant changes compared to upstreams. So that's a bug report for each party.

...
> > and also request that they
> > supply an font definition configuration based on openly available fonts.
> 
> But this should indeed be reported to TeX Live since it has a policy against
> packages that is only usable with non free software.

Well, I don't think it is wrong for a package for TeX Live (on Windows) to defaults to and depends on the *availability* of microsoft fonts, or other microsoft bits.  Said package also ships ctex-xecjk-mac.def (which looks like it applies for mac and uses Mac OS X shipped fonts), and ctex-xecjk-adobe.def (intended to generating outputs relying on CJK capability in Adobe reader). I would just rather said package should default to load some other fonts when it runs on linux.

and as I stated a few times, it just isn't appropriate to refer to a test case in *fedora linux* bugzilla which certainly does not run on a *clean* fedora system of any past/present/future vintage. It is possible to customize one's system (in a legally dubious way) to run the test case successfully, but it is wrong for the commenter to expect the redhat developers to try to replicate that customization to see if the test case works or not. 

That said, I actually don't use ctex-kit myself - it looks rather poorly written - and don't really care one way or the other.

I think I have excluded the fonts problem for it works fine on my fedora 17 laptop
Here are the settings on my fedora 20 PC
********************************************

I make sure that the required fonts are installed in my fedora 20 where those font files are from my legal copy of Windows (though I am not sure if it is legal to use them in fedora).
here are the fonts:
--------------------------------
/usr/share/fonts/win/simsun.ttc: 宋体,SimSun:style=Regular
/usr/share/fonts/win/simhei.ttf: 黑体,SimHei:style=Regular,Normal,obyčejné,Standard,Κανονικά,Normaali,Normál,Normale,Standaard,Normalny,Обычный,Normálne,Navadno,Arrunta
/usr/share/fonts/win/simkai.ttf: 楷体,KaiTi:style=Regular,Normal,obyčejné,Standard,Κανονικά,Normaali,Normál,Normale,Standaard,Normalny,Обычный,Normálne,Navadno,Arrunta
/usr/share/fonts/win/simfang.ttf: 仿宋,FangSong:style=Regular,Normal,obyčejné,Standard,Κανονικά,Normaali,Normál,Normale,Standaard,Normalny,Обычный,Normálne,Navadno,Arrunta
/usr/share/fonts/win/SIMLI.TTF: 隶书,LiSu:style=Regular
/usr/share/fonts/win/SIMYOU.TTF: 幼圆,YouYuan:style=Regular

--------------------------------
and here is the file
/usr/share/texlive/texmf-dist/tex/latex/ctex/fontset/ctex-xecjk-winfonts.def
--------------------------------
% ctex-xecjk-winfonts.def: Windows 的 xeCJK 字体设置，默认为六种中易字体
% vim:ft=tex

\setCJKmainfont[BoldFont={SimHei},ItalicFont={KaiTi}] 
 {SimSun}
\setCJKsansfont{SimHei}
\setCJKmonofont{FangSong}

\setCJKfamilyfont{zhsong}{SimSun}
\setCJKfamilyfont{zhhei}{SimHei}
\setCJKfamilyfont{zhkai}{KaiTi}
\setCJKfamilyfont{zhfs}{FangSong}
\setCJKfamilyfont{zhli}{LiSu}
\setCJKfamilyfont{zhyou}{YouYuan}

\newcommand*{\songti}{\CJKfamily{zhsong}} % 宋体
\newcommand*{\heiti}{\CJKfamily{zhhei}}   % 黑体
\newcommand*{\kaishu}{\CJKfamily{zhkai}}  % 楷书
\newcommand*{\fangsong}{\CJKfamily{zhfs}} % 仿宋
\newcommand*{\lishu}{\CJKfamily{zhli}}    % 隶书
\newcommand*{\youyuan}{\CJKfamily{zhyou}} % 幼圆

\endinput

----------------------------------

********************************************

the authors of ctex has explained that they have to use those Windows fonts because there are no proper east asian character fonts for industrial typing and printing in Linux, and for good type setting, they chose to use the Windows fonts.


(In reply to Hin-Tak Leung from comment #26)
> (In reply to Hin-Tak Leung from comment #25)
> > (In reply to sunkins from comment #24)
> ...
> > I suggest you file an issue with both texlive and upstream at
> > http://ctex-kit.googlecode.com/ about the confusion with loading fonts by
> > font names (i.e. typeface names) vs file names, and also request that they
> > supply an font definition configuration based on openly available fonts.
> 
> WTF. I looked through the history of ctex-xecjk-winfonts.def on
> http://ctex-kit.googlecode.com/svn/, and they always have lowercase
> filenames, although they do not understand the distinction between loading
> fonts by typeface vs filename. The uppercase file name loading (and they do
> distinguish loading fonts by typeface vs filename with the [] quotes as per
> fontspec) is a TeXLive customization. So you should go and file two issues
> with the two parties, and a 3rd bug for font definitions based on open fonts.
> 
> OTOH, as I wrote earlier, if you have UPPERCASE FILENAME versions of
> SIMFANG.TTF  SIMHEI.TTF  SIMKAI.TTF  SIMSUN.TTC, in $HOME, and because
> SimSun is loading by typeface, SIMSUN.TTC *must* be the genuine Microsoft
> font, it does work correctly.

(In reply to sunkins from comment #30)
> I think I have excluded the fonts problem for it works fine on my fedora 17
> laptop
> Here are the settings on my fedora 20 PC
> ********************************************
> 
> I make sure that the required fonts are installed in my fedora 20 where
> those font files are from my legal copy of Windows (though I am not sure if
> it is legal to use them in fedora).
> here are the fonts:
> --------------------------------
> /usr/share/fonts/win/simsun.ttc: 宋体,SimSun:style=Regular
> /usr/share/fonts/win/simhei.ttf:
> 黑体,SimHei:style=Regular,Normal,obyčejné,Standard,Κανονικά,Normaali,Normál,
> Normale,Standaard,Normalny,Обычный,Normálne,Navadno,Arrunta
> /usr/share/fonts/win/simkai.ttf:
> 楷体,KaiTi:style=Regular,Normal,obyčejné,Standard,Κανονικά,Normaali,Normál,
> Normale,Standaard,Normalny,Обычный,Normálne,Navadno,Arrunta
> /usr/share/fonts/win/simfang.ttf:
> 仿宋,FangSong:style=Regular,Normal,obyčejné,Standard,Κανονικά,Normaali,Normál,
> Normale,Standaard,Normalny,Обычный,Normálne,Navadno,Arrunta
> /usr/share/fonts/win/SIMLI.TTF: 隶书,LiSu:style=Regular
> /usr/share/fonts/win/SIMYOU.TTF: 幼圆,YouYuan:style=Regular
> 
> --------------------------------
> and here is the file
> /usr/share/texlive/texmf-dist/tex/latex/ctex/fontset/ctex-xecjk-winfonts.def
> --------------------------------
> ...

What you show is certainly not the /usr/share/texlive/texmf-dist/tex/latex/ctex/fontset/ctex-xecjk-winfonts.def from fedora updates-testing . 
The one shipped by updates-testing have UPPERCASE FILENAMES inside. Also your configuration in /usr/share/fonts/win/ is wrong, since it requires filenames to be in UPPERCASES. 

$rpm -qf /usr/share/texlive/texmf-dist/tex/latex/ctex/fontset/ctex-xecjk-winfonts.def
texlive-ctex-svn22488.1.02c-4.fc20.noarch

It appears that you did not update correctly. Did you really run 
   su -c 'yum update --enablerepo=updates-testing texlive\*'
???
The UPPERCASE change appears to be a TeXLive "enhancement" not in upstream ctex-kit. If you don't like it, I suggest you complain to the TeXLive people.

> ********************************************
> 
> the authors of ctex has explained that they have to use those Windows fonts
> because there are no proper east asian character fonts for industrial typing
> and printing in Linux, and for good type setting, they chose to use the
> Windows fonts.

There is no "have to". Breaking the law is obviously easier for some Chinese people than others. Some might want to tell you that "There is no proper way of making a living other than robbing the banks/selling your kidneys/kidnapping your neighbours" also.

Anyway, most of your problems is irrelevant to this bug report.

(In reply to Hin-Tak Leung from comment #31)
> (In reply to sunkins from comment #30)
> > I think I have excluded the fonts problem for it works fine on my fedora 17
> > laptop
> > Here are the settings on my fedora 20 PC
> > ********************************************
> > 
> > I make sure that the required fonts are installed in my fedora 20 where
> > those font files are from my legal copy of Windows (though I am not sure if
> > it is legal to use them in fedora).
> > here are the fonts:
> > --------------------------------
> > /usr/share/fonts/win/simsun.ttc: 宋体,SimSun:style=Regular
> > /usr/share/fonts/win/simhei.ttf:
> > 黑体,SimHei:style=Regular,Normal,obyčejné,Standard,Κανονικά,Normaali,Normál,
> > Normale,Standaard,Normalny,Обычный,Normálne,Navadno,Arrunta
> > /usr/share/fonts/win/simkai.ttf:
> > 楷体,KaiTi:style=Regular,Normal,obyčejné,Standard,Κανονικά,Normaali,Normál,
> > Normale,Standaard,Normalny,Обычный,Normálne,Navadno,Arrunta
> > /usr/share/fonts/win/simfang.ttf:
> > 仿宋,FangSong:style=Regular,Normal,obyčejné,Standard,Κανονικά,Normaali,Normál,
> > Normale,Standaard,Normalny,Обычный,Normálne,Navadno,Arrunta
> > /usr/share/fonts/win/SIMLI.TTF: 隶书,LiSu:style=Regular
> > /usr/share/fonts/win/SIMYOU.TTF: 幼圆,YouYuan:style=Regular
> > 
> > --------------------------------
> > and here is the file
> > /usr/share/texlive/texmf-dist/tex/latex/ctex/fontset/ctex-xecjk-winfonts.def
> > --------------------------------
> > ...
> 
> What you show is certainly not the
> /usr/share/texlive/texmf-dist/tex/latex/ctex/fontset/ctex-xecjk-winfonts.def
> from fedora updates-testing . 
As the guide of ctex, preinstalled file ctex-xecjk-winfonts.def is only valid for Windows use, and, if a user wants to use it in Linux, the def file should be modified to be like that mentioned in my last post. 
So, I updated texlive and modified the def to make sure it works -- the same def file indeed works in my feodra 17. 

> The one shipped by updates-testing have UPPERCASE FILENAMES inside. Also
> your configuration in /usr/share/fonts/win/ is wrong, since it requires
> filenames to be in UPPERCASES. 
> 
> $rpm -qf
> /usr/share/texlive/texmf-dist/tex/latex/ctex/fontset/ctex-xecjk-winfonts.def
> texlive-ctex-svn22488.1.02c-4.fc20.noarch
> 
> It appears that you did not update correctly. Did you really run 
>    su -c 'yum update --enablerepo=updates-testing texlive\*'
> ???
> The UPPERCASE change appears to be a TeXLive "enhancement" not in upstream
> ctex-kit. If you don't like it, I suggest you complain to the TeXLive people.
> 
> > ********************************************
> > 
> > the authors of ctex has explained that they have to use those Windows fonts
> > because there are no proper east asian character fonts for industrial typing
> > and printing in Linux, and for good type setting, they chose to use the
> > Windows fonts.
> 
> There is no "have to". Breaking the law is obviously easier for some Chinese
> people than others. Some might want to tell you that "There is no proper way
> of making a living other than robbing the banks/selling your
> kidneys/kidnapping your neighbours" also.
> 
Yes, you are right. No body accepts illegal use of any thing. My Windows copies were preinstalled and authorized by my computer OEMs and they are legal. I am not sure if it is legal to copy the font files from *my* Windows to my Linux. Because I seldom use my Windows on my PC, most of the time, the PC is running in fedora. If it is not legal（Windows fonts are only legal in Windows even on the same PC hardware),  I think I can use texlive in my Windows when dealing with non-English contents. 
> Anyway, most of your problems is irrelevant to this bug report.
Yes, this bug is relevant to texlive but not Fedora, I googled to here. This bug report was accepted and I thought it was relevant to feodra.

Thanks for your replies.

(In reply to sunkins from comment #32)
...
> As the guide of ctex, preinstalled file ctex-xecjk-winfonts.def is only
> valid for Windows use, and, if a user wants to use it in Linux, the def file
> should be modified to be like that mentioned in my last post. 
> So, I updated texlive and modified the def to make sure it works -- the same
> def file indeed works in my feodra 17. 

You are of course free to customize your own computer - OTOH, you are responsible for fixing issues from your own actions. To be specific, mix-and-match bits of TeXLive from across two years just isn't a good practise.

Your test case does not even run on a clean unmodified installation (including updates-testing/rawhide), then it is outside the scope of redhat's bugzilla; Although as I said, I have already made some adaptations, and detailed them (and revert them afterwards, as I have no personal need of them) and verified that it works.

My adaptation consists of sym-linking UPPERCASE versions of those fonts into $HOME/.fonts, and requires no changes to redhat-shipped components, unlike yours. If you modify redhat-shipped components, you are on your own.

> > Anyway, most of your problems is irrelevant to this bug report.
> Yes, this bug is relevant to texlive but not Fedora, I googled to here. This
> bug report was accepted and I thought it was relevant to feodra.

The original bug report refers to a problem that is seen on as-shipped fedora systems. Your own problem is seen on a heavily customized systems which had some shipped-components modified, and reverting/modifying to versions 2 years old. If this is hardware, you have already voided your warranty.

In any case, (1) using the microsoft fonts, without modifying redhat/texlive-shipped components, do work, as long as you follow my instructions to the letter, i.e. put *UPPERCASE* versions of the fonts in your $HOME/.fonts, and use the as-redhat/texlive-shipped ctex-xecjk-winfonts.def, (2) any test case which depends on the use of microsoft fonts is quite outside of scope of a *redhat* bugzilla report.

You are free to customize your own linux box - but you alone are also responsible for fixing problems from your own actions.

texlive-2013-4.20131226_r32488.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.