Menu
▾
▴
#4876 The wrong font name is embedded by using some OTF / OTC fonts
If I understand correctly, this caused by FreeType 2.5.5 or earlier.
For example, if you use a non-Japanese (e.g. Chinese or Korean) font in NotoSansCJK.ttc ver. 1.004, FreeType 2.5.5 gets a Japanese postscript name.
Therefore, LilyPond might embed the fonts with wrong postscript name if you use FreeType 2.5.5 or earlier.
Even if the name is wrong, the glyphs are correct.
FreeType 2.6+ is fixed it.
For LilyPond official site's binaries:
Current GUB uses FreeType 2.4.12.
So I'm making the GUB's patch which update FreeType.
For others:
Bump up required or recommended version of FreeType?
Discussion
I suggest to require 2.6.x. There are always lots of improvements :-)
I've send pull request to GUB.
https://github.com/gperciva/gub/pull/23
LilyPond 2.19.44 with FreeType 2.6.3 cannot handle non-Japanese (e.g. Chinese or Korean) fonts in NotoSansCJK.ttc ver. 1.004.
LilyPond 2.19.44 with FreeType 2.5.5 can handle them, but it embeds Japanese font name.
If I understand correctly,
for non-Japanese fonts in NotoSansCJK.ttc, font name in 'name' table and 'CFF' table is different.
For Japanese fonts in it, they are consistent.
i.e.
font-index 12:
'name' table: NotoSansCJKjp-Regular (Japanese)
'CFF ' table: NotoSansCJKjp-Regular (Japanese)
font-index 13:
'name' table: NotoSansCJKkr-Regular (Korean)
'CFF ' table: NotoSansCJKjp-Regular (Japanese)
font-index 14:
'name' table: NotoSansCJKsc-Regular (Simplified Chinese)
'CFF ' table: NotoSansCJKjp-Regular (Japanese)
font-index 15:
'name' table: NotoSansCJKtc-Regular (Traditional Chinese)
'CFF ' table: NotoSansCJKjp-Regular (Japanese)
With FreeType 2.5.5, LilyPond uses Japanese font name that is in 'CFF' table.
And it embeds the 'CFF' table that contains Japanese font name.
So both font names are consistent. It works fine even if they are wrong name.
On the other hand, with FreeType 2.6.3, if you use non-Japanese font, LilyPond uses non-Japanese font name that is in 'name' table.
However, it embeds the 'CFF' table that contains Japanese font name.
So both font names are not consistent. It does not work fine.
I think that there are two solutions for solving this problem.
1.
Use 'CFF' table's name even if it is the wrong name.
This behavior is similar to "with FreeType 2.5.5".
The name may be wrong.
2.
Use 'name' table's name and rewrite 'CFF' table's name for embedding.
This behavior can embed correct font name.
Which would you like?
I think that rewriting 'CFF' table is a little difficult.
Yes, the CFF font used for the TTC is identical for all embedded subfonts, AFAICS. Note that the CFF font name is not relevant for a TTC; only the data in the subfont's
nametable gets used.The latter is the correct behaviour from FreeType's point of view.
Yes, this is the way to go IMHO. The following is probably necessary.
Trace the
cfftable's offset of a given font file.Trace the font name contained in the
cfftable. If we have a newcfffont with the same font name, check whether it comes from the same font file and has the same offset. Otherwise emit a warning.I agree.
In NotoSansCJK.ttc, CFF name of the subfont is different for each weight.
i.e.
font-index 0:
'name' table: NotoSansCJKjp-Thin
'CFF ' table: NotoSansCJKjp-Thin
font-index 4:
'name' table: NotoSansCJKjp-Light
'CFF ' table: NotoSnasCJKjp-Light
etc.
The CFF name is the same between the same weight different language.
In this way, the embedded font name may be wrong.
Or would you think it is not wrong because it is correct CFF name?
I understand that if you use some same weight different language fonts (e.g. NotoSansCJKjp-Regular, NotoSansCJKkr-Regular, NotoSansCJKsc-Regular and NotoSansCJKtc-Regular) in a same source file, the output file can be embeded only one font (e.g. NotoSansCJKjp-Regular).
It is good because it is possible to reduce the output file size.
In this way, if you use some same weight different language fonts, the output file is embedded each languages subfonts even if they are originally the same CFF table.
It is not good because output file size increases.
Ah, my mistake. You are right, of course. Here we really have
different CFF subfonts.
For printing, the TrueType name no longer matters; the OpenType stuff is eventually resolved into glyph indices, directly pointing into the CFF resource.
No, see above. This Noto font is not a Multiple Master or GX font, so the 'thin' variants, for example, are indeed different subfonts. [Google actually is working on building GX fonts, AFAIK, but this isn't ready yet.]
Again, see above :-) This is unavoidable, I think.
Issue 4876/4: Enable fontname replacing in TrueType functions
This commit enables fontname replacing for CFF (OTF/OTC) fonts.
Issue 4876/3: Enable fontname replacing in Pango_font class
This commit enables fontname replacing for CFF (OTF/OTC) fonts.
Issue 4876/2: Enable fontname replacing in Open_type_font class
This commit enables fontname replacing for CFF (OTF/OTC) fonts.
Issue 4876/1: Add fontname replacing function for CFF (OTF/OTC) fonts
For CFF (OTF/OTC) fonts,
FT_Get_Postscript_Name ()
in FreeType 2.6+ gets the name in 'name' table.
However, we want the name in 'CFF' table instead of in 'name' table
because output postscript file is embedded only 'CFF' table of the font.
They are inconsistent for some OpenType/CFF Collection fonts (OTC).
This function can get the name in 'CFF' table.
TODO: Check conflicts between fonts which have same name in 'CFF' table
but different name in 'name' table.
http://codereview.appspot.com/300490043
This failes check
--snip--
Renaming input to:
/home/james/lilypond-git/input/regression/system-start-nesting.ly' Interpreting music... fatal error: error getting font Emmentaler-20 CFF name logfile lilypond-multi-run-5.log (exit 1): Processing./8b/lily-6e6407f6.ly'Parsing...
Renaming input to: `/home/james/lilypond-git/input/regression/song-tempo.ly'
Writing Festival XML file song-tempo.xml...song-tempo
<singing bpm="90.0">
<duration beats="1.0"><pitch note="C5">do</pitch></duration>
<duration beats="1.0"><pitch note="E5">re</pitch></duration>
<duration beats="1.0"><pitch note="G5">mi</pitch></duration>
<duration beats="1.5"><pitch note="C5">do</pitch></duration>
<duration beats="1.5"><pitch note="E5">re</pitch></duration>
<duration beats="1.5"><pitch note="G5">mi</pitch></duration>
</singing>
Interpreting music...
fatal error: error getting font Emmentaler-20 CFF name
logfile lilypond-multi-run-4.log (exit 1):
Processing
./da/lily-e1c01796.ly' Parsing... Renaming input to:/home/james/lilypond-git/input/regression/paper-margins-consistency.ly'Interpreting music...
fatal error: error getting font Emmentaler-20 CFF name
logfile lilypond-multi-run-3.log (exit 1):
Processing
./0b/lily-dadf05df.ly' Parsing... Renaming input to:/home/james/lilypond-git/input/regression/page-breaking-min-distance3.ly'Interpreting music...
fatal error: error getting font Emmentaler-20 CFF name
logfile lilypond-multi-run-2.log (exit 1):
Processing
./af/lily-23f31ae5.ly' Parsing... Renaming input to:/home/james/lilypond-git/input/regression/collision-manual.ly'Interpreting music...
fatal error: error getting font Emmentaler-20 CFF name
logfile lilypond-multi-run-1.log (exit 1):
Processing
./05/lily-fe7058d3.ly' Parsing... Renaming input to:/home/james/lilypond-git/input/regression/collision-2.ly'Interpreting music...
fatal error: error getting font Emmentaler-20 CFF name
logfile lilypond-multi-run-0.log (exit 1):
--snip--
I've reproduced this fail.
If I understand correctly, the cause is an issue of FreeType 2.6 and 2.6.1.
https://savannah.nongnu.org/bugs/?46130
FreeType 2.5.5 and earlier do not have this issue.
FreeType 2.6.2+ is fixed it.
Since I've changed from "error" to "warning" at Patch Set 2, LilyPond is no longer stop.
However, the warning messages like the following are shown if you use FreeType 2.6 or 2.6.1.
Moreover, for non-Japanese font in NotoSansCJK.ttc, PDF output is failed because LilyPond cannot get CFF name.
For other fonts, PDF output is no problem even if the warning messages are shown.
Again, FreeType 2.6.2+ is fixed this issue.
The warning messages are not shown.
Non-Japanese font in NotoSansCJK.ttc can be used for PDF output.
However, FreeType 2.6.1 seems to have been widely used in Ubuntu 16.04 LTS etc.
http://packages.ubuntu.com/xenial/libfreetype6
Would you think measures are required?
Use warning instead of error
http://codereview.appspot.com/300490043
Fix comment
http://codereview.appspot.com/300490043
Well this passes make, make check and a full make doc.
But there are a LOT of warnings now (as you say) but a LOT of them in the regi test
e.g
--snip--
input/regression/mozart-hrn-3.log
@@ -1,21 +1,556 @@
Processing
./mozart-hrn-3.ly' Parsing... Renaming input to:/home/james/lilypond-git/input/regression/mozart-hrn-3.ly'-Interpreting music...[8][16][24][32][40][48][56][64][72][80][88][96][104][112][120]
+Interpreting music...
+warning: cannot get font Emmentaler-20 CFF name
+[8][16][24][32][40][48][56][64][72][80][88][96][104][112][120]
Preprocessing graphical objects...
+warning: cannot get font TeXGyreSchola-Bold CFF name
+warning: cannot get font TeXGyreSchola-Bold CFF name
+warning: cannot get font TeXGyreSchola-Bold CFF name
+warning: cannot get font TeXGyreSchola-Bold CFF name
+warning: cannot get font TeXGyreSchola-Bold CFF name
+warning: cannot get font TeXGyreSchola-Bold CFF name
+warning: cannot get font TeXGyreSchola-Bold CFF name
+warning: cannot get font Emmentaler-20 CFF name
+warning: cannot get font Emmentaler-20 CFF name
+warning: cannot get font Emmentaler-20 CFF name
+warning: cannot get font Emmentaler-20 CFF name
+warning: cannot get font Emmentaler-20 CFF name
+warning: cannot get font Emmentaler-20 CFF name
+warning: cannot get font Emmentaler-20 CFF name
+warning: cannot get font Emmentaler-20 CFF name
+warning: cannot get font Emmentaler-20 CFF name
+warning: cannot get font Emmentaler-20 CFF name
+warning: cannot get font Emmentaler-20 CFF name
+warning: cannot get font Emmentaler-20 CFF name
+warning: cannot get font Emmentaler-20 CFF name
+warning: cannot get font Emmentaler-20 CFF name
+warning: cannot get font Emmentaler-20 CFF name
+warning: cannot get font Emmentaler-20 CFF name
+warning: cannot get font Emmentaler-20 CFF name
+warning: cannot get font Emmentaler-20 CFF name
+warning: cannot get font Emmentaler-20 CFF name
+warning: cannot get font Emmentaler-20 CFF name
+warning: cannot get font Emmentaler-20 CFF name
+warning: cannot get font TeXGyreSchola-BoldItalic CFF name
+warning: cannot get font TeXGyreSchola-Regular CFF name
+warning: cannot get font TeXGyreSchola-BoldItalic CFF name
+warning: cannot get font TeXGyreSchola-Regular CFF name
for about 200 lines.
I am using Fedora 23 and this has Freetype 2.6.0
So, I would ask; unless it is simple to update to Freetype 2.6.x where these warnings go away, are we going to get emails from users asking about all these 'warnings' that they never had before?
A smaller example in the reg test is this:
--snip--
input/regression/music-function-direct-call.log
@@ -2,9 +2,24 @@
Parsing...
Renaming input to:
/home/james/lilypond-git/input/regression/music-function-direct-call.ly' Interpreting music... +warning: cannot get font Emmentaler-20 CFF name Preprocessing graphical objects... +warning: cannot get font Emmentaler-20 CFF name +warning: cannot get font Emmentaler-20 CFF name +warning: cannot get font Emmentaler-20 CFF name +warning: cannot get font Emmentaler-20 CFF name +warning: cannot get font Emmentaler-20 CFF name +warning: cannot get font Emmentaler-20 CFF name +warning: cannot get font Emmentaler-20 CFF name +warning: cannot get font Emmentaler-20 CFF name +warning: cannot get font Emmentaler-20 CFF name +warning: cannot get font Emmentaler-20 CFF name +warning: cannot get font TeXGyreSchola-Regular CFF name +warning: cannot get font TeXGyreSchola-Regular CFF name Calculating line breaks... Drawing systems... +warning: cannot get font TeXGyreSchola-Italic CFF name +warning: cannot get font TeXGyreSchola-Italic CFF name Writing header fieldtexidoc' to./music-function-direct-call.texidoc'... Writing ./music-function-direct-call-1.signature Layout output to./music-function-direct-call.eps'...--snip--
We can make recommendations to install FreeType version X but it has to be simple to do this for users for whatever distribution they might use - we cannot really just use Ubuntu as a baseline I don't think.
Also, as I test patches are the reg tests going to be full of these messages all the time if this were to get pushed and I didn't have Freetype 2.6.1 or 2?
James
Hmm. We could implement a work-around for the problematic FreeType versions, circumventing the buggy function (
cff_get_ps_namein FreeType'ssrc/cff/cffdrivr.c) by directly accessingcff->font_name. We would also have to copy theCFF_FontRecstructure fromsrc/cff/cfftypes.hso that we get thefont_namefield offset.Very ugly, of course, but probably justified due to the importance of the fix.
Add "Issue 4876/5: Add directly parsing CFF for getting Postscript font name"
http://codereview.appspot.com/300490043
I've added Issue 4876/5.
It parses CFF directly instead of using FreeType inner struct.
Issue 4876/5: Add directly parsing CFF for getting Postscript font name
FreeType 2.6 and 2.6.1 cannot get PS name from pure-CFF.
(FreeType 2.5.5 and earlier does not have this issue.
FreeType 2.6.2+ has been fixed this issue.)
So we need directly parsing 'CFF' table, in this case.
Fix and add comment
http://codereview.appspot.com/300490043
Passes make, make check and a full make doc.
No warnings are posted (using Ubuntu 15.04 w/ Freetype 2.5.2)
Patch on countdown for july 3rd
Patch counted down - please push.