[littlestymaar]

> The GP to your original did set the bar at 70kB

It didn't, here's the comment in question:

> A probe collecting data in space takes <70 kB of memory. I fail to see how this statement should make me feel happy

It makes no mention that an app should be under 70kB. It just note that 100MB is still *enormous* compared to 70kB.

And I maintain that the difference cannot be explained by images and font cache alone.

[ben-schaaf]

> And I maintain that the difference cannot be explained by images and font cache alone.

It can't be explained by images and fonts alone, I agree, but images and fonts alone are still enormous compared to 70kB. On my screen an "e" on this site is 10*11 pixels. Subpixel positioning means we need at least 6 copies of each letter, subpixel antialiasing means we need three channel alpha (3 bytes per pixel), we have variations of bold, italic and bold-italic, 95 printable letters in ascii, that's a low-ball of 750kB for one size of one font. This comment page alone has 4 different sizes, I'd expect a chat app to have a few more.

[littlestymaar]

Well even with your quite conservative calculations [1] you end up with a size that is absolutely reasonable and negligible in a 100MB footprint.

[1]: Realistically, you're never gonna have all 95 characters in all weights for all font size, so the actual number is going to much significantly lower than the theoretical envelope. In practice, there'll be a main (font,size), that will have all glyphs (and it's going to be more than 95 because of the ligatures) in normal weight and no italic, with a subset of the glyphs in the three other modes, most likely not evenly distributed between modes. Then you'll have additional fonts (for UI labels, titles, etc) that are going to have much less represented glyphs and almost no variations of weight or italic if at all. Obviously the font(s) used for titles in going to have a bigger budget relatively to the glyph sample size, because each one is bigger than your baseline "e"