- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 20 Sep 2019 02:42:50 +0000
- To: public-houdini-archive@w3.org
The Houdini Task Force just discussed `Font Table Access API`.
<details><summary>The full IRC log of that discussion</summary>
<TabAtkins> Topic: Font Table Access API<br>
<TabAtkins> github: https://github.com/inexorabletash/font-table-access/<br>
<TabAtkins> github: https://github.com/w3c/css-houdini-drafts/issues/950<br>
<iank_> cmp: I can start by given some info for the proposal for font table access.. current status is explainer and proposal stage, interested in HoudiniTF to give feedback at this stage. No facility to access information for fonts which is local to this system.<br>
<iank_> cmp: No way to build an application to access these font tables. Only way to build a native app.<br>
<iank_> <discussion about blue light><br>
<iank_> cmp: <shows explainer><br>
<TabAtkins> explainer: https://github.com/inexorabletash/font-table-access/<br>
<iank_> cmp: The shape of the API - has a permission request. Proposal to add a naviagator.permissions.request({name: 'local-fonts'})<br>
<iank_> cmp: Then it adds a font enumeration API - e.g. navigaor.fonts.query()<br>
<iank_> cmp: query() method returns an async iterator.<br>
<iank_> cmp: Once you get the font you can query the types of tables, which are then represented as an array buffer.<br>
<iank_> <see explainer><br>
<iank_> cmp: User might interact with a font-chooser to select which fonts are exposed.<br>
<iank_> cmp: This is the shape of the API which we are considering. We'll send an Intent to Implement on chromestatus.com<br>
<iank_> cmp: Can put those links into irc if useful.<br>
<iank_> cmp: That is covering the proposal, at that point.<br>
<iank_> cmp: Questions / comments?<br>
<iank_> myles_: I think there is a few problems with this api, i think they fit into 2 cats.<br>
<iank_> myles_: 1) Mechanical types<br>
<iank_> myles_: on our platform we have a bunch of fonts, which are in AAT format.<br>
<iank_> myles_: If we expect authors to implement their own font engines, folks wont use the AAT format correct.<br>
<iank_> myles_: Similarly for emoji fonts are in a different format.<br>
<iank_> myles_: We have custom information within the files, much of this is standardized, but some of it isn't.<br>
<iank_> myles_: We expose this information through the CoreText API which exposes all this information which is normalized.<br>
<iank_> myles_: Exposing this infromation as raw is not the way to expose this, better to expose different objects.<br>
<iank_> cmp: A mix of mechanical & philosphical.<br>
<iank_> cmp: Point well taken, e.g. divergiving font formats.<br>
<iank_> astearns: It would also be nice to future proof this for future formats.<br>
<iank_> eae: Havne't been able to come up with a standard way to represent all the different formats.<br>
<iank_> eae: I don't think its unreasonable for web developers who are using this to handle the different formats.<br>
<iank_> heycam: What types of developers is this targetted at?<br>
<iank_> eae: More complex apps which are doing typesetting, they bundle the fonts, and cross compile harfbuzz etc. And the web applications can't use local fonts, and these can't be bundled due to licensing reasons.<br>
<iank_> myles_: Native apps don't have access to these?<br>
<iank_> eae: They do?<br>
<heycam> q?<br>
<iank_> myles_: The API for the text system, is CoreText.<br>
<iank_> eae: But you can always access the font files.<br>
<iank_> myles_: But this isn't an API.<br>
<iank_> heycam: Do you know why authors are cross compiling harfbuzz etc?<br>
<iank_> eae: They want to get things like glyph outlines, and selectively apply kerning.<br>
<iank_> myles_: Totally a viable problem, we should solve this, but not convinced that this is the right way to get about it.<br>
<Rossen_> ack dbaron<br>
<Zakim> dbaron, you wanted to ask about alternative entry points to the api<br>
<iank_> dbaron: I wanted to raise a different issue.<br>
<iank_> cmp: Philosphical point?<br>
<iank_> dbaron: one other comment about this - the api as you've shown this, is tied into the font enumeration api, one of the issues, its not clear what the right permission model to get user concent.<br>
<iank_> dbaron: one issue, is if there should be a different entry point.<br>
<iank_> dbaron: Might be better to hook this up to something else.<br>
<iank_> heycam: Eariler you said font-enum api would provide access via the FontFace object.<br>
<iank_> TabAtkins: Yes if you have a webfont you can also access the table from those.<br>
<iank_> cmp: Yes it is the existing FontFace object.<br>
<iank_> dbaron: If thats the case this addresses my concern.<br>
<Rossen_> q?<br>
<iank_> myles_: Also worth pointing out, over the past 3 years, variable fonts have been implemented. Generally considered to be a good thing for web platform. If folks implement APIs to parsing font tables, this success wouldn't have been possible.<br>
<iank_> eae: Thats fair, but we don't expect that the majority of websites would use.<br>
<iank_> myles_: There is the set of websites that want outlines, and want to get outlines on installed fonts.<br>
<iank_> myles_: I wouldn't be suprised if the intersection was very large.<br>
<iank_> TabAtkins: I suspect it'll be design tools.<br>
<iank_> myles_: But would want to render the same on each platform, but wouldn't want the local font?<br>
<heycam> q+<br>
<iank_> TabAtkins: But they might want to access the local fonts b/c we don't have licensing for these things.<br>
<iank_> myles_: The set of websites who actually want this seems very small.<br>
<iank_> TabAtkins: it exists on powerful design tools on desktop.<br>
<iank_> myles_: Or they use webfonts.<br>
<dbaron> I should be clear that I'm pretty sympathetic to Myles's concerns, both in terms of font format evolution and whether this is the right layer to be exposing.<br>
<iank_> TabAtkins: But if someone have bought fonts under various licencing agreements which can't be redistributed.<br>
<iank_> myles_: Talking to a group of people which make a successful web based design tool, and there is another solution to the licensing issue, e.g. could expose a subset of the font .<br>
<iank_> myles_: Not saying this is the best solution, but there are other solutions for the licensing issu.e/<br>
<pwnall> q+<br>
<iank_> TabAtkins: If the way around licensing issue, is to expose only the parts, you also need an app to do that as well.<br>
<iank_> TabAtkins: (and back at square one).<br>
<Rossen_> q?<br>
<Rossen_> ack heycam<br>
<iank_> heycam: Eariler emil, was saying we've tried to come up with higher level apis and failed.<br>
<iank_> heycam: would be good to see the list of requirements for these design tools.<br>
<iank_> eae: Sure we'll try and share as must of these design explorations as possible.<br>
<iank_> pwnall: We are also talking to a successful web design tool, this tool tells a user to install a local server to handle the local fonts on the system.<br>
<Rossen_> q?<br>
<pwnall> ack pwnall<br>
<iank_> myles_: I wanted to ask another question.<br>
<iank_> myles_: A few years ago - there was an API for the local font access API. This API feels similar to this API.<br>
<myles_> https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/G-hC66MRTso/kfWDYhC_BAAJ<br>
<iank_> myles_: Why do you think this will succeed when the other one didn't?<br>
<iank_> myles_: In particular there are a few members from the chrome team which brought up issues with this api.<br>
<iank_> myles_: if you don't have thoughts we can come back to this.<br>
<iank_> eae: yeah no thoughts at this time.<br>
<iank_> TabAtkins: There are differences, might have just been a less mature proposal.<br>
<iank_> myles_: Those differences don't seem that important.<br>
<jsbell> q?<br>
<jsbell> q+<br>
<iank_> cmp: Having reviewed the previous proposal, the table access was the big change/shift from the previous version. Font enum wasn't exposing the FontFace instance.<br>
<jsbell> q-<br>
<iank_> myles_: Not addressing the other questions raised here.<br>
<iank_> myles_: There are also fingerprinting concerns.<br>
<iank_> myles_: Also there is the philisophical question around this, it would all 100% of the text engine to be written in JS.<br>
<iank_> myles_: Having a centralized place trying to get text to work correctly over many years, has worked better than a particular team making a particular usecase work.<br>
<iank_> Rossen_: What is the particular ask?<br>
<iank_> eae: We'll follow up on the good feedback.<br>
<iank_> Rossen_: Lets go to the other propoal.<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/950#issuecomment-533381457 using your GitHub account
Received on Friday, 20 September 2019 02:42:52 UTC