- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 23 Oct 2018 07:39:55 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Fonts`, and agreed to the following: * `RESOLVED: local() matches against both full font name and postscript name` * `RESOLVED: Investigate whether it's practical to implement multi-locale name matching` <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: Fonts<br> <fantasai> drott: I raised this issue<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/3177<br> <fantasai> drott: It's about the local() value of font-face<br> <fantasai> drott: Used for uniquely identifying font on the local system<br> <fantasai> drott: Identifies one font<br> <fantasai> drott: Current description that it can only match the ??? name and the ??? name<br> <fantasai> drott: First want to expand it to ???<br> <fantasai> drott: We want the authors to have more success in actually matching the font<br> <myles_> s/???/Arial Bold Condensed/<br> <fantasai> drott: Currently spec asks authors to add both names to the src descriptor<br> <fantasai> drott: So current proposal is to match both, help authors have more success in matching thefont<br> <fantasai> drott: Second part of the proposal is about which locale/language to match against<br> <fantasai> drott: Currently the spec says only match the US-en version first<br> <fantasai> drott: If this one cannot be found, then try to match the first one encoded in the font<br> <fantasai> drott: I find this aspect of the font rather arbitrary, and don't think we should be doing this<br> <fantasai> drott: I'm not so worried about conflicts here<br> <fantasai> drott: If any questions, be happy to answer those<br> <fantasai> heycam: Do we have any requirements on matching non-local font names?<br> <fantasai> drott: If you don't use the local() value, you do family style matching<br> <fantasai> heycam: But in terms of what the family name is matched against?<br> <fantasai> drott: family name matches against the family name<br> <fantasai> drott: Fonts have three name entries<br> <fantasai> drott: There's family name<br> <fantasai> drott: and then full font name<br> <fantasai> drott: and postcript name<br> <fantasai> drott: In regular font-family matching, you match that against the family prart<br> <fantasai> heycam: Is it true that some implementations match the postcript name for font-family?<br> <fantasai> drott: I believe so<br> <fantasai> drott: But the matching is not so sharp for family<br> <fantasai> drott: You leave it to the matching algorithm to find the closest font to what you specified<br> <fantasai> drott: But for local() you have to match exactly, that's the intent<br> <fantasai> myles_: I think both of these are good for the web platform, I just dont' know how to actually implement them.<br> <fantasai> myles_: If someone knows how, that'd be great, happy to do it.<br> <fantasai> drott: Maybe don't specify as a MUST<br> <fantasai> drott: But I think we should remove the current specification that says english first, otherwise physically-first entry in the name table which seems pretty random<br> <fantasai> drott: I think Firefox implements this on all platforms<br> <fantasai> drott: Windows has DirectWrite API<br> <fantasai> drott: Fixing in Chromium, I also did this on LInux and Android so far<br> <fantasai> drott: Maybe not with CoreText, but iI think we can find a language that would allow implementations to do this<br> <fantasai> astearns: Is your suggestion to keep English first, but allow other matching, or drop any mention of English?<br> <fantasai> drott: I would prefer to match any<br> <fantasai> astearns: Do you have any particular spec language or just looking for agreement to go in this direction?<br> <fantasai> drott: don't have spec language ready, but agreement to go in that direction would be OK<br> <fantasai> astearns: so proposed resolution is to loosen font name atching requirements and allow more matching than is curretnly allowed<br> <fantasai> drott: Specifically to match both font names, and secondly to match against all languages<br> <fantasai> dbaron: Allow or require?<br> <fantasai> astearns: For the first part, full name and postcript name, would that be allowed or required?<br> <fantasai> drott: Required<br> <fantasai> drott: But for second part, locale-matching, would allow. not sure there's consensus to require<br> <fantasai> dbaron: My concern is that we'll end up in situations where impls do diferent things<br> <fantasai> dbaron: I'm more comfortable going with a requirement either way than to do MAY<br> <fantasai> dbaron: What we'll end up with there is someone haveing a web-compat problem and have to go fix it<br> <fantasai> dbaron: If that impl can't implement it, then we have a bigger problem<br> <fantasai> myles_: Agreed<br> <fantasai> myles_: Part of this issue for me is relying on API that isn't clear what it's doing<br> <fantasai> drott: I see your point<br> <fantasai> drott: I would prefer a requirement as well<br> <fantasai> drott: Would be hopeful we can spec that<br> <fantasai> drott: Otherwise just widening allowances makes sense to me<br> <fantasai> dbaron: Maybe give Myles a chance to see what CoreText can do?<br> <fantasai> dbaron: We should care what platform APIs offer when we spec these things<br> <fantasai> myles_: Is CoreText the only API that's concerning here?<br> <fantasai> drott: I looked at FontConfig and DirectWrite and on Android looked at APIs<br> <fantasai> drott: On fontconfig and directwrite it's no problem<br> <dbaron> I don't know... jfkthame would probably be the person to ask for Mozilla expertise<br> <fantasai> drott: On Android I implemented an indexing method, so possible but might require own indexing<br> <fantasai> myles_: I would like to not parse font files myself<br> <fantasai> astearns: So I guess the proposed resolution is to find better/more ways to match fonts<br> <fantasai> astearns: and try to make requirements a MUST<br> <fantasai> astearns: but we don't have spec language for this<br> <gregwhitworth> fantasai: I agree with dbaron we need to see if myles_ can implement it<br> <fantasai> drott: Can we split the resolution? Can we match full name + postscript name<br> <fantasai> myles_: it's OK<br> <fantasai> astearns: So proposed to match on full font name and postscript name (MUST)<br> <fantasai> astearns: Any objections?<br> <fantasai> RESOLVED: local() matches against both full font name and postscript name<br> <fantasai> RESOLVED: Investigate whether it's practical to implement multi-locale name matching<br> <fantasai> astearns: Might also want to ask the i18nwg if they have any input on this<br> <heycam> fantasai: to what extent are there fonts that have one localization plus english, and someone else has a different localization plus english?<br> <heycam> fantasai: let's say you have a font that's released in Japan and France, and the French version has English and French names, not Japanese names<br> <heycam> ... and the Japanese versoin has Japanese name and English name, but not a French name<br> <heycam> ... I think it was there to handle situations like this<br> <heycam> ... if you force the author to use the English name it could work in more place<br> <heycam> ... it's possible this is not why it's there<br> <heycam> myles_: I've never heard of a font author doing that. usually they just make a font in a particular set of languages<br> <heycam> fantasai: just want to check if this has historically happened in the past<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3177#issuecomment-432131599 using your GitHub account
Received on Tuesday, 23 October 2018 07:39:58 UTC