Re: make doc still fails - problem with lilypond-book - was: Still cannot make doc

[Masamichi Hosoda]

>> I've tried some Japanese fonts with `-dgs-load-fonts' option.  [...]
>> 
>> So most Japanese fonts can not be used with `-dgs-load-fonts'
>> option.
> 
> Any idea why this is so?  Could you contact the gs people by filing a
> bug report so that we get an explanation?

If I understand correctly, there is four issues at least.


First, "Noto Sans CJK JP" in NotoSansCJK.ttc cannot be used.

I think that the biggest hurdle is OTC fonts.
As you know, current ghostscript does not support OTC fonts.
http://bugs.ghostscript.com/show_bug.cgi?id=696808

I'm not familiar with OSX
but I've heard that most (all?) OSX 10.11 Japanese fonts are OTC fonts.
http://tug.org/pipermail/luatex/2015-October/005377.html

In other words,
if you use OSX 10.11,
most Japanese fonts cannot be used with `-dgs-load-fonts'.

Moreover, Debian / Ubuntu / Fedora provide the package
that contains OTC version's Noto Sans CJK.
There is not OTF version.

On the other hand,
without `-dgs-load-fonts', my patches will add OTC font supports.
In my experiment, I've succeeded to use OTC font "NotoSansCJK.ttc".


Second, "MS PMincho" in msmincho.ttc cannot be used.

I've reported this issue to ghostscript developers.
http://bugs.ghostscript.com/show_bug.cgi?id=696823

Maybe, ghostscript cannot load the font which has index!=0
in TrueType Collection.
All Japanese fonts that I've seen in modern Windows are TTC fonts.
Most Japanese fonts in Windows cannot be used with `-dgs-load-fonts'.
Only index=0 fonts can be used.

Without `-dgs-load-fonts', there is no problem even if index!=0.


Third, "IPAexMincho" in ipaexm.ttf cannot be used.

I've reported this issue to ghostscript developpers.
http://bugs.ghostscript.com/show_bug.cgi?id=696824

Without `-dgs-load-fonts', there is no problem.


Fourth, "MS Mincho" in msmincho.ttc cannot be used.

In my newest investigation,
this is LilyPond issue.

This font does not have glyph names.
So LilyPond generate glyph names like "/uni3044"
by get_unicode_name () in pango-font.cc.

Without `-dgs-load-fonts', LilyPond embed generated glyph name table
by print_trailer () in ttf.cc.
Ghostscript can find glyph name.
There is no problem.

On the other hand,
with `-dgs-load-fonts',
LilyPond does not embed glyph name table but use the glyph name.
Ghostscript cannot find the glyph name.
So it uses TOFU glyph for all Japanese characters.

I think it can be fixed.