There are various issues with Steam and Fedora 38's google-noto-sans-cjk-vf-fonts package. https://github.com/ValveSoftware/steam-for-linux/issues/9418 https://github.com/flathub/com.valvesoftware.Steam/issues/1070 I was working around this issue by removing the google-noto-sans-cjk-vf-fonts package and installing the google-noto-sans-cjk-fonts package instead, but it can't be a permanent solution as dnf keeps compiling about conflicts between system one and the updated package. ``` Problem 1: package google-noto-sans-cjk-fonts-1:2.004-1.fc38.noarch from @System conflicts with google-noto-sans-cjk-vf-fonts provided by google-noto-sans-cjk-vf-fonts-1:2.004-2.fc38.noarch from updates - package google-noto-sans-cjk-vf-fonts-1:2.004-2.fc38.noarch from updates conflicts with google-noto-sans-cjk-fonts provided by google-noto-sans-cjk-fonts-1:2.004-1.fc38.noarch from @System - cannot install the best update candidate for package google-noto-sans-cjk-fonts-1:2.004-1.fc38.noarch - cannot install the best update candidate for package google-noto-cjk-fonts-common-20201206-7.fc38.noarch ``` Any good solution to fix this issue? (i.e. help Steam to deal with variable fonts) Reproducible: Always
No idea and unfortunately there are nothing we can do so far. I tried to reject all the named instances and variable fontconfig patterns with the latest snapshot of fontconfig from upstream git and it should basically looks like same to general ttc fonts then. it works as expected on fc-match for example. however, Steam app still shows a tofu on their UI. I can't debug it more than that without some information from Valve because we don't know how they use fontconfig and render a character. You may want to wait for their response then.
For a workaround, we could drop Conflict lines in both google-noto-sans-cjk-fonts and google-noto-sans-cjk-vf-fonts and install google-noto-sans-cjk-fonts. Fortunately this still works as a workaround for some reasons. fontconfig estimate a score to determine the best font and give same scores to both static and vf fonts. In this case, first entry will be picked up though, when creating a cache, fontconfig sorts sub-directory entries in a cache alphabetically. thus, static fonts where puts into /usr/share/fonts/google-noto-sans-cjk-fonts will appears earlier than vf fonts where puts into /usr/share/fonts/google-noto-sans-cjk-vf-fonts.
I just removed the Conflicts from the RPM spec files. URL: https://bodhi.fedoraproject.org/updates/FEDORA-2023-90417fbb0e
I encountered similar breakage in XeTeX engine. Minimal latex source which uses "Noto Sans CJK SC" through the xeCJK package: test.tex: ------------------------------------------- \documentclass{article} \usepackage{xeCJK} \setCJKmainfont{Noto Sans CJK SC} \setCJKmonofont{Noto Sans Mono CJK SC} \begin{document} 中文 \LaTeX 示例。 {\ttfamily 中文 \LaTeX 示例。 } \end{document} ------------------------------------------- With only google-noto-sans-cjk-fonts and google-noto-sans-mono-cjk-fonts installed, "xelatex test.tex" works fine. Thanks to the removal of conflicts, I can install google-noto-sans-cjk-vf-fonts and google-noto-sans-mono-cjk-vf-fonts alongside the non-variable fonts. "xelatex test.tex" now gives this: ------------------------------------------- This is XeTeX, Version 3.141592653-2.6-0.999995 (TeX Live 2023) (preloaded format=xelatex) restricted \write18 enabled. entering extended mode (./main.tex LaTeX2e <2022-11-01> patch level 1 L3 programming layer <2023-02-22> (/usr/share/texlive/texmf-dist/tex/latex/base/article.cls Document Class: article 2022/07/02 v1.4n Standard LaTeX document class (/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo)) (/usr/share/texlive/texmf-dist/tex/xelatex/xecjk/xeCJK.sty (/usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3.sty (/usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-xetex.def)) (/usr/share/texlive/texmf-dist/tex/latex/ctex/ctexhook.sty) (/usr/share/texlive/texmf-dist/tex/latex/l3packages/xtemplate/xtemplate.sty) (/usr/share/texlive/texmf-dist/tex/latex/fontspec/fontspec.sty (/usr/share/texlive/texmf-dist/tex/latex/l3packages/xparse/xparse.sty) (/usr/share/texlive/texmf-dist/tex/latex/fontspec/fontspec-xetex.sty (/usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty) (/usr/share/texlive/texmf-dist/tex/latex/fontspec/fontspec.cfg))) (/usr/share/texlive/texmf-dist/tex/xelatex/xecjk/xeCJK.cfg)) (./main.aux) (/usr/share/texlive/texmf-dist/tex/latex/base/ts1cmr.fd) [1] (./main.aux) xdvipdfmx:fatal: Invalid TTC index number No output PDF file written. ) Error 256 (driver return code) generating output; file main.pdf may not be valid. Transcript written on main.log. ------------------------------------------- In main.log, there are info level messages of interest: ------------------------------------------- Package fontspec Info: Could not resolve font "Noto Sans CJK SC/BI" (it (fontspec) probably doesn't exist). Package fontspec Info: Could not resolve font "Noto Sans CJK SC/B" (it (fontspec) probably doesn't exist). Package fontspec Info: Could not resolve font "Noto Sans CJK SC/I" (it (fontspec) probably doesn't exist). ----------------------------- I'm suspecting that XeTeX engine doesn't expect the mere presence of -VF fonts of the same name and generates bogus main.xdv which causes the error of xdvipdfmx. My question is: Can I hide the -VF fonts from XeTeX by tweaking fontconfig's per-user setting without removing those -vf packages system wide? Longer term, I guess it would be ideal to teach XeTeX to ignore -VF fonts. I have no idea if such an update is possible, though.
Please open another bug for the XeTeX issue, thanks!
This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle. Changing version to 42.