lilypond-auto
[Top][All Lists]
Advanced

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

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] #4876 The wron


From: Auto mailings of changes to Lily Issues
Subject: [Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] #4876 The wrong font name is embedded by using some OTF / OTC fonts
Date: Thu, 23 Jun 2016 15:12:04 +0000

Yes, the CFF font used for the TTC is identical for all embedded subfonts, AFAICS.

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.

  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.

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.

  1. 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.

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.


[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 12:50 PM 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 address@hidden 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
address@hidden
https://lists.sourceforge.net/lists/listinfo/testlilyissues-auto

reply via email to

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