Will give you Roboto Bold rather than Black? If so, that's expected - it's simply the same issue, in reverse. Does anyone happen to know if oneĭo you mean that under GDI rendering, something like > The wrong font face is applied, like Roboto Bold instead of Roboto Black.
> Sans ExtraLight, Ubuntu Medium and various Roboto font faces. When hardware acceleration is disabled, Firefox doesn't recognize DejaVu If we do add a font-family-compatibility hack of some kind, we can probably resolve these reports as duplicates. I just don't think anyone has been focusing on the issue for the time being, beyond recognizing that it exists and that it's really a case of authors misunderstanding the font family model(s). If and when we decide on a resolution, it should apply to them all. Yes, we have several reports that are really the same underlying issue. > would be useful to group the various reports together. > actually going to be handled on a per-font basis, in which case a meta bug
> between condensed/stretched fonts and light/bold ones. > same problem? It seems like if there was a distinction to make, it would be Why are both bug 584769 and bug 644385 New? Don't they describe the exact But there's not been any clear decision as to exactly what (if anything) to do. I guess the bugs haven't simply been closed as INVALID because there's been some discussion of possibly adding hacks to deal with some of the common author confusion here. Is this recognized as a valid issue or not?Īs explained (here, by Boris and John, as well as elsewhere) this is not really a bug, it is behaving as designed, given that we're dealing with two different font platforms - GDI and DirectWrite - that present different font family structures.
This report is still unconfirmed, while identical ones about other fonts > I hope someone can clear up a few things. (In reply to Gingerbread Man from comment #9)
0 kommentar(er)
