Skip to content
This repository has been archived by the owner on Mar 7, 2023. It is now read-only.

Latest commit

 

History

History
127 lines (106 loc) · 18.1 KB

meeting-20201019-4.md

File metadata and controls

127 lines (106 loc) · 18.1 KB
Raw

Minutes of Meeting 4, 2020-10-19, 16:00–18:30 UTC

  • Chair: Liang Hai
  • Scribe: Simon Cozens

Resolutions

None

Actions

  • Ask W3C for a dedicated video meeting space.
  • Discuss meeting time scheduling on GitHub issue.
  • Research setting up IRC/github-bot.
  • @scottkellum, please post more notes from implementation responsive text prototypes.

Attendance

Andrew Glass, Bobby de Vos, Caleb Maclennan*, Chris Chapman*, Cosimo Lupo*, David Corbett*, David Singer*, Duncan MacMichael, Greg Hitchcock, John Hudson*, Johnathan Kew*, Laurence Penney*, Liang Hai*, Mehmet Oğuz Derin*, Nat McCully*, Nate Willis*, Ned Holbrook*, Norbert Lindenberg, Peter Constable*, Renzhi Li, Scott Kellum*, Simon Cozens*, Toshiya Suzuki*, Vladimir Levantovsky*, Zachary Scheuren*

* Formal participants of the FTCG.

The IRC channel recorded the following nicks: liang, simon, Vlad, cjchapman, mehmetoguzderin, alerque, JohnHudson, dsinger, dscorbett, jfkthame, nmccully, Norbert

Minutes

