Whether or not a change will be implemented, this situation should be clearly explained in the MDN font and font-family articles (and maybe font-weight and font-stretch as well).
> to get Roboto Black across both platforms, something likeĬhrome's workaround has an interesting side-effect, in that it results in spurious "fake" font-family names being recognized: The default font, Times New Roman is used instead. Results in Chrome using the Times New Roman *Bold* face (note that there is no *Black* face of TNR).ĭoes NOT use Times New Roman Bold, it falls back to the 'sans-serif' generic. It's also interesting to note that Chrome does this family-name hacking on Windows/DirectWrite only, which means that if the exact same set of fonts (e.g. the full Roboto family) is installed on both Windows and macOS machines, it will behave differently: on macOS, "family" names such as "Roboto Thin" or "Roboto Black" are NOT recognized, whereas they are on Windows. This seems like an unfortunate inconsistency, and tends to limit the webcompat utility of the workaround: sites that rely on such legacy GDI-style names may still fail on other platforms. I've been experimenting with some possible approaches here, and I think I have a patch that works reasonably well. * If the CSS font-family property calls for a family name that isn't found, we check if the name includes a space.
* If so, it's possible this is a "styled family" name (like "Arial Black" or "Fira Sans Heavy" or "Segoe UI Light"). Strip the last word off the font-family name to give a candidate "base family name", and see if that is available. * If it is, then iterate over the faces in the base family, and check the 'name' table of each to see if it has a legacy family name (like "Arial Black") that differs from the preferred family name ("Arial").
* Add new gfxFontFamily objects for any such legacy families to the gfxPlatformFontList, and then re-try the original font-family search.
0 kommentar(er)
