Re: [blink-dev] Re: Intent to Ship: Local Fonts Access API

LGTM3 On Wed, May 11, 2022 at 5:02 PM Yoav Weiss wrote: > LGTM2 > > Thanks for pushing forward the discussions, and landing the spec in a good > place from an interop perspective. > > On Monday, May 9, 2022 at 7:20:53 PM UTC+2 Ajay Rahatekar wrote: > >> Hello API Owners, >> >> Please let us

[blink-dev] Re: Intent to Ship: Local Fonts Access API

LGTM2 Thanks for pushing forward the discussions, and landing the spec in a good place from an interop perspective. On Monday, May 9, 2022 at 7:20:53 PM UTC+2 Ajay Rahatekar wrote: > Hello API Owners, > > Please let us know if there are any outstanding concerns apart from the > discussion on

[blink-dev] Re: Intent to Ship: Local Fonts Access API

Hello API Owners, Please let us know if there are any outstanding concerns apart from the discussion on the Mozilla position , that we can address. The team is targeting M103 for shipping this api. Thanks for

[blink-dev] Re: Intent to Ship: Local Fonts Access API

I LGTM'd in the tool but it didn't show up here, but y'all have my +1. Thanks for getting this done. On Thursday, April 28, 2022 at 5:01:51 PM UTC-7 Joshua Bell wrote: > FYI, non-normative note added. I also followed up on the questions in the > Moz standards position thread, added a few more

[blink-dev] Re: Intent to Ship: Local Fonts Access API

FYI, non-normative note added. I also followed up on the questions in the Moz standards position thread, added a few more notes to the spec as well. On Wed, Apr 27, 2022 at 9:01 AM Alex Russell wrote: > A non-normative note in the spec sounds good. Wouldn't want to block > shipping on it. > >

[blink-dev] Re: Intent to Ship: Local Fonts Access API

If we're going with exposing byte-by-byte representation of the fonts on the user's filesystem, we should make that slightly more explicit. Maybe add a note to https://wicg.github.io/local-font-access/#font-representation-data-bytes clarifying that point? I *think* that lack of normalization

[blink-dev] Re: Intent to Ship: Local Fonts Access API

Normalisation isn't usually a goal for users that want the actual bytes of the local font in order to do the rendering themselves and can be an active non-goal given the ways that folks want to do custom grouping, enumeration, and rendering. Partners have consistently asked us not to remove

[blink-dev] Re: Intent to Ship: Local Fonts Access API

On Wed, Apr 20, 2022 at 4:21 AM Yoav Weiss wrote: > > > On Wed, Apr 13, 2022 at 6:46 PM Joshua Bell wrote: > >> On Wed, Apr 13, 2022 at 6:36 AM Yoav Weiss >> wrote: >> >>> Also, any learnings/feedback from the Origin Trial? >>> >>> >> Not distinct from the dev trial (i.e. developers trying the

[blink-dev] Re: Intent to Ship: Local Fonts Access API

On Wed, Apr 13, 2022 at 6:46 PM Joshua Bell wrote: > On Wed, Apr 13, 2022 at 6:36 AM Yoav Weiss wrote: > >> Also, any learnings/feedback from the Origin Trial? >> >> > Not distinct from the dev trial (i.e. developers trying the API behind a > flag). There was a feature request for additional

[blink-dev] Re: Intent to Ship: Local Fonts Access API

One thing to call out on the thread since it may not be obvious - per the chromestatus entry ( https://chromestatus.com/feature/6234451761692672#details) the API will not ship on Android or WebView at the same time as desktop (W/M/L/CrOs). On those platforms, the API will not appear, so normal

[blink-dev] Re: Intent to Ship: Local Fonts Access API

On Wed, Apr 13, 2022 at 6:36 AM Yoav Weiss wrote: > Also, any learnings/feedback from the Origin Trial? > > Not distinct from the dev trial (i.e. developers trying the API behind a flag). There was a feature request for additional metadata which was implemented, then the request was withdrawn so

[blink-dev] Re: Intent to Ship: Local Fonts Access API

Also, any learnings/feedback from the Origin Trial? On Wednesday, April 13, 2022 at 3:35:02 PM UTC+2 Yoav Weiss wrote: > On Friday, April 8, 2022 at 8:15:42 PM UTC+2 Ajay Rahatekar wrote: > >> Contact emails >> >> ds...@chromium.org, jsb...@chromium.org >> >> Explainer >> >>