8000 [subset] Keep MacRoman English name entry if no Unicode ones are available? · Issue #146 · fonttools/fonttools · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

[subset] Keep MacRoman English name entry if no Unicode ones are available? #146

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
behdad opened this issue Aug 13, 2014 · 12 comments
Open

[subset] Keep MacRoman English name entry if no Unicode ones are available? #146

behdad opened this issue Aug 13, 2014 · 12 comments

Comments

@behdad
Copy link
Member
behdad commented Aug 13, 2014

Currently default is --no-name-legacy, which drops all non-Unicode names. But some fonts (like Apple Color Emoji) only have a MacRoman English name, no Unicode ones.

In general we should pick the best name per nameID/language.
@anthrotype
Copy link
Member

on a related note, I think the default for the --name-languages option should also include the Macintosh language ID '0', besides the current Windows' 0x0409, if you don't want that the option --name-legacy be overridden the latter.

Macintosh and Windows language IDs don't seem to overlap with each other, so we may well set name_languages = [0, 0x0409] in the subset.Options class, without influencing the default --no-name-legacy behaviour.

@behdad
Copy link
Member Author
behdad commented Oct 8, 2014

Got patch?

@anthrotype
Copy link
Member

I tried to make a patch that keeps any MacRoman English name entries (platformID=1, platEncID=0, langID=0) if no Windows-Unicode English ones are available (platformID=3, platEncID=[0, 1, 10], langID=0x0409).

However, if I run that on the Apple Color Emoji you mention in the example, a new problem arises.
Since the nameID 2 (Subfamily) has an equivalent Windows Unicode entry in that font (0x0409, American English), the MacRoman English nameID 2 (Subfamily) will be dropped, following the above mentioned logic. But then OSX's FontBook will read the nameID 2 from the Chinese (Taiwan, 0x0404) entry instead of the American English one...

So, it looks like one can't simply consider each nameID separately and pick up the Unicode version as the "best name per nameID/langID". Another approach would be to treat at least the basic nameIDs 1–6 as a group: that is, keeping them all if any one of them does not have an Unicode English equivalent.

@behdad
Copy link
Member Author
behdad commented Jan 22, 2015

I'm open to that. We need to find a good set of names and keep them, and probably drop everything else.

@MrBrezina
Copy link

Just for the record, in case no one brought it up yet, missing MacRoman English name entries (platformID=1, platEncID=0, langID=0) for the basic nameIDs – probably 1–6 is causing problems in MS Office 2011 for Mac. Fonts do not load into font menu.

@anthrotype
Copy link
Member

are you saying that the font has valid Windows-Unicode nameIDs (1-6) but MS Office 2001 Mac does not load it unless the MacRoman names are also there?

@MrBrezina
Copy link

Yes, it seems that way.
1,2,4,6 have to be there in MacRoman

On 29. 1. 2016, at 13:55, Cosimo Lupo notifications@github.com wrote:

are you saying that the font has valid Windows-Unicode nameIDs (1-6) but MS Office 2001 Mac does not load it unless the MacRoman names are also there?

—
Reply to this email directly or view it on GitHub #146 (comment).

@anthrotype
Copy link
Member

Well I just took a random font, stripped of all its nameIDs with platform=1 (Mac), leaving in only platform=3 (Windows), and loaded it in Word 2011 for Mac [version 14.5.8 (151023)] and it works...

@MrBrezina
Copy link

Hah, great! I am on a slightly older version (150604) where it is an issue.

On 29. 1. 2016, at 14:05, Cosimo Lupo notifications@github.com wrote:

Well I just took a random font, stripped of all its nameIDs with platform=1 (Mac), leaving in only platform=3 (Windows), and loaded it in Word 2011 for Mac [version 14.5.8 (151023)] and it works...

—
Reply to this email directly or view it on GitHub #146 (comment).

@anthrotype
Copy link
Member

that's bad... :-(

well, with pyftsubset you can keep them if you pass the options --name-IDs=1,2,3,4,5,6 --name-languages=0,1033 --name-legacy

@MrBrezina
Copy link

I think I will just suggest people to update Office and do this only when they cannot update.

@davelab6 davelab6 mentioned this issue Jan 29, 2016
Closed
felipesanches referenced this issue in fonttools/fontbakery May 30, 2016
@felipesanches
fix platformID=1 checker
59f60c6
@brawer
Copy link
Collaborator
brawer commented Mar 9, 2017

Related to this, the subsetter should probably keep MacRoman names for PostScript names (not just nameid 6, but also the PostScript names listed in fvar). #756

@brawer brawer mentioned this issue Mar 9, 2017
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@behdad @MrBrezina @brawer @anthrotype
0