Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Roel Nieskens

About

Username
Roel Nieskens
Joined
Visits
615
Last Active
Roles
Member
Points
80
Posts
72
  • Re: Units per em

    Regarding file size, I suppose that once you crossed the line where most point are more than 256 units apart, it doesn't really matter if you use a UPM of 2048, 4096, 8192, etc. The savings come from being able to use a single byte to store the point's coordinates, as opposed to a signed short, which is two bytes. A font with a 1024 UPM might have 50% of its coordinates stored as a short — say 25.000 points, which equals 50.000 bytes — but when "scaled" to 256 UPM they might all fit in a byte. That saved you 25Kb.

    There's a silly experiment I did with a famous icon font that reduces file size in exactly that manner.

    Oh, and get your rotten tomatoes ready: I think most webfonts would work perfectly well for screen with a low UPM like 256. The least that could be done is scaling the UPM as far down as possible by using the greatest common divisor for all coordinates.
  • Re: Is Anyone Designing Colour Fonts?

    Changing the palette for both vector color font formats (COLR and SVG) would be done by overwriting colors defined in the CPAL table. The proposed ways, either by assigning colors to CSS variables or using a custom CSS4 syntax, will be pretty straightforward for web developers. It'd be a simple key/value thing, like --color0: hotpink.

    It's probably not a big surprise that none of this works in browsers yet. SVG doesn't even take its colors from the CPAL table yet — it only uses the ones hardcoded in the font or the regular text color defined in CSS (e.g. color: hotpink). The latter could be useful for both Gluk's examples: the fill could always be white but the outline and shadow could take its color from CSS in the first font, and if the gradient can always be black and the fill color taken from CSS in the second font.

    (On a side note, CPAL only takes RGBA values so for print something custom needs to be made by the design software to assign colors, I suppose.)
  • Re: OpenType SVG color fonts coming to Windows 10 :)

    I haven't experimented with CPAL + SVG myself yet.
    In have experimented by now, and the conclusion is that neither Firefox nor Edge take colors from the CPAL table for an OT SVG font. (Nor does Photoshop, by the way.)
  • Re: WOFF support in different browsers

    Unfortunately we can never be sure. It's very well possible to have an old Android 2.2 phone connected to a hyperfast 54 Mbps wifi network, or the latest high-end Macbook to a super unstable GPRS network. Web developers have been dreaming of a media query or API that would just answer the simple question "are we on a slow or fast connection?"

    So we have to make assumptions. Serving heavily optimised fonts to modern browsers who can handle them, and no fonts to obsolete browsers, is a very good start.

    Dealing with FOUT and FOIT by having a good @font-face loading strategy is a much larger problem to be solved and not many web developers are doing that. They still believe including legacy formats in the old "bulletproof @font-face syntax" (published in 2009, when webfonts were still in their infancy!) is enough for an accessible, usable site. I think that's where the request of EOT, OTF/TTF and SVG versions comes from — because of outdated info, not because of a thorough research of the target audience and their needs.
  • Re: WOFF support in different browsers

    If you click the "Show all" button it'll show you older versions of browsers, and you'll see for instance that IE8 and older Android don't support WOFF. It'd be up to you to decide if you want to offer no custom fonts to those visitors, of offer EOT (for old IE) or TTF/OTF (for old Android).