[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: James Lowe
Subject: Re: make doc still fails - problem with lilypond-book - was: Still cannot make doc
Date: Mon, 6 Jun 2016 18:24:53 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0


On 06/06/16 14:44, Masamichi Hosoda wrote:
I've tried some Japanese fonts with `-dgs-load-fonts' option.  [...]

So most Japanese fonts can not be used with `-dgs-load-fonts'
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.

I'm not familiar with OSX
but I've heard that most (all?) OSX 10.11 Japanese fonts are OTC fonts.

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.

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.

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

Without `-dgs-load-fonts', LilyPond embed generated glyph name table
by print_trailer () in
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.

lilypond-devel mailing list

So do we need any warnings or notes to be added to here:

and/or here:




reply via email to

[Prev in Thread] Current Thread [Next in Thread]