MS Word (Office) for Mac Issues: Troubleshooting, Contracts, and EULAs

Mac versions of MS Office—and in particular Word—do not always show installed fonts in the font menus. Microsoft’s advice for this is: “Third-party fonts are not directly supported in Microsoft Office for Mac applications.”

Troubleshooting Word bugs can eat up a lot of time, which made me wonder, have any type designers started refusing to support Microsoft Office for Mac? Is anybody writing a troubleshooting clause for Office into font contracts stating that Word for Mac support could require costly troubleshooting at the client’s expense? Has anyone put a notice into a EULA stating that the font simply might not Work in Office and that no support will be provided?
Tagged:

Comments

  • Alex Kaczun
    Alex Kaczun Posts: 163
    I was not aware of the Mac MS—Office font install issues. I've not had any inquirers from any of my online vendors due to my OTfonts not installing properly or failing to show up in Mac MS Office font menu. I always test on my Mac before I distribute fonts.

    But, if it should become a major concern I will add that clause to my EULA notice.

    Thanks for the heads-up, James.

    Are there any more specifics as to why these issues? I would be interested to hear more.
  • John Hudson
    John Hudson Posts: 3,227
    edited April 2013
    The issue relates to single-fonts (i.e. without style-linked family members) and style families with more than four standard entries.

    Adam Twardoch has thoroughly documented the issue, as of last August. See
    the latest version of his family naming guidelines here:
    http://forum.fontlab.com/index.php?topic=313.0

    See also:
    http://typophile.com/node/95677
  • John Hudson
    John Hudson Posts: 3,227
    PS. The whole thing seems pretty plainly a Word bug to me, and the “Third-party fonts are not directly supported in Microsoft Office for Mac applications” line -- while understandable in terms of MS avoiding having to troubleshooting particular fonts -- doesn't excuse them from implementing the OT name table spec in a consistent and predictable way.
  • I have considered that issue and frankly would like to do it. I have little faith in anything made by Microsoft and don't need the hassle, having already been through it. If everyone indicated an inclination to get on board I would be at the front of the line.
  • James Puckett
    James Puckett Posts: 1,998
    Thanks, John. I did not realize that this was related just one problem.
  • John Hudson
    John Hudson Posts: 3,227
    edited April 2013
    We can't be expected to support broken apps at the expense of standards in retail fonts.
    I'm glad to see this attitude expressed. For many years, I watched with a certain amount of dismay as my colleagues introduced hacks into fonts in order to accommodate what seemed to me bugs or limitations in applications. As someone who makes a lot of fonts within the development cycles of operating systems and major applications, I'm perhaps spoiled in frequently being able to tell my clients that the problem is theirs to fix, and I'm sympathetic to those colleagues servicing graphic design or other non-software markets, who sometimes have to do whatever it takes to get a font to work. But in the long run it does us no lasting good to circumvent specifications and break standards.
  • 100% agree with what Jackson said.
    I will keep naming fonts as usual.

    A word processor app than can't handle fonts? A bit ironic...
  • I've never had a problem making a single set of fonts that work in MS Office (Mac & Windows) + all your favorite design apps. So it is possible.

    As for standards, bear in mind that this cuts the opposite direction too — type designers sometimes seem to assume that every program handles fonts like InDesign. Not so. I occasionally get complaints from MS Office users about other fonts they've bought (!) The most common of which is that their new "pro" fonts don't have style-linking implemented, so using the italic & bold key shortcuts in Word won't produce the right results.
  • Matthew, the problem in Office for Mac does not occur for font families consisting of the four RIBBI styles.
    And as for standards, if Office for Mac would treat fonts exactly like Office for Windows then there would be less of a problem.
  • I've never had a problem making a single set of fonts that work in MS Office (Mac & Windows) + all your favorite design apps. So it is possible.
    Your families are not big enough then. :)
    The most common of which is that their new "pro" fonts don't have style-linking implemented, ...
    That is a different story.
    The Word for Mac problem in question can be reproduced with some of Adobe's fonts too which are the opposite of low-quality fonts.
    Not style-linking a family's styles is sometimes done for good reasons, by the way. As soon as a family gets bigger, and depending on the number and gradation of weights, you may end up with left-over weights for which there is no match.
  • Your families are not big enough then.
    Wirklich? I was actually going to say “… and the secret of my success with Office has been following Karsten Lücke's excellent advice about metrics and naming.”

    In particular your point that for full backward compatibility, one should “use[] only four standard styles (any additiional one would confuse Windows).” This has been the guiding principle for all my family naming. It has worked well, first with a font family of 12 styles, and most recently with a family of 18 styles.
    you may end up with left-over weights for which there is no match.
    The problem with ignoring style linking is that office users have to work with a lot of documents that presume the existence of bold / italic / bold italic styles. In my most recent family I used Robofab to automatically clone certain styles under multiple names so that the user always gets the right visual result. (e.g., Light Weight + Bold Style is the same as Book Wt + Bold Style is the same as Medium Wt + Bold Style is the same as Bold Wt.)
  • Ben Blom
    Ben Blom Posts: 250
    Although I do appreciate Adam's ingenuity to come up with a workaround for a nasty problem in Word 2011 for Mac — I decided, after thinking about this for quite some time, to continue to follow his earlier font family naming recommendations (which are consistent with Karsten Lücke's recommendations).

    Concerning style links between different weights in my eight-weight font families, I am used to offer more than just a style link between the Regular (400) and Bold (700) font. If I would follow Adam's new recommendations, I would be forced to remove these other weight style links. I do not want to remove this functionality from my typefaces — neither from the new ones, nor from the old ones — because I believe this functionality is appreciated by those who are used to use style links.

    To me, Word 2011 for Mac is like a bad kid in the class, causing good-behaving kids in the class problems, by forcing a reduction of functionality. I do not want to give in to this bad kid.
  • I do not want to give in to this bad kid.
    There are other problems with Word 2011 for Mac, I have constant trouble with the cursor/mouse operation, search and replace function, styles and font handling. I think it's the worst MS Word incarnation ever. I would not recommend adjusting type design workflows for this beast. It will be extinct soon, if there is any darwinian justice out there.
  • [Deleted User]
    [Deleted User] Posts: 0
    edited April 2013
    In particular your point that for full backward compatibility
    That's why!

    It did not occur to me that you might be doing this because most families that I have seen follow Adobe's naming convention, creating a single big family via name records with NID 16/17 (Win) and 1/2 (Mac), so that users see one family in CS applications rather than multiple four-style families. It is good to know that designers accept the latter too. (The thin line between user expectations and making it work.)
    In my most recent family I used Robofab to automatically clone certain styles under multiple names so that the user always gets the right visual result.
    That's a good approach.

    Ben Blom – Consider my PDF as providing not recommendations but illustrations of essentially two approaches (you may 'interpolate' between them) with some variations (like the one Mr Butterick reminded me of) and the possible effects they may produce.
  • I had just posted a similar question today, but stumbled on this one through a google search.

    In my case the 5 fonts all share the same first word in the name, but are not style linked. The smaller basic version just has the name and that's the one that does not show up in Word for Mac. I am wondering if Word is trying to treat them as if they were style linked and, not seeing anything beyond the first word in one version, just ignores it. Since Word has the 4 style only restriction 5 fonts with the same first title word may be the trigger.