Description of problem: /usr/share/ghostscript/conf.d/*map.zh_* refers to *.ttf instead of *.ttc, causing printing or viewing of cjk pdf without embedded cjk fonts to not work. Version-Release number of selected component (if applicable): cjkunifonts-uming-0.2.20080216.1-10.fc10.noarch cjkunifonts-ukai-0.2.20080216.1-10.fc10.noarch Additional info: This seems to be an small oversight of the packager when the unifonts changes from ttf in 0.1.x to ttc in 0.2.x ?
Migration from .ttf to .ttc is upstream's decision. Please gracefully provide details info/logs/errors from incompatible softwares.
(In reply to comment #1) > Migration from .ttf to .ttc is upstream's decision. > > Please gracefully provide details info/logs/errors from incompatible softwares. You do not understand the problem. The "ghostscript/conf.d/*map.zh_*" files are a set of distribution-specific/value-added config files which tell ghostscript what default CJK fonts to use when pdf files containing CJK text but without embedded font is encountered. On older fedora systems, the config files tell ghostscript to use uming.ttf and ukai.ttf, because those are the fonts *available on the system*. Since upstream has migrated to ttc, and fedora now follow upstream to ship uming.ttc/ukai.ttc instead of uming.ttf/ukai.ttf, the config files now tell ghostscript to use font files which no longer exist. The problem is very well-understood and the solution well-characterised: the content of /usr/share/ghostscript/conf.d/*.zh_* should always refer to available and valid font files on the system. When the font file names have changed, the config files should be updated to match.
(In reply to comment #2) > You do not understand the problem. The "ghostscript/conf.d/*map.zh_*" files are > a set of distribution-specific/value-added config files which tell ghostscript > what default CJK fonts to use when pdf files containing CJK text but without > embedded font is encountered. Have you tested this on rawhide yet? > On older fedora systems, the config files tell ghostscript to use uming.ttf and > ukai.ttf, because those are the fonts *available on the system*. Since upstream > has migrated to ttc, and fedora now follow upstream to ship uming.ttc/ukai.ttc > instead of uming.ttf/ukai.ttf, the config files now tell ghostscript to use > font files which no longer exist. Could you please test on rawhide with installing cjkuni-fonts-ghostscript also? > The problem is very well-understood and the solution well-characterised: the > content of /usr/share/ghostscript/conf.d/*.zh_* should always refer to > available and valid font files on the system. When the font file names have > changed, the config files should be updated to match. I should've updated all of them, and they are packed in cjkuni-fonts-ghostscript on rawhide.
Please kindly test if this rpm solves your problem: http://koji.fedoraproject.org/koji/taskinfo?taskID=1284552
(In reply to comment #4) > Please kindly test if this rpm solves your problem: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1284552 Still broken, just in different ways. The base name now changes to ttc, but the full path is wrong. I'll attach logs later. Sorry I cannot share the pdf test file - it contains proprietary info - but if you can find a equivalent pdf, the test is simply: "gs -dNOPAUSE file.pdf" to see the logs I am posting.
Created attachment 338816 [details] log of how it was broken Note that it says: 'Can't find the font file /usr/share/fonts/cjkunifonts-uming/uming.ttf' (The correct path is "/usr/share/fonts/cjkunifonts-uming/uming.ttc")
Created attachment 338817 [details] new brokenness with rpms from comment 5 Different brokenness with rpms from comment 5. Note now it says "Can't find the font file /usr/share/fonts/cjkuni/uming.ttc" The new rawhide rpm puts the file at /usr/share/fonts/cjkunifonts-uming/uming.ttc (note the extra bits "-uming").
The config.d/*map* files just need to match exactly the locations and naming of the fonts.
I guess the cidmaps I back-ported before was referring to new package names used in rawhide (coming up F11 in this case). Please kindly check the following update which target F10: http://koji.fedoraproject.org/koji/buildinfo?buildID=100858 Let me know the results so I could push to F10 once it is proved working. Thanks a lot. It is welcome to test the same on rawhide, or F11 once its released.
Created attachment 342605 [details] new log, showing finding font files successful After http://koji.fedoraproject.org/koji/buildinfo?buildID=100858 , it now works correctly on f10. There seems to be a new harmless message compared to previous: Can't find (or can't open) font file /usr/share/ghostscript/8.64/Resource/Font/NimbusSanL-Regu. Can't find (or can't open) font file NimbusSanL-Regu. Querying operating system for font files... Loading NimbusSanL-Regu font from /usr/share/fonts/default/Type1/n019003l.pfb... 3652904 2149080 21225716 19825545 3 done. So please close.
Created attachment 342629 [details] font encoding(?) problem The new font files seem to have some font encoding problem with X? Anyway, here is firefox screenshot, plus url. configuring firefox to use Sazanami Gothic (a japanese font) for tradtional chinese explicitly shows how the page should look for most parts - obviously using a japanese font (with missing code points) is not ideal.
I have already tried fc-cache -f and also manually blowing away fontconfig's cache everywhere...
downgrading to -11 reverts to correct behavior...
I have tried forward/backward a few times (close firefox, install package , fc-cache -r as root and user, start firefox), and it seems that something in -13 is different and broken compared to -11 ; url as in the screenshot .
FAPIcidfmap.zh_TW seems to refer to /usr/share/fonts/chinese/{cjkunifonts-ukai,cjkunifonts-uming} rather than /usr/share/fonts/{cjkunifonts-ukai,cjkunifonts-uming} But please close when that's fixed. I think my firefox problem is unrelated (it seems to come and go, and not depending on which version - I unpacked both src rpm and can't see how the difference affect the x server) - so I probably should file a different bug.
Please ignore comment 11,12,13,14 - I think it is due to the radeon X driver. "MOZ_DISABLE_IMAGE_OPTIMIZE=1 firefox" works around it.
(In reply to comment #16) > Please ignore comment 11,12,13,14 - I think it is due to the radeon X driver. > "MOZ_DISABLE_IMAGE_OPTIMIZE=1 firefox" works around it. Thanks for info. I have fixed comment #15 and rebuilt: http://koji.fedoraproject.org/koji/buildinfo?buildID=102212 It will be on current rawhide and F11 soon. :)