Skip to content
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.

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

Font shows in mac office (Outlook/Word) as garbled characters #329

Closed
nz4ypt opened this issue Jul 16, 2020 · 21 comments · Fixed by #402
Closed

Font shows in mac office (Outlook/Word) as garbled characters #329

nz4ypt opened this issue Jul 16, 2020 · 21 comments · Fixed by #402

Comments

@nz4ypt
Copy link

nz4ypt commented Jul 16, 2020

Environment

Cascadia Code version number: 2007.01
Application (with version) used to display text: mac Outlook 16.38, mac Word 16.38
OS platform and version: catalina 10.15.5
Screen resolution (i.e. 220dpi): 4k HiDPI at 200% scaling (1920x1080@2x)

Any other software? These fonts work fine in mac Excel. Same version (16.38)

Steps to reproduce

Open a new word document, or new email, change font to any of the Cascadia family (code/mono/pl/..), then start typing. garbled chars start to show up.

The names of the fonts from the drop-down list in Outlook or Word are also showing as garbled fonts. They are not recognizable but you know they are the 4 Cascadia fonts installed.

Expected behavior

Should not expect garbled chars show up.

Actual behavior

garbled font name shown in the drop-down list. when selecting one of them, the fonts in main document will become garbled texts as well.

screenshot1

screenshot2

@aaronbell
Copy link
Collaborator

Well that's pretty weird.

I'm not seeing the issue with the font drop down menu, but I can repro the text entry bug. Will contact the Office Mac folks.

@DHowett
Copy link
Member

DHowett commented Jul 16, 2020

I wonder if there's a meaningful difference between the OTF and TTF versions? @nz4ypt which version did you install?

@nz4ypt
Copy link
Author

nz4ypt commented Jul 16, 2020

@DHowett Thank you! That did make a difference. I installed TTF earlier. I re-installed OTF fonts and now able to display properly in the documents.

Screen Shot 2020-07-16 at 5 05 58 PM

However, in the drop-down list, I still see the bad names for each fonts. but when you have one selected, it then shows ok in the text box (like shown in above screen). I tried to remove all fonts, reboot, and add back OTF again, but same issue.

Screen Shot 2020-07-16 at 5 06 33 PM

@aaronbell
Copy link
Collaborator

Hi! The folks over in Office have asked if you could send a Word doc that is exhibiting the problem with the font embedded that they could use for testing. Would you be able to provide that? Thanks!

@aaronbell
Copy link
Collaborator

Unfortunately, we have not been able to repro what you're observing. It might be a font cache issue, but without a repro case, the Office folks can't investigate. As such, I'm closing this bug.

@jjeskovs
Copy link

I have the same issue,
Hgvcjkjkjbb.docx
please attached word document.

@aaronbell
Copy link
Collaborator

Verified that the attached word doc appears to show the issue.

@aaronbell
Copy link
Collaborator

(I’ve forwarded the test case off to Office to take a look).

@aaronbell
Copy link
Collaborator

@jjeskovs Can you zip the font file itself and attach it here? Thanks!

@dougwhitemappen
Copy link

dougwhitemappen commented Feb 2, 2021

Came across this issue while trying to resolve the exact same problem our customers were having with RobotoSlab.

I was able to reproduce the issue with Cascadia Code 2007.01 release, and then with the 2009.22 release.
I believe that Office is having problems with extracting font weights from a single .ttf file.

With the 2009.22 release you guys included a static folder with the individual files for each of the font weights, so I've only got a fix for that release, but I think I have identified the problem.

By uninstalling (./ttf/CascadiaCode.tff) and installing the font weights individually (./ttf/static/CascadiaCode-*) I was able to fix the issue and render the fonts correctly. Similarly, reversing back to the combined font re-introduces the problem.

The font files are located in ~/Library/Fonts so this is scriptable.

Note: You need to fully restart Word to get it to rebuild the font cache.

Before:
image

After:
image

@aaronbell
Copy link
Collaborator

Thanks Doug. I am still awaiting final confirmation from the Mac Office team, but it appears that the problem is related to a disconnect between the postscript naming convention and how Mac Office enumerates the names for the different weights.

I believe I have a fix for this which will be included in the next release of the font. Then you will be able to use the variable font version again :).

DHowett pushed a commit that referenced this issue Feb 9, 2021
This is a significant update to Cascadia Code including a large number
of bug fixes as well as updating the font to offer support for Fira
Code v5 ligature support. 

This update supersedes PR #373.

