16:49:54 RRSAgent has joined #webfonts 16:49:54 logging to https://www.w3.org/2022/03/08-webfonts-irc 16:50:08 Zakim has joined #webfonts 16:57:02 chris has joined #webfonts 16:58:20 Vlad, I sent an agenda+ https://lists.w3.org/Archives/Public/public-webfonts-wg/2022Mar/0005.html 16:58:51 rrsagent, here 16:58:51 See https://www.w3.org/2022/03/08-webfonts-irc#T16-58-51 16:59:13 rrsagent, make logs public 17:01:54 myles has joined #webfonts 17:02:29 Garret has joined #webfonts 17:02:44 present+ 17:02:52 zakim, start meeting 17:02:52 RRSAgent, make logs Public 17:02:53 Meeting: Web Fonts Working Group Teleconference 17:03:52 present+ 17:04:02 present+ 17:05:55 Chair: Vlad 17:06:16 Topic: Publication of historical documents 17:07:11 Chris: came across document from 1996 on downloadable fonts. But it's currently member only. I think we should publish it as a note because it's an important historic document. 17:07:52 Chris: back then working group was just a mailing list. 17:08:15 jpamental has joined #webfonts 17:08:21 Chris: then got moved into CSS working group, and first draft was published as part of CSS working group. 17:08:37 Chris: the requirements document is interesting because it documents what we were thinking about. 17:08:47 jpamental present+ 17:08:49 Vlad: no reason to not publish it. 17:08:52 Garret: agree. 17:09:11 Resolution: publish 1996 web fonts requirement document. 17:09:46 Vlad: next agenda item is open PRs 17:10:08 Topic: open PR documents 17:11:07 Garret: two open PRs. One PR is waiting review from Myles. The second should be good to go. 17:11:18 Myles: don't block on me, I'll retroactively fix any problems if needed. 17:11:22 Garret: sounds good, I'll merge it. 17:12:28 sergeym has joined #webfonts 17:12:35 present+ 17:12:54 present+ myles 17:13:05 Chris: re: the tag PR should we merge this as is and have follow on PR's to add the remaining tags? 17:13:07 Garret: yes 17:14:12 Chris: on the overview PR Vlad still has requested changes, you'll need to change your review to approve before we can merge. 17:14:59 Vlad: now looking at open issues. 17:15:09 Topic: Open Issue 17:15:30 Vlad: issue was opened along side the overview PR. I think we need to be more specific about what implementations are supposed to do when they support range request. 17:15:49 Vlad: issue 79 17:16:40 Myles: so you'd like more info about mapping bytes to glyph ranges. 17:16:57 Vlad: if your an implementer you expect the spec to tell you what to do in your implementation. 17:17:08 jpamental has joined #webfonts 17:17:15 Myles: when you say incompatible can you describe that more? 17:17:31 Vlad: if the spec says nothing about what needs to be done, there's nothing we can test. 17:17:57 Myles: could you give an example of something the spec should say. 17:18:49 Vlad: in case of patch subset we require implementation to calculate glyph coverage so alternate forms are provided to the client. So we have some info about what subsets need to be created. Range request says nothing about what the implementation should be. 17:19:16 Myles: one thing I should add is that clients should be running shaping to determine what glyphs are necessary, and add text about how to turn that into byte ranges. 17:19:32 Vlad: we can also mention that shaping should also include processing of CSS feature settings. 17:19:40 Myles: sounds reasonable. 17:20:15 Vlad: in the process of doing that we can figure out what parts should be subject to conformance testing. 17:20:30 Myles: conformance testing would check that at least certain bytes are requested. 17:21:12 Vlad: we can adopt similar approach from woff2/woff1 we have content that ends up selecting alternate form of glyph and have special font that was the word pass. If everything is done right you see pass. 17:22:24 Chris: will shaping need to be re-run once more of the font is loaded. 17:24:01 Myles: split into the initial request and the subsequent request. After the glyph data is loading more shaping may be needed. 17:24:31 Vlad: shall we review other open issues? 17:24:37 Garret: yes 17:25:45 Vlad: issue 75. 17:26:24 Garret: responded to this waiting to hear back more from mark. 17:26:31 Vlad: shall we ping the issue again? 17:26:34 Garret: yes. 17:26:47 Myles: don't think we should require client hints since not all browsers implement. 17:27:32 Vlad: next 74. 17:27:40 Garret: looks like this is one for Myles to review. 17:27:43 Myles: will review. 17:29:51 Garret: for this one I think there's a misunderstanding. PatchRequest has a field "indices_needed" which I believe they think refers to glyph indices, whereas this is actually for unicode codepoints. I can comment on the issue to explain more and should consider renaming the field. 17:31:40 Vlad: number of issues opened by Myles that look like notes of changes needed 17:32:25 Myles: yes I'll take a look at those. 17:32:47 Myles: these where comments from the merge pull request that I made into issues. 17:34:19 Vlad: next I opened an issue about selecting which IFT method to use. I believe it should be up to the author to pick which method should be used. 17:34:33 Vlad: from the tests we know there's different behaviours for the two methods. 17:34:38 Jason: should there be a default? 17:35:10 Vlad: right now CSS allows author to specify tech incremental the user agent needs to support both. 17:35:35 Myles: it's problematic to require browsers to support both before being able to ship one of them. 17:35:50 Jason: should the author be able to set a preference? and then falls back. 17:36:15 Chris: for example you specify an order of formats in order of preference. 17:36:34 Myles: here the technologies can co-exist. You can have a server support both. 17:36:59 Vlad: need to give control to the author. For them to choose both methods need to be supported. 17:37:15 Jason: in order for it to be successful, there should be a default better than the current state. 17:37:42 Jason: what was successful about VF was the ability to rollout at scale transparentl3y. 17:38:13 Myles: people who have control over CSS don't have control over their server. So if the server has both, both can be tried. 17:38:32 Myles: makes sense that both exist and can make an automatic selection makes a lot of sense. 17:39:41 Garret: agree with Myles we should allow browsers to rollout the tech incrementally and initially implement only one method. 17:40:11 Myles: Vlad, are you imaging if the browser tries to use a different mechanism the server rejects it. 17:40:32 I have made the request to generate https://www.w3.org/2022/03/08-webfonts-minutes.html chris 17:40:59 Vlad: my goal is that browsers are capable of doing their best. So that needs them to support both. 17:41:09 I have made the request to generate https://www.w3.org/2022/03/08-webfonts-minutes.html chris 17:41:32 Myles: with specs we can hope the browser can implement the technology, but we don't need enforce this. 17:41:42 Vlad: I don't want to enforce, but encourage both. 17:42:10 Myles: agreed. 17:42:13 Garret: agreed. 17:42:34 Jason: if we describe it in a way that if a browser has both implemented it can try both. 17:42:57 Jason: it's best if the author can suggest a preferred method. 17:43:39 Jason: should be able to influence loading. 17:44:05 Garret: maybe we need the supports 'incremental' to be split into two values? 17:44:51 Vlad: issue that was opened on css fonts side (#6982) 17:45:00 CSS fonts issue https://github.com/w3c/csswg-drafts/issues/6892#issuecomment-995954028 17:46:04 Myles: currently the spec only has 'incremental' 17:46:21 Garret: I see the issue has a request to split that into 'incremental-patch' 'incremental-range' 17:46:41 Garret: if we are in agreement we should follow up with CSS to make that change. 17:47:02 Myles: disagree, it may be confusing since it could still fallback to the other method. 17:47:14 Jason: if we update the wording around that could help clear up confusion. 17:47:38 Myles: the css other knows less about net conditions then the browser does. 17:47:48 Vlad: but CSS author knows more about content. 17:47:56 Myles: wouldn't the browser know more. 17:48:07 Jason: is method selection related more to content or the font. 17:48:26 Myles: analysis, suggests it's mostly based on language. 17:48:52 Jason: may not know the specifics of the content, but may know that a script will work better with one method than the other. 17:49:20 Jason: if we have an idea that this font will work better they can express a preference, and it will still work if the preference isn't supported. 17:49:50 Myles: it is reasonable for a author to make a style sheet and apply it to many pages without testing it on each page. 17:50:09 Vlad: so there's no reason to allow authors to express a preference? 17:50:34 Myles: I think the browser can make more informed decisions in most cases. 17:51:14 Myles: it's API design, I think that the design of this feature should match with design principles about how to get best results. 17:51:44 Myles: allowing authors to express preference that they may not be in the best position to produce the best results, is not the best api design. 17:52:05 Vlad: we do allow that we fonts and font features, why wouldn't we allow the preference for the transfer method. 17:52:39 Myles: because of two reasons, the first is that there is no behavioural difference that a user would observe on a method other than performance. 17:53:12 Myles: because we are in this world we want the decisions to be made by the actor with the best info to make that decision. 17:53:36 Vlad: there's still a difference between decision and suggestion. Want to allow others to make a suggestion. 17:54:17 Jason: if the browsers always going to know better to make that decision, are we confident that the browser can always make that decision. 17:55:07 Myles: let's imagine the world where the author can make the decision of which method to support, I don't think any browser would honour it. Why would a browser ignore it's own heuristics since the outcome is the same for either method. 17:55:44 Vlad: that's perfectly feasible situation for browser to decide what's best. So you're saying that browsers should support both and can make best decision possible. 17:56:14 Jason: it feels like we're optimizing for initial release. When it's going to be expert css users who will use it. 17:56:34 Jason: guess I'm changing my mind a bit, we don't need to add the burden for the css authors. 17:56:59 Myles: I don't think it's true only expert users will use this. If your server supports neither method it will have no affect. 17:57:36 Jason: it's like VF, a small subset initially went out of their way to use it initially. Early adopters. I don't think that's the right audience to optimize for. 17:58:07 Myles: yeah that's what I'm trying to get at. Long term I imagine all authors add this to font face because it's just better. 18:00:26 Garret: my thoughts, there is a mechanism for power users to make a choice, they can configure their server to support only one method. Second, we should make this simple to adopt authors may have a hard time choosing between methods. 18:00:51 Vlad: worried about the case where server only supports X and browser only supports Y. 18:01:44 Myles: the world where a browser supports only supports one, will be defacto the world we end up in since it'll be difficult for browsers to ship both at the same time. So having a browser that only supports one, will likely be the world we are in. 18:04:20 Garret: for further discussion would be helpful if we start with some proposed concrete changes and discuss those. 18:04:54 Vlad: don't have anything specific in mind but we can look at what we can do to encourage implementers to support both. 18:05:59 zakim, list attendees 18:05:59 As of this point the attendees have been Vlad, Garret, chris, sergeym, myles 18:06:16 present+ jpamental 18:06:19 zakim, list attendees 18:06:19 As of this point the attendees have been Vlad, Garret, chris, sergeym, myles, jpamental 18:06:25 rrsagent, make minutes 18:06:25 I have made the request to generate https://www.w3.org/2022/03/08-webfonts-minutes.html Vlad