Meeting minutes
<yjbanov_> Travis: Today's primary topic is metrics
<sushraja> ah thanks yjbanov_ if you are picking it up :)
<sushraja> Ill scribe - though I am not experienced at this.
<yjbanov_> Neither am I, but I'm happy to do it :)
<yjbanov_> Travis gives a summary of https://
<yjbanov_> brb: need laptop charger
fserb: formatted text paragraph is same as a block?
Travis: yes
<yjbanov_> Fernando: need to figure how/if the runs are joined during layout
<yjbanov_> Fernando: what is "inlineSize"
<yjbanov_> Travis: it's the dimension along which the text wraps
fernando: 'width' is available on the FormattedText... doesn't that define inlinesize?
sushraja: it allows auto/width to do min-max sizing.
sushraja: inlineSize is availableWidth (not sure about containers)
fserb: not 100% sure that inlineSize is the only properly the matters at this point... device-pixel ratio? Still need to think about this.
<yjbanov_> Fernando: inlineSize may not be the only property that's needed
<yjbanov_> Julia: height limitation may also matter
Julia: height limitation might also affect it. Lots of different factors.
Mouad: maybe other properties are already on the FormattedText object?
… elipses property?
<yjbanov_> Mouad: ellipsis information is typically on the FormattedText onjrvy
<yjbanov_> *object
yjbanov_: can it be made more explicit--in the lifecycle? to explicitly take a snapshot that you intend to keep around?
… 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.
… if the underlying system has collected the metrics, then if you try to use the object, it will throw exceptions.
fserb: fairly confident that you can't do that (throw exceptions)--or shouldn't.
… one solution is to say format() always returns a new object, but the metrics has an "update"
… this would give us the hybrid approach that we are looking for.
… don't like "magically" invalidating
mike: still not seeing the problem...
fserb: seems trying to avoid object creation (in JS)
… would suggest just leave it be.
… might need to see how this looks in practice.
julia: what about editing?
… the key is when you slightly update the data
sushraja: in old model, we let the web author have a combination of metrics where some are correct and others maybe stale.
<yjbanov_> Sushanth: the API could return the same object ot the developer, who can then compute the delta
<yjbanov_> Sushanth: one issue if devs add new properties to objects returned by metrics.
fserb: unrelated issue: potential support for web workers.
<yjbanov_> fserb: potential support for web workers.
fserb: each time I look at this, I see it might be tricky.
sushraja: on dev side, I'm looking at this problem.
<yjbanov_> Sushanth: the difficult part is layout blocks.
mike: from my client's perspective, workers are a requirement.
<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
fserb: just want to make sure the spec isn't impossible to implement.
<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
<yjbanov_> (DOM, Houdini, workers, etc)
<yjbanov_> Julia: need to consider early in the design process that one character can produce multiple glyphs
<yjbanov_> Example: á
<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
<yjbanov_> Julia: HarfBuzz would put combining character next to the main character. This can be engine-dependent.
<yjbanov_> Travis: trying to avoid M:N mapping between characters and glyphs
<yjbanov_> Julia: let's embrace it! :)
<yjbanov_> fserb: mapping is too useful to avoid it (ligatures is another example)
<yjbanov_> Julia: people think about text and graphemes, which consist of many glyphs.
<yjbanov_> So we might need to map to graphemes and/or grapheme clusters.
<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.
<yjbanov_> Julia: an editor that allows editing graphemes internally is a different use-case
<yjbanov_> Julia: we need to provide both, normal text editor use-case, and one that goes _into_ the glyph
fserb: need to know the reason for the n-to-n mapping.
… for emoji... you never want to put in between, but for arabic you might.
yjbanov_: Folks may want to render the accent marks with different fonts!
fserb: there are languages in which the n-to-n mapping doesn't exist.
mike: one possible way to ofganize the complexity...
… purpose for metrics to allow the client to do their own drawing.
… then almost all of this can go away.
… must have x/y positions to draw
… but for editing, it can be pretty hairy.
fserb: that was the conclusion we reached after last three attempts to solve this problem.
… there is a use case to draw on the screen.
… the other use case is a high-level API, but the mid-layer is hell.
… the low-level ops are aweful and intractable.
fserb: you do it the way the browser does...
… it takes decades to solve these problems.
julia: the only reasonable approach, I agree.
sushraja: for caret movement, if your caret is right of several consecutive glyph.
fserb: you provide high-level ops for this scenario.
… backspace and movement are different things!
… must find a set of ops that are meaningful and abstract from there.
sushraja: I understand the general approach.
mike: we should focus on drawing scenarios (which should make some scenarios tractable)
… back mapping is hard, maybe we hide it.
… maybe give less instead of more.
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.
mike: some apps may not take any API we give them.
<yjbanov_> Sushanth: if we expose browser behavior it may be counter-productive for specialized editors (e.g. Word) that do something custom
julia: is it visual order or logical order (e.g., RTL)
fserb: with coordinate systems, be sure the ordering in the lists makes sense.
mike: the font id is useless if I don't know which font it was resovled ot.
<yjbanov_> *glyph id is useless if...
mike: advance may not be important, but x/y is for drawing.
sushraja: q on level of detail for glyphs...
… seems useful for downloaded fonts.
… what do you need to know (beyond size)?
mike: if there's backmapping for size from the data model
… there may be fallback even among my downloaded fonts
… to be sure I have the right font file.
<yjbanov_> Mike: need to know which font was picked
Julia: who defines which font goes where?
… how is it represented here?
sushraja: it's not.
… who implements the font fallback?
mike: whatever the browser would have done.
julia: so it's hidden from the API
sushraja: if we just give the string for the downloaded font, is that sufficient?
mike: as long as it's unique, then yes, it's useful.
yjbanov_: is there ambiguity within the font?
sushraja: with glyph id, that may be enough?
yjbanov_: is font-family enough to not have ambiguity?
mike: it is for downloaded fonts, not for built-in fonts.
sushraja: there may be issues with exposing font-fallback for local fonts.
yjbanov_: being done in "local font access"
<yjbanov_> https://
mike: might need something more than just font-family (good note)
… font-family will be a unique identifier -- should be noted in the spec.
sushraja: note that we are limiting to downloaded fonts for glyph-level metrics.
yjbanov_: speaking of downloaded fonts.. (in Flutter by canvas-kit) have canvas-kit tell us what fonts are missing.
… this is done lazily.
… so if there are fonts that are missing, then it would be nice to know that.
mike: having the ability to know a missing font-mapping is very useful.
Travis: and this could be a good signal for fragments backed by system fonts.
Travis: thanks everyone for attending, and for the collaborative discussion!