Mac legacy names and cmap needed in Word for Mac

moyogo commented 7 years ago

Word for Mac doesn’t show some fonts in the menu if they don’t have some Mac platform names (1, 2, 3, and maybe more I need to confirm with Michele). Furthermore, if there is no Mac platform cmap table, the font is not ordered as desired (after Zapfino even when it should be before).

For example, Noto Sans doesn’t show up in the Word for Mac font menu.

We need to go back on https://github.com/googlei18n/ufo2ft/pull/66 and https://github.com/googlei18n/fontmake/pull/130.

anthrotype commented 7 years ago

oh no... :man_facepalming:

which version of word for mac?

moyogo commented 7 years ago

Word for Mac 2011.

anthrotype commented 7 years ago

does it also affect Word 2016?

chrissimpkins commented 7 years ago

I have this installed (Word 2016 on OS X) if I can be of any help with testing. Just point me to fonts of concern and I'd be happy to provide any info that you need if you don't have this version of Word available to test.

anthrotype commented 7 years ago

Just try any font made with fontmake, which doesn't have platformID=1 (Macintosh) names and cmap subtables.

chrissimpkins commented 7 years ago

I tested Hack version prior to conversion to fontmake builds with the following name tables and cmap subtables:

with_mac_name_tables

with_mac_cmap_subtables

Conversion to fontmake builds leads to the following name tables and cmap subtables:

hack_fontmake_build_name_tbl

hack_fontmake_build_cmap

Cleared font cache between installs + reboot and can confirm that both Word 2016 and Powerpoint 2016 display Hack in the font selection menus on OS X across both Hack builds.

hack_with_fontmake

davelab6 commented 7 years ago

Can the MS cmap also be dropped, leaving only the unicode one?

chrissimpkins commented 7 years ago

If you point me to any other fonts that you build with fontmake, be happy to try new install as well to confirm not dealing with a Microsoft font caching issue. Not sure how they cache and whether my approach rebuilds their caches.

moyogo commented 7 years ago

We were able to test Word 2016 later today. It does work in that version for us as well.

khaledhosny commented 7 years ago

Do we really need to support a 7 years old software package that its vendor support will end in a couple of days?

chrissimpkins commented 7 years ago

@khaledhosny from a user standpoint many may be hanging on to that version to avoid the new subscription model

davelab6 commented 7 years ago

I'd say yes for another 3 years

On Sep 29, 2017 12:21 PM, "Chris Simpkins" notifications@github.com wrote:

@khaledhosny https://github.com/khaledhosny from a user standpoint many may be hanging on to that version to avoid the new subscription model

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/googlei18n/fontmake/issues/360#issuecomment-333171917, or mute the thread https://github.com/notifications/unsubscribe-auth/AAP9y7dJyWNQ9ZTFyF5_hA8wDfOIcxKIks5snRjrgaJpZM4Pog5S .

twardoch commented 7 years ago

Office 2016 for Mac is available as one-time licenses in the Home ($140) and Business ($230) editions. No subscription necessary. It is vastly superior to Office 2011 (while the Windows version hasn’t evolved that much since version 2010).

cjdunn commented 4 years ago

@anthrotype I just hit this error with fontmake related to missing platformID=1

When I set the stylemapfamilyname and stylemapstylename in my designspace file to accommodate style linking in applications like Word or OpenOffice, the generated fonts show up as a conflict in OSX and style linked regular/italic pairs show as duplicates in Font Book (or any style linked RIBBIT fonts). Similar error as described in this issue: https://github.com/fonttools/fonttools/issues/683

I'm using OSX 10.15.3, Catalina, so this is still an issue in 2020 with the latest software.