Standing items

  1. Introducing the IRC channel and bots / meeting administration

    • liang: Talking on the channel will get your name into the log. You can use q+ to add yourself to the speaker q-. If you want to chat without being logged, start your message with /me, and you can see simon taking notes. If you see any specific mistakes, especially those about your own speech, use sed s/// syntax.
    • Zakim is the meeting management bot, takes care of agenda items and you can ask it other things. See https://www.w3.org/2001/12/zakim-irc-bot.html
    • Rrsagent is used for logging the transcript.
    • Anything you message into the channel without /me will be logged. Anything you type on the channel is visible to everyone on the channel.
    • dsinger: github-bot is not an official W3C project but we may want to try it.
    • dsinger: You can say "q+ to ..." to tell the bot what you want to talk about. "vq?" command lists queue with these topic attached. please use q+ to because it helps meeting management.
    • liang: Helps you remind yourself what you wanted to say!
    • lorp: Github bot logs to issues?
    • dsinger_: Yes, it's useful.

  2. Code of Conduct

    • simon: If you're here, you're expected to have read the CoC and agree to it.
    • liang: There's a pinned issue pointing to it, we're going to expand it to add more useful things newcomers need to know.

  3. Self-introduction of new participants

    • Dave Singer and Ned from Apple have joined the CG.
    • Duncan MacMichael, program manager of MS DirectWrite. Involved in lifting it out of Windows core as part of Project Reunion.
    • Mehmet Oguz Derin: Lurker, maths student. Wants to propose something that's lacking but wants to lurk first to see.
    • liang: Open an issue in github with your proposal. Don't be shy. The issue tracker is used as a forum, not a bug tracker. I'd like to see more diversity of issues, interesting projects, to give people permission to add anything to the issue tracker.

  4. Minutes of last meeting.

    • liang: Simon transfered the Google Doc minutes to markdown and placed in GitHub report. Last meeting minutes at https://github.com/w3c/font-text-cg/blob/main/minutes/meeting-20200921-3.md
    • liang: Formally created group after last meeting with resolutions to sort out the repo and approve charter. We don't need to or intend to maintain a stable formal charter, it will evolve as we understand more about what we are here for.
    • alerque: That should probably be in the charter itself.
    • liang: It is; the charter has a strong sense that it is a meta-charter, talks a lot about drafting a new charter and possibilities of replacing existing one. On the other hand, as a new small group we don't have to operate in a formal way. Process of producing a new charter is more desirable than formal deliverables. Point is to increase communication and collaboration. Last-minute changes to the charter?
    • simon: Not particularly significant, read the PR if you're interested. https://github.com/w3c/font-text-cg/pulls/1
    • alerque: We implemented branch protection, not as a security thing but as a management one. Nobody, even admins, are allowed to push to main; everyone has to go through a PR. To go along with that, one other person formally approves any changes before they are applied. liang is the owner and simon and alerque are admins. W3C people also have admin access. With a PR workflow we can add more admins in maintainer role to do triage etc. Two people could collude to get stuff in there, but there is notification to make sure everyone knows about it.
    • liang: Last time we didn't take an attendees list. If you know anyone who attended but who is not in the minutes, please raise an issue.
    • liang: Email subscriptions. I use Github mobile. Apps are good for notifications from repos. If you prefer emails, there's a link in the repo to the agenda document. You can configure github to send you emails if you want them.

  5. Chair nomination

    • liang: So far I'm just the acting chair, we only just got through the charter and don't want to take much time with procedural stuff. If you want a chair election, call for one. We should probably do this sooner or later. Let's not do this now because of time and we want to talk tech. Personal understanding is that chair is only meant to do management, not leadership. Simon and alerque also co-chairs. Happy to have acting chair for now but call out if you want an election.

  6. Next meeting schedule

    • liang: Please try to avoid using the public mailing list for discussion. If I see them I will copy them across to Github. Behdad had the understanding that the "leadership" had a specific idea of the scope of the group. If you feel in that way, we should probably talk about that. My personal feeling is that the reason why we are here is to try to provide an umbrella, triage station for any issues. If you think about the specific scope to much you can easily discourage potential contributions from newcomers. We try to be inclusive. Even if the topic is very specific to OT/OFF, it may still be helpful to make sure you start the conversation. All of the existing organisations have specific scopes so it can be difficult for someone outside those groups to work out which one to go to, and the issues may not fall into such a specific scope.
    • Vlad: If the topic is very specific to OFF, you're always welcome to bring it to the AHG.
    • liang: So rather than framing a scope, just talk about interesting topics. We'd like to keep a fixed schedule. Be careful of daylight savings time! Each meeting we'd like to plan out major items to talk about next time, participants can show their interest and we'll try to accomodate that.
    • Vlad: This particular time slot is in conflict with regular weekly scheduled meeting of web fonts working group. We could postpone that group to accommodate this one but with a significant overlap this conflict is not a good thing. As that group has been working with this schedule for two years I strongly suggest we try to avoid this conflict.
    • Peter: This particular tmie slot is in conflict with regular weekly meeting of Unicode officers (I'm on IRC only until that's done)
    • ACTION: Discuss time scheduling on GitHub issue.
    • liang: Monthly plenaries for this group is probably not practical. We need to be more active in Github. Face-to-face meetings are good for hearing others, but we shouldn't count on monthly meetings for too much significant discussions. Try to use the time for FYI, exchange progress.

  7. Recent discussions on the MPEG-OTSPEC mailing list

    • https://lists.aau.at/pipermail/mpeg-otspec/2020-October/thread.html
    • https://lists.aau.at/pipermail/mpeg-otspec/2020-September/thread.html
    • Vlad: Multiple discussions, some not really relevant to the AHG. Brief summary of WG meeting: Proposal submitted for new amendment for extending COLRv1 submitted by Google, discussed at WG, WG recommendation was to start working draft amendment. Highlighted importance of integrating this with variable fonts as variable colour fonts are a more attractive proposition than SVG.
    • One mandate was to seek additional contributions to align variant fonts and colour fonts. Working draft available soon when I've finished writing it. Once it's ready it's approved to be shared publically for comments and review. Tentative plan is that this will remain as a working draft for one or two cycles so we can not only add variable font / colour font integration but that we also have time for further amendments. Will soon brief AHG mailing list on this.
    • liang: What's the relationship of this amendment in the whole context of var/color fonts? Vlad: Currently 3 ways to create colour fonts: COLR/CPAL (MS proposal) painting together TT outlines - limited by single colour per layer, solid colours, no gradients, no opacity etc. COLRv1 fixes. Second way to do it is SVG glyph outlines. Much more expressive tools, colour gradients. Seen as a significant improvement, drawback is that rendering SVG glyphs requires more machinery than renderers have. Web browsers can do it, but font engines generally don't. Third way is colour bitmap tables, two supported formats. Originally Google's 2013 proposal (CBDT) and the Apple format (sbix).
    • Aim of this proposal is to introduce colour gradients (linear, radial) and opacity channel gradients to COLR. Easily integrated to variable fonts as base glyphs are already variable through current TT OTVar. We can make the colour descriptions variable through same mechanism. I believe this will be significantly more attractive than the others. SVG is very expressive but very difficult to connect to existing font engines. Failed call for consensus! Not enough clarity of what the consensus was called for, so resolved at the WG level instead.
    • liang: Big thread with Behdad, Dave and everyone. Big thread on removing CFF2.
    • Vlad: Removal of CFF/CFF2 was inspired by behdad's email. Nobody took it seriously, nobody responded, so behdad interpreted it as agreement. For various reasons I don't think anyone is going to agree to do that.
    • liang: It's a "What if?" I would encourage all of you to provide a summarised document so we can share this information on Github. ** Nobody responded?? (https://lists.aau.at/pipermail/mpeg-otspec/2020-October/002584.html)
    • Vlad: WG has approved MPEG GitHub, so discuss it there?
    • liang: If nobody's on the AHG is interested in pursuing it, it would still be useful for us to have a summary of the discussion for historical reasons. Every month we should be thinking about simplifying the whole mass of alternative technologies we have!
    • Vlad: "We" are a community which can only change something with community-wide agreement.
    • liang: Yes, but that's why an organisation like FTCG can be helpful because we're not necessarily aiming for a particular result. We can have the discussion without presuming an outcome. So there should at least have an FYI so that when someone next month picks up the discussion (e.g. dropping CFF), they will have an easily accessible summary of what did or didn't happen and what was discussed.
    • JohnHudson: There's an interesting question related to the CFF removal. Behdad's provocation is based on the idea that there is no implementation spec for CFF hinting. Although the spec includes hints, there's no specification for how to implement it. Behdad's provocation was to throw it out; alternatively we could complete it. The interesting question is how you specify implementation for something which is designed for multiple implementations. How we address specification/implementation of hinting is something we want to consider.
    • ChrisChapman: This has been addressed two or three times. TT hints are specific instructions at the pixel level and can be precisely specified. PS hints are by definition not precise and implementation-specific. As displays get better, considering all the problems we need to solve, CFF hint definition seems pointless.
    • JohnHudson: The concern is that because it isn't specified publically, does Adobe has secret knowledge to make its rendering better?
    • ChrisChapman: No, Apple's CFF/CFF2 implementation is separate. As we keep saying, anything that respects the guidelines makes sense. There's no Adobe-approved hinting renderer.
    • Lorp: That's clear, we believe you, but someone coming in fresh gets told to go to the freetype source code to understand how hinting works. Seems like there's still a piece missing.
    • liang: Does SVG specify how it should be rasterized in the same way that TT does?
    • Renzhi: As to how to specify what is implementation-defined, ISO has a lot of specs which are implementation-defined. For example C standard says what should happen for a malloc, but not how to implement it. For CFF we could just say "the behaviour of hinting is implementation-defined."
    • liang: Mismatch in people's expectations about how much should be defined by the spec.
    • renzhi_li: In some contexts, hinting is irrelevant. (e.g. plotters) Maybe worth adding a chapter with high-level hints to guide the implementor.
    • liang: CFF is a nested spec in OTT, so we could say "Just see the CFF spec" but sometimes we need more pointers.
    • Vlad: This group has significant overlap with OFFAHG, and we should be aware of the boundaries. We have a scope that involves other work items that are not part of the font format. We should be conscious that we do cross the boundaries. CFF discussion belongs to ad hoc. If you want to change OFF, use the MPEG Github. As far as hints are concerned, TT hints have never been mandatory. Any rendering engine can ignore hints and still be compliant. Same applies to CFF hints.
    • Vlad: With display resolution going up, need for hints going down. Some people thought ignoring hints altogether is not a big deal, especially with complex handheld screens. I agree that hint spec should be lower priority.
    • alerque: I'd agree on the scope comments from Vlad, when there is a specific group where things are more on topic or where active discussion is going on we sould make an effort not to diplicate. When things come up that are not fully in scope elsewhere (of which there are lots of possibilities) then we can dig in and find the right venue for them.
    • liang: Every group has its own priorities, which is why it's not good to think about boundaries too much - it ends up in self-censorship.
    • Vlad: Just be sensitive, there are some processes we need to follow.
    • liang: So long as we don't cross the patent boundary (which is only applicable to contributing technical work)

  8. Group proposal: Responsive text tooling (#12)

    • Scott: Biggest issue I've seen with variable fonts is a gap between layout and font implementation. Expectation the variable fonts will change over different widths such as widths of viewport and container. No control within CSS to adjust the variation based on these parameters. We can set the axes but can't scale e.g. width axis based on browser width. Simply not possible in pure CSS.
    • alerque: Not just CSS, the same issue exists in print layout too, there is virtually no mechanism for this out there beyond custom scripting.
    • liang: I read the proposal a bit and my understanding it's about exposing enough CSS API to font formatting so variable fonts get information from layout engine. We could say it's CSS WG scope and we could move it there. Why did you propose it here and not CSS WG?
    • Scott: Have also proposed to larger CSS working group. This is relevant to fonts and layout.
    • renzhi_li: Just a note on responsive text, not just CSS, PowerPoint shrinks the font if you have too much text in the box. Other software may also use this for adjusting layout. Maybe useful for AR. May be a variation of opsz.
    • liang: Scott's proposal talks about CSS but it's helpful to take these broader perspectives. So how do we proceed with this proposal?
    • Lorp: On the idea of the width axis responding, I discussed it with Florian as potentially part of CSS. Binary search only way to determine width axis. Defining it analytically is less interesting to the CSS WG!
    • liang: So not just a matter of exposing APIs, also mathematical issues. What about Houdini(?)
    • scottkellum: I have prototyped techniques to make it work, a lot of it is possible with fusion of web technologies. I don't necessarily think there is a quick fix or a simple solution. It's between web layout and font interaction, and the varfont spec. Lots of prerequisites - element3(?) spec which will define the container, container width Javascript API, various other proposals. Long-term initiative.
    • liang: Rather than resolving it into a spec, perhaps we need guidelines and toolings for people to efficiently link these approaches.
    • Peter: Scale for width axis was defined so it would lend itself to binary search heuristics. Any time you are doing justification you are going to try lots of things to see what gets the best result. From your proposal are you really talking about width axis selection?
    • scottkellum: No, this is an example. Typesetting in a way that responds to changes in layout.
    • Peter: So potentially making any number of choices on the font selection based on layout.
    • simon: Communication between shaping and layout, newbreak etc. JSTF
    • JohnHudson: Many issues discussed in OT that have been stalled. Have posted some of those on this groups github. Want to draw your attention to those items. Previous discussions were private so didn't want to give too much detail. One item is post-line-breaking layout. This was pre-OTVar. Being able to do some kind of layout (GSUB/GPOS) which currently happens before line breaking but is also segmented into glyph runs, but once you've done your line breaking you can then do contextual subs etc.
    • liang: Thank you for posting earlier discussions to a more accesible place.
    • Lorp: The limitation with min-max clamping is a significant one. New functions will be useful for layout - giving calc a full range of functions seems obvious.
    • liang: Scott, please post notes.
    • ACTION: Scott, please post more notes on this.