Font dependencies should always be virtuals. Surely there are multiple fonts with Japanese characters?
If you look at the Gentoo patches, you'll see the reason - ghostscript needs full path with filename for the fonts. So, the font must be chosen by package maintainer. Now, if this particular font is a good choice, is a different matter.
Bug 104512 says the typemap files (I didn't find 'kochi' in any patches) are pretty much unnecessary now...
...in patches tarball under fontmaps ? The bug you've mentioned also says CJK fonts are a special case.
(In reply to comment #3) > The bug you've mentioned also says CJK fonts are a special case. The upstream bug makes no such exception ( http://bugs.ghostscript.com/show_bug.cgi?id=687595 ), and the Gentoo bug seems to have comments expressing both opinions.
One more bug I forgot about. http://bugs.gentoo.org/show_bug.cgi?id=104512#c12 says otherwise. I'm not exactly informed well about postscript, but the problem may lie in historical limitations of the language and the way Adobe solved it with CIDMaps.
What's the status here (to me it just looks like lots of confusion)?
(In reply to comment #6) > What's the status here (to me it just looks like lots of confusion)? There's no confusion here - without the font listed in cidmap.ja (and CMaps, obviously) - see patch tarball under fontmaps, gsx -sDEVICE=display /usr/share/doc/${PVR}/examples/cjk/gscjk_aj.ps will simply fail. I actually keep the ebuild in my overlay, cause I use it with a different font than one in the tree.
How about adding eselect module to configure this font?
Created attachment 313351 [details] ghostscript-gpl-font.eselect This is RFC eselect module to select font and generate cidfmap.* * How dose it work: # eselect ghostscript-gpl-font list Available config files for cidfmap.ja (* is enabled): [1] kochi-substitute [2] mig [3] sazanami * Available config files for cidfmap.ko (* is enabled): Available config files for cidfmap.zh_CN (* is enabled): Available config files for cidfmap.zh_TW (* is enabled): # eselect ghostscript-gpl-font set ja 1 # eselect ghostscript-gpl-font list Available config files for cidfmap.ja (* is enabled): [1] kochi-substitute * [2] mig [3] sazanami Available config files for cidfmap.ko (* is enabled): Available config files for cidfmap.zh_CN (* is enabled): Available config files for cidfmap.zh_TW (* is enabled): * Design: app-text/ghostscipt-gpl will install symlink of /etc/gsfonts/conf.d/cidmap.{ja,ko,zh_CN,zh_TW} into /usr/share/ghostscript/9.05/Resource/Init/ Each font package install their cidfmap into /etc/gsfonts/conf.avail/{ja,ko,zh_CN,zh_TW} This eselect module create symlink to one of font's cidfmap into /etc/gsfonts/conf.d Users even can create their own cidfmap and eselect it to be used by ghostscript.
Any idea?
I just hit another issue with kochi-substitute in mis-rendering arrows... Any recent work on that bug? Looking at the eselect proposal, it may be better to integrate that in the current `eselct fontconfig` instead?
We stumbled upon this again when doing a license audit for the Gentoo install media. The image for the live DVD includes ghostscript-gpl and pulls in media-fonts/kochi-substitute via the l10n_ja use flag. media-fonts/kochi-substitute is currently labelled as LICENSE="free-noncomm" (which is not part of the @FREE set), and its licensing situation seems to be everything else than clear. Debian has done a license audit of the package which can be found here: https://metadata.ftp-master.debian.org/changelogs/main/t/ttf-kochi/ttf-kochi_20030809-15_copyright The translation of the Japanese license text says: "It's sure that it's no problem to distribute freely as non-commercial purpose." (How they come from that to the conclusion that it would be DFSG-free isn't at all clear to me.) Furthermore, the homepage of the Debian package https://packages.debian.org/jessie/ttf-kochi-gothic says: "Both this package and its alternative sazanami font are legacy and deprecated. You are recommended to transition to other modern font packages such as 'fonts-vlgothic' or 'fonts-ipafont-gothic'." Presumably, our equivalent to that would be media-fonts/vlgothic and media-fonts/ja-ipafonts.
Looks like there is little progress here since almost 10 years. So, unless someone objects, I am going to package.use.mask the l10n_ja flag for ghostscript-gpl in the base profile.
I don't understand why masking the USE flag is a solution here. Shouldn't the font just be changed to some free alternative? And while it's the current font, some people may still choose to make that compromise, and shouldn't be blocked by a hard mask - ACCEPT_LICENSE is good enough, no?
(In reply to Luke-Jr from comment #14) > I don't understand why masking the USE flag is a solution here. Shouldn't > the font just be changed to some free alternative? Yes, it should, but nobody has done that since 2010. The problem is that we cannot distribute a "free-noncomm" package on our install media. > And while it's the current font, some people may still choose to make that > compromise, and shouldn't be blocked by a hard mask - ACCEPT_LICENSE is good > enough, no? Nothing will prevent them from installing the font package, only it won't be pulled in as a dependency.
If the USE flag doesn't actually do anything, maybe it should just be removed?
(In reply to Luke-Jr from comment #16) > If the USE flag doesn't actually do anything, maybe it should just be > removed? But it does do something: it makes the example mentioned in comment 7 work. Also, any other postscript snippet depending on cidfmap.ja. Unless in the meanwhile ghostscript acquired pango-like font matching capabilities, a filename with full path is required to make things work - and that's what effectively is this useflag for. Baring either ghostscript acquiring those font matching capabilities or implementing idea from comment 9, there's will be no status change here. At most, you could pick a different font (after all, this one was picked arbitrarily from those available at the time).
for printing: until a better solution comes up let's mask ja support (it is blocking install media) we really need some knowledgeable help here
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6ecc859252ca5b0ab0f689cac728af66ea2c0e75 commit 6ecc859252ca5b0ab0f689cac728af66ea2c0e75 Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2019-04-25 18:14:18 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2019-04-25 18:17:04 +0000 profiles/base: package.use.mask l10n_ja for app-text/ghostscript-gpl. Bug: https://bugs.gentoo.org/325795 Acked-by: Andreas K. Hüttel <dilfridge@gentoo.org> Signed-off-by: Ulrich Müller <ulm@gentoo.org> profiles/base/package.use.mask | 7 +++++++ 1 file changed, 7 insertions(+)
