15:03:23 <RRSAgent> RRSAgent has joined #formatted-text
15:03:23 <RRSAgent> logging to https://www.w3.org/2021/08/18-formatted-text-irc
15:04:22 <Travis> Present+ Travis Leithead
15:05:22 <yjbanov_> yjbanov_ has joined #formatted-text
15:07:30 <Travis> Present+ Yegor Jbanov
15:07:40 <sushraja> sushraja has joined #formatted-text
15:08:05 <yjbanov_> Travis: Today's primary topic is metrics
15:08:29 <sushraja> ah thanks yjbanov_ if you are picking it up :)
15:08:30 <sushraja> Ill scribe - though I am not experienced at this.
15:09:01 <yjbanov_> Neither am I, but I'm happy to do it :)
15:11:10 <yjbanov_> Travis gives a summary of https://github.com/WICG/canvas-formatted-text/blob/main/explainer-metrics.md
15:13:27 <yjbanov_> brb: need laptop charger
15:19:07 <Travis> fserb: formatted text paragraph is same as a block?
15:19:10 <Travis> Travis: yes
15:20:35 <yjbanov_> Fernando: need to figure how/if the runs are joined during layout
15:22:22 <yjbanov_> Fernando: what is "inlineSize"
15:22:40 <yjbanov_> Travis: it's the dimension along which the text wraps
15:24:37 <Travis> fernando: 'width' is available on the FormattedText... doesn't that define inlinesize?
15:24:54 <Travis> sushraja: it allows auto/width to do min-max sizing.
15:25:58 <Travis> sushraja: inlineSize is availableWidth (not sure about containers)
15:27:06 <Travis> fserb: not 100% sure that inlineSize is the only properly the matters at this point... device-pixel ratio? Still need to think about this.
15:27:08 <yjbanov_> Fernando: inlineSize may not be the only property that's needed
15:27:35 <yjbanov_> Julia: height limitation may also matter
15:27:35 <Travis> Julia: height limitation might also affect it. Lots of different factors.
15:28:20 <Travis> Mouad: maybe other properties are already on the FormattedText object?
15:28:35 <Travis> .. elipses property?
15:28:44 <yjbanov_> Mouad: ellipsis information is typically on the FormattedText onjrvy
15:28:48 <yjbanov_> *object
15:32:16 <Travis> yjbanov_: can it be made more explicit--in the lifecycle? to explicitly take a snapshot that you intend to keep around?
15:33:03 <Travis> ... use case: transition animation. Rather than pay cost of layout in the middle of layout; I pre-compute it before the start. Then store it and blast it into the rendering system w/out re-layout.
15:33:44 <Travis> .. if the underlying system has collected the metrics, then if you try to use the object, it will throw exceptions.
15:34:33 <Travis> fserb: fairly confident that you can't do that (throw exceptions)--or shouldn't.
15:35:04 <Travis> .. one solution is to say format() always returns a new object, but the metrics has an "update"
15:35:16 <Travis> .. this would give us the hybrid approach that we are looking for.
15:35:26 <Travis> .. don't like "magically" invalidating
15:36:10 <Travis> mike: still not seeing the problem...
15:36:18 <Travis> fserb: seems trying to avoid object creation (in JS)
15:36:26 <Travis> .. would suggest just leave it be.
15:36:35 <Travis> .. might need to see how this looks in practice.
15:36:40 <Travis> julia: what about editing?
15:36:55 <Travis> .. the key is when you slightly update the data
15:37:32 <Travis> sushraja: in old model, we let the web author have a combination of metrics where some are correct and others maybe stale.
15:37:45 <yjbanov_> Sushanth: the API could return the same object ot the developer, who can then compute the delta
15:38:31 <yjbanov_> Sushanth: one issue if devs add new properties to objects returned by metrics.
15:38:48 <Travis> fserb: unrelated issue: potential support for web workers.
15:38:50 <yjbanov_> fserb: potential support for web workers.
15:39:01 <Travis> .. each time I look at this, I see it might be tricky.
15:39:10 <Travis> sushraja: on dev side, I'm looking at this problem.
15:39:17 <yjbanov_> Sushanth: the difficult part is layout blocks.
15:40:02 <Travis> mike: from my client's perspective, workers are a requirement.
15:41:06 <yjbanov_> Mike: let's figure out if data model and API make sense in all threads, then we can add more on threads where document model is available
15:41:14 <Travis> fserb: just want to make sure the spec isn't impossible to implement.
15:43:16 <yjbanov_> Mike: it's valuable to bring up alternative sources of metrics, because this way we can avoid bias of the only source we considered
15:43:32 <yjbanov_> (DOM, Houdini, workers, etc)
15:47:15 <yjbanov_> Julia: need to consider early in the design process that one character can produce multiple glyphs
15:48:17 <yjbanov_> Example: á
15:49:24 <yjbanov_> Travis: one idea: the engine could split glyphs into multiple fragments so that fragments can overlap and be positioned on top of each other
15:50:09 <yjbanov_> Julia: HarfBuzz would put combining character next to the main character. This can be engine-dependent.
15:51:02 <yjbanov_> Travis: trying to avoid M:N mapping between characters and glyphs
15:51:08 <yjbanov_> Julia: let's embrace it! :)
15:51:40 <yjbanov_> fserb: mapping is too useful to avoid it (ligatures is another example)
15:52:35 <yjbanov_> Julia: people think about text and graphemes, which consist of many glyphs.
15:52:53 <yjbanov_> So we might need to map to graphemes and/or grapheme clusters.
15:53:49 <yjbanov_> Julia: in text editors, if you click mouse, you need to put the cursor somewhere; cannot be glyph, cannot go inside the grapheme, as it will produce incorrect encoding.
15:54:23 <yjbanov_> Julia: an editor that allows editing graphemes internally is a different use-case
15:54:46 <yjbanov_> Julia: we need to provide both, normal text editor use-case, and one that goes _into_ the glyph
15:55:19 <Travis> fserb: need to know the reason for the n-to-n mapping.
15:55:42 <Travis> .. for emoji... you never want to put in between, but for arabic you might.
15:56:09 <Travis> yjbanov_: Folks may want to render the accent marks with different fonts!
15:56:45 <Travis> fserb: there are languages in which the n-to-n mapping doesn't exist.
15:58:01 <Travis> mike: one possible way to ofganize the complexity...
15:58:22 <Travis> .. purpose for metrics to allow the client to do their own drawing.
15:58:29 <Travis> .. then almost all of this can go away.
15:58:39 <Travis> .. must have x/y positions to draw
15:58:47 <Travis> .. but for editing, it can be pretty hairy.
15:59:33 <Travis> fserb: that was the conclusion we reached after last three attempts to solve this problem.
15:59:39 <Travis> .. there is a use case to draw on the screen.
15:59:52 <Travis> .. the other use case is a high-level API, but the mid-layer is hell.
16:00:08 <Travis> .. the low-level ops are aweful and intractable.
16:00:51 <Travis> fserb: you do it the way the browser does...
16:01:12 <Travis> .. it takes decades to solve these problems.
16:01:36 <Travis> julia: the only reasonable approach, I agree.
16:02:07 <Travis> sushraja: for caret movement, if your caret is right of several consecutive glyph.
16:02:17 <Travis> fserb: you provide high-level ops for this scenario.
16:03:26 <Travis> .. backspace and movement are different things!
16:03:46 <Travis> .. must find a set of ops that are meaningful and abstract from there.
16:03:56 <Travis> sushraja: I understand the general approach.
16:06:45 <Travis> mike: we should focus on drawing scenarios (which should make some scenarios tractable)
16:06:57 <Travis> .. back mapping is hard, maybe we hide it.
16:07:50 <Travis> .. maybe give less instead of more.
16:08:46 <Travis> sushraja: if we define high-level as what the browser does, but the app want's a different data, then it's less useful for that client.
16:09:00 <Travis> mike: some apps may not take any API we give them.
16:09:00 <yjbanov_> Sushanth: if we expose browser behavior it may be counter-productive for specialized editors (e.g. Word) that do something custom
16:10:31 <Travis> julia: is it visual order or logical order (e.g., RTL)
16:11:04 <Travis> fserb: with coordinate systems, be sure the ordering in the lists makes sense.
16:12:58 <Travis> mike: the font id is useless if I don't know which font it was resovled ot.
16:13:14 <yjbanov_> *glyph id is useless if...
16:13:45 <Travis> mike: advance may not be important, but x/y is for drawing.
16:16:57 <Travis> sushraja: q on level of detail for glyphs...
16:17:06 <Travis> .. seems useful for downloaded fonts.
16:17:14 <Travis> .. what do you need to know (beyond size)?
16:17:33 <Travis> mike: if there's backmapping for size from the data model
16:17:53 <Travis> .. there may be fallback even among my downloaded fonts
16:18:02 <Travis> .. to be sure I have the right font file.
16:18:15 <yjbanov_> Mike: need to know which font was picked
16:18:21 <Travis> Julia: who defines which font goes where?
16:18:33 <Travis> .. how is it represented here?
16:18:38 <Travis> sushraja: it's not.
16:18:49 <Travis> .. who implements the font fallback?
16:18:57 <Travis> mike: whatever the browser would have done.
16:19:05 <Travis> julia: so it's hidden from the API
16:19:22 <Travis> sushraja: if we just give the string for the downloaded font, is that sufficient?
16:19:32 <Travis> mike: as long as it's unique, then yes, it's useful.
16:19:58 <Travis> yjbanov_: is there ambiguity within the font?
16:20:10 <Travis> sushraja: with glyph id, that may be enough?
16:21:29 <Travis> yjbanov_: is font-family enough to not have ambiguity?
16:21:39 <Travis> mike: it is for downloaded fonts, not for built-in fonts.
16:22:08 <Travis> sushraja: there may be issues with exposing font-fallback for local fonts.
16:22:17 <Travis> yjbanov_: being done in "local font access"
16:23:00 <yjbanov_> https://web.dev/local-fonts/
16:23:04 <Travis> mike: might need something more than just font-family (good note)
16:23:21 <Travis> .. font-family will be a unique identifier -- should be noted in the spec.
16:23:39 <Travis> sushraja: note that we are limiting to downloaded fonts for glyph-level metrics.
16:25:00 <Travis> yjbanov_: speaking of downloaded fonts.. (in Flutter by canvas-kit) have canvas-kit tell us what fonts are missing.
16:25:13 <Travis> .. this is done lazily.
16:25:28 <Travis> .. so if there are fonts that are missing, then it would be nice to know that.
16:26:58 <Travis> mike: having the ability to know a missing font-mapping is very useful.
16:27:36 <Travis> Travis: and this could be a good signal for fragments backed by system fonts.
16:30:18 <Travis> rrsagent, make logs public
16:30:43 <Travis> Travis: thanks everyone for attending, and for the collaborative discussion!
16:30:57 <Travis> RRSAgent, please make the minutes
16:30:57 <RRSAgent> I have made the request to generate https://www.w3.org/2021/08/18-formatted-text-minutes.html Travis
17:10:17 <Travis> bye, Zakim
17:10:31 <Travis> Zakim, bye
17:10:31 <Zakim> leaving.  As of this point the attendees have been Travis, Leithead, Yegor, Jbanov
17:10:31 <Zakim> Zakim has left #formatted-text
17:10:40 <Travis> RRSAgent, bye!
17:10:40 <RRSAgent> I see no action items