Bug 488398 - ghostscript files referred to outdated font info
Summary: ghostscript files referred to outdated font info
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: cjkunifonts
Version: 10
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Caius Chance
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-03-04 04:22 UTC by Hin-Tak Leung
Modified: 2009-05-15 06:42 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 529975 (view as bug list)
Environment:
Last Closed: 2009-05-15 06:42:11 UTC


Attachments (Terms of Use)
log of how it was broken (3.53 KB, text/plain)
2009-04-08 22:13 UTC, Hin-Tak Leung
no flags Details
new brokenness with rpms from comment 5 (3.52 KB, text/plain)
2009-04-08 22:17 UTC, Hin-Tak Leung
no flags Details
new log, showing finding font files successful (2.49 KB, text/plain)
2009-05-06 07:50 UTC, Hin-Tak Leung
no flags Details
font encoding(?) problem (143.37 KB, image/png)
2009-05-06 10:46 UTC, Hin-Tak Leung
no flags Details

Description Hin-Tak Leung 2009-03-04 04:22:49 UTC
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 ?

Comment 1 Caius Chance 2009-04-08 03:57:16 UTC
Migration from .ttf to .ttc is upstream's decision.

Please gracefully provide details info/logs/errors from incompatible softwares.

Comment 2 Hin-Tak Leung 2009-04-08 05:55:16 UTC
(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.

Comment 3 Caius Chance 2009-04-08 06:13:26 UTC
(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.

Comment 4 Caius Chance 2009-04-08 06:42:27 UTC
Please kindly test if this rpm solves your problem:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1284552

Comment 5 Hin-Tak Leung 2009-04-08 22:11:22 UTC
(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.

Comment 6 Hin-Tak Leung 2009-04-08 22:13:51 UTC
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")

Comment 7 Hin-Tak Leung 2009-04-08 22:17:23 UTC
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").

Comment 8 Hin-Tak Leung 2009-04-08 22:20:21 UTC
The config.d/*map* files just need to match exactly the locations and naming of the fonts.

Comment 9 Caius Chance 2009-05-05 02:17:25 UTC
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.

Comment 10 Hin-Tak Leung 2009-05-06 07:50:34 UTC
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.

Comment 11 Hin-Tak Leung 2009-05-06 10:46:00 UTC
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.

Comment 12 Hin-Tak Leung 2009-05-06 10:46:56 UTC
I have already tried fc-cache -f and also manually blowing away fontconfig's cache everywhere...

Comment 13 Hin-Tak Leung 2009-05-08 04:05:02 UTC
downgrading to -11 reverts to correct behavior...

Comment 14 Hin-Tak Leung 2009-05-08 04:22:50 UTC
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 .

Comment 15 Hin-Tak Leung 2009-05-08 21:09:55 UTC
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.

Comment 16 Hin-Tak Leung 2009-05-09 01:22:09 UTC
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.

Comment 17 Caius Chance 2009-05-15 06:42:11 UTC
(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. :)


Note You need to log in before you can comment on or make changes to this bug.