Closes #262 - ⏎ added
Closes #264 - additional codepoints for control characters added
Closes #281 - `!:` and `!.` added
Closes #290 - `/\` and `\/` added
Closes #301 - `??=` added
Closes #324 - ℞ added
Closes #327 - `<:>` and other variants implemented via the `calt`
  refactoring
Closes #359 - house added
Closes #371 - Added x-height instruction into ttfautohint to control the
  height of the lowercase.  
Closes #375 - Completely redesigned quote marks for better recognition
Closes #377 - updated hinting to achieve more consistent results
Closes #381 - increased height of thetamod
Closes #382 - reduced the width of the hooklefts
Closes #383 - updated heights on esh, glottalstop, glottalstopreversed
Closes #384 - tweaked hinting a little bit. Maybe it'll help :)
Closes #386 - added remaining soft-dotting
Closes #392 - changed designs of angled quotes (they are now round)
Closes #394 - changed former `~=` symbol to a simpler component-based
  version. Should be less confusing now for Lua / Matlab users. 
Closes #395 - makes the underline thicker based on font weight
Closes #400 - increased size of degree

Closes #219 
The full control pictures block has been added (u+2400 to u+2426). For
purposes of rendering, the two letter abbreviations have been used
instead of the standard three letter abbreviations:

Additionally, ss20 includes the oft-unused graphical representations of
these codepoints (for fun!):

Closes #276 (infinite arrows)
Full support for Fira Code's current ligature set (with a few
exceptions). Now featuring infinite arrows!!! 

This involved a full refactoring of the `calt` feature—for those
interested, it now uses forward-looking substitutions instead of
backward-looking substitutions and progressive substitution to reduce
code. This also required some redesigning of the greater / lesser
related ligatures. Please note, I have also removed all the obsolete
ligatures now covered by the arrows code.

Closes #329 
There was a mismatch in the font's postscript naming conventions that
was corrected. Should now render all weights in Word. **Note** there is
apparently an additional bug in Mac Word's implementation of variable
fonts which should be available in an update mid-Feb. 

* Not listed – Reworked the hints for the mod and superscript glyphs so
  that they're bottom-up rather than top-down. This allows for better
  bottom alignments. 

Aside from the above changes, this version also includes many other
small updates including spacing, outline quality improvements, and
fixing hinting.
@thlinard
Copy link

Thanks Doug. I am still awaiting final confirmation from the Mac Office team, but it appears that the problem is related to a disconnect between the postscript naming convention and how Mac Office enumerates the names for the different weights.

I believe I have a fix for this which will be included in the next release of the font. Then you will be able to use the variable font version again :).

Hi @aaronbell

The problem affects every VF from Google Fonts too (tested with Word 16.45 on macOS 10.15.7), is there a way to contact the Mac Office team? I can easily provide sample files.

Otherwise, will the fix scheduled in the mid-Feb update require the type of changes you have made (nameID 4, 6, 17 and 25) to work? If so, I can let the Google team know.

@aaronbell
Copy link
Collaborator

@thlinard

I actually sent an inquiry asking about what changes are being made at the start of the month, but haven't heard back. Have sent a follow up.

However, that aside, I think that the modifications I made to the name table are sufficient to resolve the issue.

In the case of Cascadia Code, the Mac Office's system previously detected the PostScript name as "Cascadia-Code", but all of the font variants were being read in the form of "CascadiaCode-Regular", or "CascadiaCode-Bold".

So the key change that I made was the addition of name table 25. My belief is that use of that field informs the system what the root PostScript name should be (rather than whatever the existing PostScript name is set to). It probably also helped to set name table 6 to drop the "-Regular", but my understanding is that with the presence of 25, it shouldn't have an impact.

Use of "Roman" is for other reasons unrelated to this issue.

@thlinard
Copy link

thlinard commented Feb 12, 2021

Hi @aaronbell

However, that aside, I think that the modifications I made to the name table are sufficient to resolve the issue.

Well, not quite. Here are the menu with the new 4 VF fonts installed (CascadiaCode-2102.03, TTF VF version or static TTF, Word 16.45, macOS 10.15.7):

Cascadia Code-Menu

Edit: I think the problem with the static files is only a cache issue.

The text ("When zombies arrive, quickly fax judge Pat" for the record, even if at this level, the information is hardly useful) is grabled only for the VF version:
Cascadia Code-Text

So the key change that I made was the addition of name table 25. My belief is that use of that field informs the system what the root PostScript name should be (rather than whatever the existing PostScript name is set to). It probably also helped to set name table 6 to drop the "-Regular", but my understanding is that with the presence of 25, it shouldn't have an impact.

Yes, I saw that with your changes, nameID 4 + 17 = nameID 6 = nameID 25 (in the variation of a space or a hyphen).

