W3C home > Mailing lists > Public > public-houdini@w3.org > October 2015

Minutes Paris F2F 2015-08-25 Part IV: Font Metrics, Lineboxes, and Their Interaction, Custom Layouts

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 16 Oct 2015 19:38:55 -0400
Message-ID: <CADhPm3sSuo9bvm_8z7MkRQDTWJ+aX-vWH+KbRW7a++Nt=krhAQ@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Friday, 16 October 2015 23:39:53 UTC