- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 16 Oct 2015 19:38:55 -0400
- To: public-houdini@w3.org
Font Metrics, Lineboxes, and Their Interaction
----------------------------------------------
- There was broad agreement that there was demand and need for
exposing font metrics.
- However, there was disagreement as to how the solution should be
approached- should it be use case driven or should it be based
on finding the primitives and then seeing what exposure of
those primitives would solve the majority of use cases.
- Ultimately it was decided that this conversation was too linked
with custom layout to be resolved before custom layout is
discussed.
Custom Layouts
--------------
- There was discussion about the positioning constraints put on
the first level of custom layouts in regards to box layout.
- There were several people concerned that the restrictions on
abspos blocks were either artificial or over-restrictive.
- The decision not to use promise-based layout was explained
as due to performance issues.
- This lead to calls to try and achieve simultaneous
layout or, at a minimum, avoid multiple pass layouts.
- In regards to line layout there is a lot still to iron out, but
the basic idea is there's a measure function that takes a
width, does the segmentation, and you get back boxes that
could have the font metric APIs.
Font Metrics, Lineboxes, and Their Interaction (Continued)
----------------------------------------------------------
- After the further understanding of the progress on custom
layouts, the conversation turned to what is the minimum
necessary to expose for a robust but not over complex version
1.
- There were several people arguing for dominant baseline and
baseline grids as being the minimum necessary to be able
to re-implement flexbox, which is a leading use case.
- Another argument was that the whole picture needs to be
considered, not just use cases, in order to prevent
building something that is only solving one problem.
- Ultimately a group will work offline to find the right spot
between the feeling that there's an existing model for how
glyphs have their metrics and if we don't write down what
their model is there's a chance we'll expose things that
aren't consistent with the actual underlying model and the
desire to expose a simplified version of that existing model
to users in order to both simplify implementations and
increase user understanding of what they can do with this API.
===== FULL MINUTES BELOW =======
scribe: dael
Font Metrics, Lineboxes, and Their Interaction
----------------------------------------------
ChrisL: There are several topics about the font metrics API. What
metrics do you want? Do you want what's in the font, what
the browser returned? In the units the font uses, in
pixels? And in some cases you're better off with lineboxes.
First thing is to discuss that.
ChrisL: Most likely thing you want is the baseline.
Rossen: Should we diagram?
ChrisL: Yeah.
ChrisL: Before I go into this, the overall sketch of how I picture
this working, you point to something in a document and say
what font is used. What font is actually being used
because it can be several options. And you get that data
back and do a polyfill.
ChrisL: Simplest is you pass a selector and get that back, but
it's not good enough. That's the point of the deadrange.
That's another topic, but that's what I mean by point.
ChrisL: You decide you're using language in script x and language
in script y and you decide you want to pull it one
language down. Or you want to do drop caps and we don't
have it.
astearns: Simplest approach I know of is in flexbox you can align
flex items by first baseline. I don't know of a way to
do that with information given in APIs. So being able to
polyfill that first baseline alignment and adjusting
where the boxes are.
smfr: So the UA does first-pass layout and you come and fix it.
Florian: And when you point, you don't mean coordinates?
ChrisL: Point in the source tree.
ChrisL: It's more that you're hidden in some way and you'll reveal
once you've calculated.
ChrisL: One thing you'll want to know if where is the baseline
you'll decide to align this on. This is a common case
where you have an image and want to align. You've also got
x height in Latin fonts, people have expressed that desire.
ChrisL: And the other is you want to know what the actual font is,
some of which is metrics, some of which it is not.
ChrisL: Do I need more diagrams for what we're going for? Some of
this is low hanging and easy to expose.
astearns: For example the font being used and the dominant
baseline in the linebox, they seem to be to be fairly
different things.
ChrisL: Does anyone in the room see this as interesting?
Rossen: It's not us that should be finding this interesting, it's
the use cases that should be telling us.
astearns: I can list more use cases.
Rossen: Are we finding this interesting, yes, the requirements
should be based on use cases.
ChrisL: Mathematical layout is something people want to do,
certainly.
astearns: I've seen the upset reaction from people trying to do
font setting in sophisticated ways.
<astearns> first baseline offset, baseline grids, initial-letter,
aligning anything to typographic measures
ChrisL: They're trying to make assumptions that I want to use this
font and I hard code and if doesn't work because that's
not the font used.
liam: There's tonnes of use cases and we should do those on list.
Being able to align things, when we look at things like page
floats, howcome did some examples and having successfully
presented to usenet, his page floats would be rejected
because they didn't line up exactly with the cap height and
the like and you can't do that right now.
liam: If you're doing custom layouts, which is reasonable in
Houdini, you need access to positions as well as sizes. Just
guessing or hard wiring the line height doesn't work if
there's a superscript. This isn't as simple as it might
sound.
jdaggett: Yes.
smfr: I'm a little confused about how this fits into layout. Every
time the UA lays out the line you have to run script to fix
this up. Unless this is a part of custom layout it would be
nice to get this fixed up before the user sees it.
jdaggett: I guess, I definitely agree that there are a lot of use
cases for a lot of this information, however I think the
danger here is if we take that attitude of we'll just
take a set of end use cases and try and gin up
artificial data structures that provide the information
for those use cases we'll produce something that's a big
mess. That we're producing artificial data structures is
also a problem.
jdaggett: When you have a text frame there are steps. Segmentation
of the data and script structure for the font, when
ChrisL says 'the font' there isn't just the font. In
what astearns has posted to the list there's information
that the first line information is the font. You have to
distinguish the outputs of these different phases. You
have to let them cleanly tweek what they want to and not
get mixed up.
<Florian> Chris did not say "the font *for the line*"
ChrisL: At no point has anyone said this is for the whole line.
This is the first character or first glyph.
jdaggett: My problem is I think you need to look at text
rendering, break down the primitives and see in where in
these step is there information you need to get out. In
a lot of use cases you find things like font selection
is important to expose.
astearns: I agree that we need to explore that stack of things
that happen and hook into the right place. But we also
have the fragment API that is giving things like
position, width, height that are the results of the
layout property we want to hook into. There's a place in
those results to give some of the information that
script layout need to get at the right information.
Rossen: Suppose all these APIs are read only, would that make you
easier?
jdaggett: No. If you look on the list you'll find astearns
proposal for font metrics and it's a mixture of line
metrics and per font metrics. You need to define these
are metrics with a font in general, these are metrics at
the glyph level, these are the line. I think you have to
split these out so it's clear what you're exposing.
You're mixing up elements setting primitives. It creates
extra work for a UA.
astearns: I do agree that not having them all bundled in the same
interface is useful. Setting the attr values so you know
where they're coming from is good.
ChrisL: I'm generally agreeing with you. Being able to iterate
through the segments would be nice. And I take your point
on per font instead of per glyph metrics. I understand
your point about different levels and keeping them
separate.
jdaggett: I don't think we should proceed from use case. We should
proceed from here's the model, here are the use cases,
here is how we can expose these intelligently.
<jdaggett> here's the set of primitives needed for displaying text:
<jdaggett> 1. text analysis and segmentation: Unicode operations
on text
<jdaggett> 2. font selection: mapping of text to set of <font,
text subrange>'s
<jdaggett> 3. text shaping: map <font, text subrange> ==> <font,
glyph id's, positions>
<jdaggett> 4. font data access: <font, table id> ==> binary table
blob
<jdaggett> 5. line placement: <font, glyph ids, positions> ==> set
of lineboxes with adjusted positions
<jdaggett> 6. path extraction: glyph ids ==> path data
<dauwhe> jdaggett: is there a good description of what browsers
actually do (other than browser source code)?
SteveZ: Basically want I wanted to say is I'm also interested in
the line layout aspect of the problem and it's very much
related to this kind of thing. I'm assuming it would be
part, but I don't know so I wanted to put in that that
should be a part of the case.
SteveZ: You want to have line breaking as a piece. It's not per
say part of the font, but it's very much involved as a
part of the process.
jdaggett: I think there are a lot of use cases people talk about
and they take different parts of the problem. I just
dumped in IRC what I put on the list about the different
primitives. I don't think so many people are interested
in doing shaping. I think what people want to do is the
line breaking on this. Given these are the glyphs and
the advances, how will I break lines.
jdaggett: So how do we provide the information and how do I feed
this back into whatever system has been set up?
Florian: I want to go in jdaggett's direction and related this to
the conversation with franremy earlier with the tension
of trying to do things good for use cases and trying to
expose the underlying model.
Florian: Fewer people have an underlying model of the font
pipeline in this room, but I think we should be taking
the same approach.
Rossen: Also it differs between implementations.
Florian: In general I'm agreeing with you jdaggett. We also do
need to look at the use cases to figure out which
underlying concepts are work exposing because it could be
with the use cases some people won't care about parts of
the underlying model.
<liam> [ "the font" - http://www.holoweb.net/~liam/download/font.html
has a base character and an acute accent in different fonts
in é ]
esprehn: Just to direct the discussion, it would be nice to talk
about this in the terms of the Houdini model. I think we
should phrase this where if we let you hook into the line
layout, what should we expose and what would be useful.
ChrisL: I think the fix up after the fact was janky. I think
hooking in is what you want to do.
jdaggett: I was going to say is one way we can short cut is
provide an API that gives access to the tables of the
font. For math layout that's the sanest thing, the level
of detail needed for those people is far beyond.
astearns: That sounded crazy to the jdaggett of a few months ago
when I mentioned it. Having the raw data to do math
layout that aligns with any content the browser itself
is laying out means you have to align to all the regular
layout.
jdaggett: For math layout you have to be able to say this box in
the box tree, this script manages.
astearns: Even when you have complete control over the box, you
might want to align with other boxes.
ChrisL: It is a fairly simple thing that people have been asking
for: expose two base lines and line them up.
jdaggett: I don't want to get deep into supporting someone's math
layout. It's more efficient for you to create a set of
scripts that understand math tables and we can provide
the services to allow you to coordinate where that is.
astearns: And in order to do that coordination, when you expose
the lineboxes or fragments, you also need to give at
least the dominant base line.
jdaggett: My point is more we don't want to spend a lot of time
making an API for math layout.
jdaggett: We want to have a simple thing where we say you make the
math tables and we'll help you coordinate where that
lines up.
astearns: shane you were talking about the hooks you would need to
do your own line layout earlier?
shane: A form of custom layout.
Rossen: But the general area is custom layout.
shane: And you want to leverage the browser's ability to give you
lineboxes.
Rossen: And in this context is where all of this will become
relevant.
iank: Tomorrow with layout we could talk about how line layout
works briefly and for a first level of the spec what is the
bare minimum we could ship with that API and be useful. We
won't be able to spec everything in the first level, so what
is the bare minimum
Rossen: And to refocus the conversation here, because it's still
about fonts and font metrics. Since last F2F you said you
would go and spec all the things you are required in terms
of font and line metrics. Do we have anything written up
in terms of what we're referring to?
astearns: A minimum set of things, not all. We should have a
minimum set that fit reality and show where the data is
coming from and allow for extensions and hooks that
might be needed in the future, but start with something
as small as possible so we don't get into a morass.
astearns: So far all I've got is the e-mail exchanges, but we can
take those and this conversation...
ChrisL: At some point it became clear we needed more conversation
here. You clearly need both.
ojan: Can I propose as a part of custom layout we have a really
barely baked custom layout that we can present and maybe we
could figure out how this and that work together.
Rossen: ChrisL, do you feel you've had enough discussion on this
topic? You have some other topics today. It seems this is
a good and useful discussion after we discuss layout. If
you're okay we can pull the custom layout topic now and go
from there.
Rossen: And then we'll swap pagination to tomorrow. If sounds like
the current topic are going in tangents because there are
two sets of assumptions.
Custom Layouts
--------------
iank: I wanted to get one thing out of the way for box layout, but
we can do line layout.
iank: One thing- this is very much box layout, but I wanted to
start a discussion on what is a minimum viable set of
features we can do for an algorithm. I sent this to the list
in the hope that people would read it and come up with
suggestions.
iank: Basically what we'd like to do if do what flex and grid do
for a lot of it. So remove all the complexity of intruding
floats and collapsing margins. Blockify all the children as
well. If we move to where you can layout children we'll need
a flag later. You can't reorder the DOM tree like flex.
Rossen: So if I want a custom layout myself with a float layout
with line around I can't do it?
TabAtkins: You do it yourself with -- something.
Rossen: Modeling all custom layout types after there are specific
layout types is more restrictive.
TabAtkins: It works for 1/3 of the CSS layout and also tables. And
a number of other layout systems are comfortable in
these. A bunch can be done, you can't do block layout.
For simplistic version 1 making sure we can optimize,
this should be sufficient for a lot of use cases.
<franremy> +1
iank: Your direct children and not all the way down the tree is
another initial constraint.
iank: I also missed abspos is metric-ly handled.
Rossen: So similar to floats?
iank: If you abspos a child of a custom layout, it works on flex.
Rossen: If I want to create a custom layout which handles all the
first level children which also includes all the abspos
items...I may not have control over the properties of the
children, but I still want to process and layout them in a
uniform way. I should be able to position and size. That
abspos becomes transparent is loss for me.
ojan: I pictured this what we would have a separate phase for
position. So there's a separate call back for when you do
position. That didn't seem necessary for version 1.
Florian: If we're thinking of the abspos children of the grid that
you put in the slot, you need version 2?
Rossen: So if I implement grid I have to position abspos on the
grid.
Rossen: I think the limitation you have is somewhat artificial for
the abspos.
Florian: For abspos you don't need full control if you can give it
a custom containing block.
ojan: You need some API and at the moment there isn't one.
Rossen: If you're at the level where an abspos icon is positioned
you should be able to.
ojan: I don't think it's too hard to extend, we wanted to just
stay focused.
TabAtkins: I think we should by default treat them as out of flow.
plinss: There's aspects of abspos where you need to know where
this hit.
plinss: The custom layout should know where to place this.
TabAtkins: Static position is determined by the parent of the
abspos element. If you have a custom layout container
with an abspos child, that container sets its static
position. We can be simple for now with 0,0 or we can
extend later. We can drop an issue now.
dbaron: It seems like there are three different things.
dbaron: Taking over static position of something that's abspos
means ignoring it and placing the other children which is
different.
ojan: I think forcing things to be static position is reasonable,
but I worry authors will be immediately unhappy with it.
Rossen: Layout is about positioning and sizing. I'm going to
position however I want. When we're giving someone else
the layout, we're giving them all the problem space.
ojan: I'm sold.
dbaron: The flip side is in our own engine we used to do that and
we didn't get abspos right for most things until we
switched to where abspos as applied to everything at a
general level.
TabAtkins: I agree.
Florian: I don't think we should take over abspos. We may want to
be abspos aware. You may want to layout within and let
the normal browser take over.
ojan: Grandchild?
Rossen: Once I do layout on the child, one of the returned things
is a collection of what I found that you should layout for
me. You have one more item you have to layout.
ojan: But why do the position: static thing at all?
Rossen: This is the way it works in our implementation. You layout
an item and they give you back a bag of things that was
found somewhere else in the tree and you have to decide do
I take care of this or do I move this up?
Rossen: As part of when you discover the abspos, you have to
figure out the static position and set it up.
Rossen: I think we're going on a tangent.
ojan: This is an open issue and we need to work on it.
liam: The interaction between this and fragments?
TabAtkins: Flexbox and grid turn off everything that could cause
fragmentation. It's not explicitly clear about it and
we should generalize the language a bit more.
liam: It's a big limitation, but it's fine.
iank: Other initial thoughts so far?
iank: What we're thinking for that basic API for this, and this is
writing in the document somewhere, is have a class like API
with three calls. Third is do your layout call where you go
past a whole bunch of constraints and then you can traverse
down your children.
iank: Things like if you are responsible for your children or they
for you is something we haven't figured out.
<iank> https://docs.google.com/document/d/1nYeyLuhFf_Y5No11rsMcAQBFbKcPNQW0DQHV1G4r4uI/edit#heading=h.gycgwg8x982t
iank: This is an example of the layout.
ojan: This isn't the polished end result. This is pseudo code.
iank: This is your current layout mode.
Rossen: So given a fragment....
iank: This is you basically. 'node' could be 'this'
iank: This is where things get more vague is layout. What we have
in this version of the API, you get past a bag on
constraints.
iank: You could mention a world where you want a width constraint
where flexbox has fixed you to a size. You can set
constraints so saying you must be this width or up to this
width.
iank: In this version the child will resolve its own height from
the constraints.
ojan: To clarify, the thing we're picturing is you pass in
everything that is an input to layout and everything that
comes out is an output and you don't have access to anything
else.
ojan: Among the inputs would be your list of children.
ojan: Presumably with positioning your list of positioning
dependents would come out.
plinss: So that implies that all layout of the children would
happen in the same marker.
ojan: Correct. We considered a promise-based API and it was 20x
slower. Some of that could be improved, but I doubt all of
it. I think promised based is too expensive.
plinss: If you have children and they can't lay out in parallel...
iank: There is a version I considered where you give a list of
children to layout now.
plinss: It doesn't have to be a promise per child.
shane: Doesn't have to be a promise at all. It could sit and wait
until the layout is done.
plinss: If you're claiming each child's layout in a loop, if
you're telling the first child to wait you're going to
block.
Rossen: Your point is valid. That you're with such an API you're
restricting synchronous layout. So getting children ready
out of order will make for tricky layout. You can't
position block c before you have a and b.
plinss: But that's how layout has worked for the last 10 years,
I'm talking about the next 10 years.
plinss: One person at least is working on parallel layout.
plinss: When we started this we don't want to bake the existing
algorithm into these APIs. I accept that when you want to
layout a custom block you have to let the children layout.
Let's explore tweaking. Instead of calling individual
children, here's an opportunity to layout all my children,
I'll wait until they're all done.
SimonSapin: The reason this algorithm has to be sequential is this
function is responsible for layouts on the children
and doing recursion.
SimonSapin: If we remove the responsibility from the engine...
Before and after would be two different callbacks. So
if you do it sequentially, I'm starting to have this,
you have the possibility to do something here. Once
you have the children you can do something after.
That's sequential and can be rewritten. After we're
done with one node we can all the children and the
parent together and once they're done we do the second
callback
TabAtkins: So take this exact algorithm and in the line that says
child.layout you can split that into two.
ojan: We considered this but it doesn't work for some layout
algorithms. Flexbox needs to do two pass.
Rossen: You still could. You have to reset the context for the
children and lay them out again and you get a new set of
results. You may want another pass.
plinss: In that scenario you may want to avoid if two different
guys are passing over the children so we don't do four
passes.
astearns: And if you want to do flexbox with this you have to give
the position of the first dominant baseline.
dbaron: How does servo do it?
SimonSapin: I'm not sure we do it yet. Everything we do is one
pass and we have different callbacks.
TabAtkins: We know how to pause a function and resume it later.
They're called generators. The functionality exists. We
can say layout children is a functionality you can
invoke.
esprehn: Generators are against.
TabAtkins: This is a top level function.
esprehn: It's a member of the layout class.
TabAtkins: It's directly called by the OS.
TabAtkins: The question is do we need to limit the number of
children that are laid out.
shane: Why don't we do both and let the author choose?
TabAtkins: We would want to make sure the ergonomics are such that
laying out all your children all at once is the obvious
thing to do.
Rossen: In this context, can you jump to line layout? I'm afraid
jdaggett is past his bed time.
iank: This is less baked.
<iank> https://docs.google.com/document/d/1htU9IM1aJGl2_mFFSg0_2P_wvBEPeHLU424RzyhiOsE/edit?usp=sharing
iank: The core of this is you've got linebox and how it bounds and
baselines which can be bikeshedded. Ignore the promises for
a second. Basically you have a you can say to your content
okay, give me a linebox up to a point where it will break.
So it can be give me a linebox for the next word or next
script boundary.
iank: Or element boundary.
iank: Given your layout mode and the type of breaks, you can find
a list of breaks. You can then split them up into lineboxes.
iank: It's measureRange and it's got your children. On your layout
you can render a linebox.
esprehn: This will all get better names.
iank: Render is place, effectively.
iank: Once you've grabbed your linebox, you modify the bounds and
place it.
shane: We need to split the top-left from the height.
ojan: The core is there's a measure function that takes a width,
does the segmentation, and you get back boxes that could
have the font metric APIs.
astearns: I just added a comment to the first bit. You want to
change hanging baseline to dominant baseline. The rest
you have to define where you're getting those values
because a line doesn't have a single ascent. Are you
giving a first one for the first glyph, a max for the
line? All those things you need to define where they
come from. If that's just the definition or encoded, I'm
not sure.
shane: What's important here is not the set of font metrics, this
is a place holder until we ask experts. You're measuring
text into a box for a browser. All you can say is how wide
the box is and that sort of thing, you get a box back and
you can place it or throw it out. It gives you enough power
to do similar content to what's out there as well as all
kinds of interesting things.
Rossen: In your examples, where are the boxes generated?
Rossen: One of the things line layout does is it takes...let's
assume the input is a some kind of text, it will have to
generate a whole bunch of boxes besides figure out where
it goes. Is the only hook you're envisioning is the only
thing I want you to do is position the next thing with the
box you're giving me?
Rossen: Or do you have access to a subset of DOM with all the
properties and you decide how to generate the box?
iank: In this API we were envisioning that you're just laying out
text. We're not doing splitting of boxes. It's just text.
ojan: Including inlines as well.
ojan: The first version ages ago was plain text but that was not
useful.
shane: You can't do plain text because you need to do inline
blocks.
ojan: That's what I was saying.
astearns: You have a to do saying you have to have a range. So you
give a width and the browser gives you a linebox that
tells you what would fit, can you say here's a linebox
what fits?
ojan: The expert isn't here, but I think he was picturing
something you could do iteratively.
Rossen: Let's forget about text. We're working with generating
boxes that are fragmented. Instead of arranging blocks one
after another, all I have is divs. I have to split at some
point and I want to split a div into two boxes. Explain
how that works.
ojan: I don't have a good explanation and I was hoping for your
input. In Blink's codebase line layout and box are different.
Rossen: I'm asking you to provoke the conversation. In our case
our boxes-if they're for inline or blocks or whatever-are
always done in the same way. The result of layout is a box.
ojan: I want to have this conversation, I think it would result in
a better API.
esprehn: I agree. We thought about this in terms of our
implementation and in terms of disjointed layout. It
seems like instead of blockifying the children you could
do fragmentation-like. We should have that discussion.
dbaron: A few things we need out of this API. One thing is you
need, if you take a range and try and build a linebox, you
first want to know how tall. That was part of the process
of deciding if you want to reject that placement. You
tried placing a line at a width, it has a height, it
intersects, you try again.
dbaron: Another thing you need to know is about what is in the
line block. If you're doing things like floats or margin
notes attached to things in the line block, you need to
know what it's attached to. So if you have margin notes
you want to attach off to the side...maybe that's not this
API.
Rossen: Even abspos items attached to the lines.
SteveZ: You're assuming an anchor of some kind.
dbaron: That was what I wanted to point out. I'll have more
comments when there's more details.
jdaggett: A quick point. I don't think you should assume text
layout works in an interactive fashion. That's how they
commonly work, but that's not the ideal. There's
algorithm that takes a whole paragraph.
Rossen: Yes. We don't want to prevent that and I don't think this
would. I think we're trying to set the framing of how to
think about it.
astearns: So you get a box and you place or reject and that would
preclude getting a bunch of boxes and accept or preclude.
Rossen: That was one suggestion, but I don't think we're at a
point where we can see it's clearly better.
Rossen: Let's run with the assumption that custom layout has
happened and we do have the linebox. I know this is
getting late for jdaggett and there are a whole bunch of
things we should talk on for this and perhaps we can have
a breakout, but I want to move back to the people who
wanted to talk about all the properties that the linebox
would know now that you have it somehow.
Font Metrics, Lineboxes, and Their Interaction (Continued)
----------------------------------------------------------
astearns: You have a start of things that you might want to say
about a linebox that could effect its positioning. Once
it creates a linebox you need to place it somewhere.
What's here with a dominant baseline with ascent and
descent it's the start of the information you need.
jdaggett do you think this is the appropriate place to
put these?
astearns: It seems to me once you have a linebox you have the
dominant baseline and you need to know where it is in
the height of the box to know where to place it when
you're doing baseline grid.
astearns: Or if you wanted to implement a variant system that
dealt with lines going top of cap to top of cap you
might need cap height over the linebox to determine
where to place relative to the other.
Florian: What is the cap height of the linebox rather than the
glyph?
astearns: That's a good question.
jdaggett: This is the point I was making on the list we need to
separate metrics that are defined by the line and
metrics that are constants in a given font. Looking at
the perspective of the line there are a bunch of metrics
associated with a given font and for the line you have
an overall metric.
astearns: To proceed at this level we should ensure that the
linebox has a prototype level. I don't know if for the
first iteration we need more than dominant baseline.
SteveZ: You want to know which baseline is the dominant one.
astearns: That's more important.
ChrisL: Which was was used and how it came across that is more
important.
SteveZ: If you're doing initial caps from non-Latin languages you
need more information than that.
astearns: We need to have, we should start with a minimum set of
typographic measures that makes sense but leaves things
open for extensions. I think baseline grid should be
level 1. I don't think a different leading system is.
jdaggett: What do you mean?
astearns: Roman scripts everywhere outside the web deals with
stacking differently and non-Roman do things differently
on the web. I think that aligning the dominant baseline
should be a requirement but leading is a further future
requirement.
esprehn: This seems reasonable, it seems like we need to get a
bunch of people together in a breakout to build something.
We use to have linebox grid. I think webkit still has it.
I think it's a useful thing to have.
jdaggett: It feels weird to talk about baseline grid as version 1
when it seems like you can't do much in a single line.
esprehn: I don't think we'll know what we can do in version 1
until we try. This is so rough we can't tell. We should
set out with some goals and try.
jdaggett: We need a sketch out model and decide what will be
exposed in version 1 first.
astearns: Line breaking is part of the model. We're trying to spec
that one piece.
Rossen: And before you have linebox you won't have dominant
baseline. We are going to specify this in a logical way so
they're useful once they come up. I'm not looking to
expose alphabetical baseline on something you can't even
get.
jdaggett: It seems like a dumbed down model.
Rossen: Which is probably okay for the people going to use it at
first.
jdaggett: I'm skeptical.
Rossen: Let's be realistic. The people who want to work on our
code bases work on our code bases. We don't want to expose
every single thing. In here we are trying to sketch a
model which is an intersection of all these
implementations but is useful for people that will use the
dumbed down objects as something better than what's out
there today.
Rossen: I think we sympathize with your concerns and the other
implementors have just as much concern because that's work
for us, so I think the overall feedback is we hear you.
jdaggett: I think we really need to think about underlying models
of the processes we're trying to expose before we say we
want to support baseline grids.
TabAtkins: jdaggett doesn't want this to be one of those solely
use case driven designs where we figure out here's the
one use case and we solved that. But we like having
leading use cases that are moderately complex that show
we have some useful things.
astearns: The leading use case is the start.
TabAtkins: Without a leading use case it's very easy to design
something worthless that it could have been very easy
to fix. But once you have that leading use case we can
figure out ways to make everything consistent. Baseline
grids seems to be right about the level of complexity
for version 1.
Florian: But the goal of version 1 is not that.
TabAtkins: Re-implementing flexbox is a leading use case for
version 1. We can get to a well known point that is
useful.
Florian: For CSS we have a well documented, well understood model
for what's going on. I don't think we have the same level
of understanding for the font pipeline and having a high
level overview of that would be helpful.
TabAtkins: This doesn't need to be strictly ordered; this isn't a
waterfall design process, it's back and forth.
heycam: Can I try restating jdaggett's concern?
heycam: What I'm hearing is there's an existing model for how
glyphs have their metrics and if we don't write down what
their model is there's a chance we'll expose things that
aren't consistent with the actual underlying model.
jdaggett: Yeah. That's what I was saying.
SteveZ: For clarification. I agree whatever we produce ought to be
implementable in terms of those underlying primitives, but
the user might not need those and we may present a
simplified model. Is that okay?
jdaggett: No. You're creating an artificial model and that's
something you'll have to support forever.
SteveZ: I was saying that I want to simplify the model that the
user saw and not give him all the details at a lower level.
It has to be consistent.
jdaggett: Describing and exposing the primitives are two separate
things. We have to first define the primitives. To be
able to get this type of information that you want you
need to have information from this specific object. Then
you can talk about how will we present this. A lot of
what I'm hearing is people take stuff associated with a
line and say it's with a font.
Rossen: Is this something that you want to contribute to and
propose that kind of model?
jdaggett: I posted something on the list and dumped it into IRC. I
can flesh it out more.
Rossen: That's useful. By the time you get to a user exposed to
those you may decide it's too much information and we
shouldn't expose all these things.
jdaggett: You have to understand the model to know what to expose.
Florian: I've seen dbaron make a presentation about how a layout
engine works. We need something similar for the font
layout model. Having that is something I would like to
understand. If it's video, slideshow, text, that's
irrelevant.
<Florian> I was referring to this presentation (or its variants):
https://www.youtube.com/watch?v=a2_6bGNZ7bA I'd like to
see something similar for the font level of things
Rossen: It sounds like there needs to be more work done on further
defining the model. Going back to the current topic, is
there anything else we want to discuss or should we take
that after we have more knowledge. I'm looking at ChrisL
and astearns and jdaggett
SteveZ: I think it's ready to go offline.
Rossen: So jdaggett, I think this is going to be all for font and
lineboxes. The next this on the agenda is the deadrange.
Received on Friday, 16 October 2015 23:39:53 UTC