If Word for Mac specifically asks for this, why not, it won't be much to fix. But I doubt that adding nameID 25 is enough.

I convinced Marc Foley from Google Fonts last year to improve their STAT table, and that involved adding a nameID 25 (and postscriptNameID for the NamedInstance of the fvar table, which you don't do for Cascadia). It was about fixing bugs with Photoshop and InDesign, so now all new VFs that come out of Google Fonts have a nameID 25. And I assure you, that's not enough to solve the support issue in Word for Mac: they all look the same as in the two screenshots I just posted.

@aaronbell
Copy link
Collaborator

Well I don’t quite know what to tell you. I followed the name table structure of https://github.com/adobe-fonts/source-code-pro, which worked correctly on my machine. And in my tests, I did not observe any problems of garbled characters while using the new versions of Cascadia Code.

@thlinard
Copy link

Well I don’t quite know what to tell you. I followed the name table structure of https://github.com/adobe-fonts/source-code-pro, which worked correctly on my machine.

I believe you're not at fault, the fonts are fine. For the static files, the Panose definition is incorrect, but since so many fonts aren't correct on this point either, it shouldn't have any consequences, or at least not as much.

I think there is a serious bug in Word, and the Mac Office team should be made aware of the extent of the problem.

And in my tests, I did not observe any problems of garbled characters while using the new versions of Cascadia Code.

Are you using macOS Big Sur? Or a beta version of Word for Mac? English locale or another one?

@thlinard
Copy link

thlinard commented Feb 12, 2021

On another machine, 1) I installed the static fonts, 2) opened Word, 3) closed Word, 4) deleted the statics, 5) installed the VFs, 6) opened Word. And there the menu issue was gone for Cascadia (but still present for a VF installed without all this protocol).

On the other hand, even if the menu was correct, by choosing a weight and applying it to the text, it was in fact replaced by another font.

Then 1) deleted the VF, 2) opened Word, 3) closed Word, 5) installed the VFs again, 6) opened Word. And the menu issue was back (and the garbled text too).

@aaronbell
Copy link
Collaborator

As I understand it, the Mac Office team is aware, and is issuing a fix this month to resolve the problem. It seems like we'll need to wait for that fix to have this issue fully resolved.

I'm on 16.45, still running Mojave in standard US locale. But my understanding is that the inbuilt DWrite implementation in Word is being used, so the base OS shouldn't matter that much.

Are you able to duplicate the same behavior with Source Code Pro?

@thlinard
Copy link

As I understand it, the Mac Office team is aware, and is issuing a fix this month to resolve the problem. It seems like we'll need to wait for that fix to have this issue fully resolved.

Yes, certainly.

I'm on 16.45, still running Mojave in standard US locale. But my understanding is that the inbuilt DWrite implementation in Word is being used, so the base OS shouldn't matter that much.

Very probably. For example, Word doesn't recognize instances of Skia, which is yet the ancestor for all VFs (it was a VF before VFs, even though it doesn't have a STAT table but only an fvar table), while Apple applications display all of its named instances.

Are you able to duplicate the same behavior with Source Code Pro?

Yes, with Source Code Pro VF TTF version, 1.018R.

@thlinard
Copy link

thlinard commented Feb 17, 2021

Hi @aaronbell

I tested Office for Mac version 16.46 (February 2021 update) today. According to my tests (dummy fonts with fake nameID), the implementation is a mix between the fvar and STAT tables: the named instances are the fvar.NamedInstance but their names are not extracted from their subfamilyNameID, but are built from the ValueNameID attached to the STAT.AxisValue (which is quite… surprising, and sometimes gives the same result as the subfamilyNameIDs, but sometimes not…).

Cascadia Code 2102.03 works fine, but version 2009.22 also: nameID 25 doesn't seem to be used (but your changes weren't for nothing: they are useful for Photoshop and InDesign, with their rather flawed implementations of the VF specs).

If the fonts have been installed before, the contents of the following folders must be deleted:

  1. ~/Library/Containers/com.microsoft.XXX/Data/Library/Application Support/Microsoft/FontCache
  2. ~/Library/Containers/com.microsoft.XXX/Data/Library/Application Support/Microsoft/FontPreviewCache

Where "XXX" is the application's name (e.g. ~/Library/Containers/com.microsoft.Word/Data/Library/Application Support/Microsoft/FontPreviewCache).

@aaronbell
Copy link
Collaborator

@thlinard Thanks for reviewing the update and font! I hadn't realized a new version was released today.

It would have been nice if the team had been more forthcoming with what the update actually does rather than needing to figure things out after the fact, but I'm glad that it seems like the update has solved the problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants