> 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)
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 `name` table gets used.
> With FreeType 2.5.5, LilyPond uses Japanese font name that is in
> 'CFF' table. [...] 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.
The latter is the correct behaviour from FreeType's point of view.
> 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.
Yes, this is the way to go IMHO. The following is probably necessary.
* Trace the `cff` table's offset of a given font file.
* Trace the font name contained in the `cff` table. If we have a new `cff`
font with the same font name, check whether it comes from the same font file
and has the same offset. Otherwise emit a warning.
> 2. Use 'name' table's name and rewrite 'CFF' table's name for
> embedding. This behavior can embed correct font name.
>
> I think that rewriting 'CFF' table is a little difficult.
I agree.
---
** [issues:#4876] The wrong font name is embedded by using some OTF / OTC
fonts**
**Status:** Accepted
**Created:** Thu Jun 02, 2016 03:00 PM UTC by Masamichi Hosoda
**Last Updated:** Thu Jun 23, 2016 11:01 AM UTC
**Owner:** Masamichi Hosoda
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?
---
Sent from sourceforge.net because [email protected] is
subscribed to https://sourceforge.net/p/testlilyissues/issues/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/testlilyissues/admin/issues/options. Or, if this is
a mailing list, you can unsubscribe from the mailing list.
------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Testlilyissues-auto mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/testlilyissues-auto