If I use fontmake to generate UFOs (instead of OTFs or TTFs) from that same designspace, and then generate binaries from those UFOs using RoboFont (which uses AFDKO's makeotf ), the resulting fonts work fine in OSX and Font Book shows no errors.

When I diff the fontmake OTFs vs the RoboFont OTFs I can see the main difference is that RoboFont includes both platformID=1 and platformID=3 name fields for nameID 1 and 2, which I think are the relevant fields for style linking, whereas fontmake only includes platformID=3.

Would you consider adding an optional parameter to include platformID=1 font info names? I think that would resolve this issue, and you wouldn't have to change the defaults. Thank you for your consideration!

madig commented 4 years ago

Which versions of Word and OpenOffice (LibreOffice?) for Mac did you test?

aaronbell commented 3 years ago

Like @cjdunn said, it would be great to offer a flag to include platformID=1 names for greater flexibility in fontmake.

davelab6 commented 3 years ago

This is now needed for Google Fonts releases :) @madig could you fix this if you had time?

twardoch commented 3 years ago

For the Windows entries (PID.EID 3.1), the NIDs 16 & 17 (Preferred/Typographic names) always group all styles under one family name, and the NIDs 1 & 2 provide the RIBBI naming.

For the Mac entries (PID.EID 1.0):

Older Monotype & Adobe OT fonts put the Typo naming into NIDs 1 & 2, and no NIDs 16 & 17 were supplied. This is what FLS5, Glyphs or FL7 does.
But I recently realized that the newest Monotype & Adobe OT fonts (like Futura Now or Minion 3) do it differently: they have the Typo naming in NIDs 16 & 17 and RIBBI naming in NIDs 1 & 2 also in the Mac records, so the Mac and Windows name records are truly identical.

I'm not sure when the font makers made that switch. I wonder if anyone has info on this? I've heard that this new naming is "better" for cross-platform.

Note: this is of course for non-VF fonts mainly.

(If NIDs 16 & 17 would be the same as NIDs 1 & 2, then 16 & 17 are not supplied. This is the case in both older and newer fonts.)

anthrotype commented 3 years ago

Wait a second. I thought legacy Macintosh-platform name records (platformID=1) were in fact "legacy" and as such no longer needed on latest macOS. How come was this issue resurrected now?

This is now needed for Google Fonts releases :)

When has this changed? Is it just to support Mac Word 2011?

m4rc1e commented 3 years ago

@aaronbell I assume you've hit this issue whilst working on the CJK fonts? Do the fonts work in later versions of MS Office?

Personally, I don't see a point in supporting MS Office 2011 anymore since it's ancient. Also, Dave's comment mentioned he'd like to support MS Office 2011 for another three years. That period is now up.

If the issue exists in later versions of MS Word, I'll take a look and make a fix.

thlinard commented 3 years ago

And quoting @brawer (https://github.com/fonttools/fonttools/issues/1170#issuecomment-368492829):

I’ve done some more testing on MacOS 10.13.3.

* If a font contains only Windows names, it works perfectly fine and passes all validation tests on MacOS.

* However, if a font contains _any_ Macintosh names, at least name IDs 1, 2, 3, and 6 must be present for the Macintosh platform for validation to succeed.

aaronbell commented 3 years ago

@m4rc1e honestly, I haven’t run into any issues with the Mac names not being included. A foundry was asking why we didn’t include them (it surprised me that fontmake was not generating them), and I didn’t see the harm in their addition. So I came looking to see if there was any bug related to their generation and found this thread, which seemed to indicate that there was still reason to include the names (per CJ’s comment).

If the consensus is to drop them, I’m fine with that. And will explain it to the foundry.

aaronbell commented 3 years ago

I guess a follow up question would be—if there is someone out there who wants to use fontmake and wants Mac names (for whatever reason), why not provide them at least the option (via a flag) to add the names easily rather than requiring they go through and automate it themselves?

madig commented 3 years ago

Fontmake's code is organically grown enough that adding yet another switch without good reason is not a good idea.

anthrotype commented 3 years ago

I suggest we close the issue as wontfix.

aaronbell commented 3 years ago

My only concern is that fontmake is doing something that none of the mainstream type design tools are doing. It could be a significant point of confusion for designers who expect the name table to match between a font exported, say, out of Glyphs, Robofont, or Fontlab, and one generated by fontmake, and may not understand that the Mac names are no longer necessary.

So if you want to close this issue as wontfix, I suggest including some language somewhere that will call out this difference.

googlefonts / fontmake

Mac legacy names and cmap needed in Word for Mac #360