by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Peter Müller
@Munter
Looks like Google fonts made a change so the first option you get when you selected some fonts is now to download them!
No CSS snippet for it though
And I also only got the ttf
Andreas Lind
@papandreou
Interesting!
Peter Müller
@Munter
I still think the script I wrote to download is better. I can specify the formats, and it can also subset in the same step
Andreas Lind
@papandreou
Bram the prophet: https://twitter.com/bram_stein/status/1179410446534823942
Peter Müller
@Munter
I added Munter/subfont#101 and updated Munter/subfont#31
Andreas Lind
@papandreou
Nice!
Shouldn't be insanely hard. I wonder if we should keep downloading their "vanilla" CSS with one big TTF and then convert to woff/woff2 ourselves and upgrade with unicode-range etc.
It seems like that would be the easiest, as the unsplit ttf is closer to "the source".
But we'll probably need a different strategy for that css2 api
Peter Müller
@Munter
https://github.com/Munter/subfont/blob/master/lib/downloadGoogleFonts.js already directly downloads the right formats, also of the original fonts
Andreas Lind
@papandreou
Right! That's just so specific to Google Web Fonts
But maybe we'll do ourselves a favor if we make a specific handler for each service
Peter Müller
@Munter
Until we have harfbuzz we'll need to retain google fonts subsetting
so I imagine that at some step we know what texts we need and then we call this function twice; one for the subset, one for the originals. From then on we can forget the knowledge of where the fonts came from
Andreas Lind
@papandreou
Yeah, that's a good point. If it's only a concern at one specific point in the process, it'll probably be fine.
Unfortunately not much is happening on the harfbuzz side, at least not when it comes to those subsetting features we need. I checked a few weeks ago
Peter Müller
@Munter
I'll cut a subfont release with all your additions. I guess we're still within a semver patch
Andreas Lind
@papandreou
assetgraph-sprite doesn't tell the canvas instance which type the image has, it just hands in the raw Buffer. So it must be an image type not supported by cairo rather than a valid and supported image mislabeled as a png.
Andreas Lind
@papandreou
Hmm, the node.js 10 build of subfont has been broken for a few days, since https://travis-ci.org/github/Munter/subfont/jobs/703442365
Did you look into that, @Munter?
Peter Müller
@Munter
@papandreou I'm trying to clear the cache and restart that job now to see if the cache became corrupt
Andreas Lind
@papandreou
Great!
Peter Müller
@Munter
That made https://travis-ci.org/github/Munter/subfont/jobs/703442365 go green. A few ugly messages about us not dealing properly with promises, but otherwise it looks good
Andreas Lind
@papandreou
Thanks for sorting it :+1:
No idea where those promise warnings come from
Peter Müller
@Munter
Probably easier to see when not on the dot reporter
Andreas Lind
@papandreou
Ah, I see it, can fix real quick
That helped: https://travis-ci.org/github/Munter/subfont/jobs/704912491
Andreas Lind
@papandreou
@Munter, do you remember why we include unicode-range: ... in the @font-face declarations of the __subset versions of the fonts?
Andreas Lind
@papandreou
Now that we have the unicode-range stuff for fallback fonts in place, I'm trying to make Bram's fontfaceobserver.com website work with subfont. I'm hitting a case where having unicode-range: ... for the subsets is causing Chrome to download the fallback fonts as soon as it has loaded the fallback CSS.
I've found a fix for it -- turns out it happens when the unicode-range for the __subset fonts does not contain U+20 (space). If I add that to the unicode-range property, Chrome doesn't download the fallback fonts (whether or not the subset actually includes a space!). So we can fix it by always adding U+20.
However, just removing the unicode-range property also fixes it, so maybe we can just get rid of it altogether?
Peter Müller
@Munter
@papandreou As I recall we put the range in the subset declaration specifically to make the fallback download trigger asap if the browser knew it needed a glyph that wasn't covered. Even before the font would finish downloading
It sounds like a bug if our range declaration doesn't contain a space. It's definitely one of the characters I would expect represented in almost any subset we create from natural content
Andreas Lind
@papandreou
Ah, that makes sense. I’ll just go for fixing it without pulling out unicode-range, then. The case I tried seemed legit — some of the subsets just didn’t need to contain a space, but apparently Chrome really felt it was needed 😅
Peter Müller
@Munter
That's a bit surprising. I wonder if we should add the space in the unicode range or always as part of the subset as well
Andreas Lind
@papandreou
Let’s put it in the subset so we don’t lie, haha. It won’t cost many bytes.
Peter Müller
@Munter
Yeah, I also assume it's one of the cheaper glyphs :P
Andreas Lind
@papandreou
Sometimes font designers get creative, but generally no 😂
s/ no/ yes/
Argh
Stupid app
Andreas Lind
@papandreou
I’m sorry about the number of issues we’ve had with the whole “unused variants” fix I made. When I get some time I’ll try to use the puppeteer-based setup that we added for the image-based tests to make sure that the fallback fonts aren’t downloaded in various scenarios.
Peter Müller
@Munter
It's just super complex. Also to even think of the scenarios for tests
Andreas Lind
@papandreou
Yeah, agreed. So I think leveraging a headless browser even more is the way to go — that should give a lot more assurances about the actual behavior.
The reference image tests already error out if one of the fallback fonts is downloaded.
Peter Müller
@Munter
Damn, you'e been busy. Are all 3 PR's against subfont ready to go?
Oh, some were for hashfiles :)
Andreas Lind
@papandreou
Yeah, it’s all ready. I’m at a concert, but will try to get the space thing fixed later 🤗