3 ms·

He forgot one: inline the font data (evil cackle). This made sense for me in conjunction with subsetting for a stopwatch app that only needs 10 digits and a co

He forgot one: inline the font data (evil cackle). This made sense for me in conjunction with subsetting for a stopwatch app that only needs 10 digits and a colon. I submit it's not so bad if you inline it with the rest of your styling, at least that's cacheable separate from the content.

lelandfe 5y ago
I’ve been meaning to build a PoC where you subset to the glyphs shown above the fold, inline, and then download the full font face at a low priority.
- pshc 5y ago
  If fully automated, this would be quite slick.
- amelius 5y ago
  You could inline a dummy font containing only the font metrics. Then replace it by the real font after the initial render.
  - necovek 5y ago
    I was going to suggest that too. Separate metrics files have already been done too (both with TeX in TFM files and Adobe/PostScript fonts in AFM/PFM files), so you wouldn't even have to invent a new file format. Or you could simply use a regular font with no glyph curve data. I am a bit disappointed this is not covered in the original post, and that no effort is being put in W3C to make that easy and viable.
    - amelius 5y ago
      > I am a bit disappointed this is not covered in the original post, and that no effort is being put in W3C to make that easy and viable. Yes. What would be interesting is if you could use an a-priori available font (system font), and combine it with a website-provided font metrics file. That way, you can render visible text immediately, and then later render the correct font without layout change.
      - necovek 5y ago
        Yeah, but strictly as a solution to shifting layout, having metrics asap and actual text display later — when the glyph data is downloaded — is the most obvious solution. Rendering a similar system font (by metrics comparison, ideally) in its place is indeed a great improvement on this, but mostly for the render-as-soon-as-possible problem. I'd treat it as a separate problem simply because it can be on the user agent to decide to do it and how, and even without it, a bunch of web apps would start benefitting right away (those which have most of their actual text off screen but which might block rendering other parts of the page).
  - lelandfe 5y ago
    That also sounds interesting! My goal is to have the characters visible on the first render, whereas that sounds like the glyphs would be invisible – albeit accurately sized, and therefore preventing layout shifts. Correct me if I'm wrong :)

lelandfe 5y ago

I’ve been meaning to build a PoC where you subset to the glyphs shown above the fold, inline, and then download the full font face at a low priority.

pshc 5y ago
If fully automated, this would be quite slick.
amelius 5y ago
You could inline a dummy font containing only the font metrics. Then replace it by the real font after the initial render.
- necovek 5y ago
  I was going to suggest that too. Separate metrics files have already been done too (both with TeX in TFM files and Adobe/PostScript fonts in AFM/PFM files), so you wouldn't even have to invent a new file format. Or you could simply use a regular font with no glyph curve data. I am a bit disappointed this is not covered in the original post, and that no effort is being put in W3C to make that easy and viable.
  - amelius 5y ago
    > I am a bit disappointed this is not covered in the original post, and that no effort is being put in W3C to make that easy and viable. Yes. What would be interesting is if you could use an a-priori available font (system font), and combine it with a website-provided font metrics file. That way, you can render visible text immediately, and then later render the correct font without layout change.
    - necovek 5y ago
      Yeah, but strictly as a solution to shifting layout, having metrics asap and actual text display later — when the glyph data is downloaded — is the most obvious solution. Rendering a similar system font (by metrics comparison, ideally) in its place is indeed a great improvement on this, but mostly for the render-as-soon-as-possible problem. I'd treat it as a separate problem simply because it can be on the user agent to decide to do it and how, and even without it, a bunch of web apps would start benefitting right away (those which have most of their actual text off screen but which might block rendering other parts of the page).
- lelandfe 5y ago
  That also sounds interesting! My goal is to have the characters visible on the first render, whereas that sounds like the glyphs would be invisible – albeit accurately sized, and therefore preventing layout shifts. Correct me if I'm wrong :)