Or things like showing a clock, countdown, whatever. A time that "jumps around" on the screen from one second to the next annoys the hell out of me...
https://v-fonts.com/fonts/extendomatic-variable
gold +1.2%
oil -6.4%
corn +5.2%
everything lines up and looks nice. At the moment, with CSS, there's no way to make that happen, and in normal typefaces the hyphen-minus is too narrow. You can replace the minus signs with a wider dash, but that is semantically wrong and also a pain in the arse.It occurs to me that contextual alternates could make this Just Work. I haven't used any typefaces expensive enough to do that though!
In this case, an alternative to "-", U+002D HYPHEN-MINUS, is "−", U+2212 MINUS SIGN. On Linux, I considered mapping the keypad substract key to it, but instead I configured a xcompose alias.
gold +1.2%
oil −6.4%
corn +5.2% <td align="char" char=".">€ 1.20</td>
https://www.w3.org/TR/html401/struct/tables.html#h-11.3.2HTML 4 was still in this weird in-between time where there were styling attributes in HTML coexisting with the upcoming CSS. Afair no browser ever implemented character alignment and in Google’s HTML it is only written up as obsolete:
https://html.spec.whatwg.org/multipage/obsolete.html#dom-tab...
Styling in general is of course a CSS thing – but thinking about it arranging alignment in multiple interdependent elements is a problem which not just need a property but a layout algorithm which browsers then need to implement. So we still don’t have nice things.
> It occurs to me that contextual alternates could make this Just Work.
The replacement mechanism in OpenType fonts is surprisingly useful. I remember Apple’s San Francisco font switches between different variants of the colon if it follows text characters ("my proposal: nuke it from the orbit") or if it exists between numbers as in a time ("23:52"); in the latter it is more centered.
Generally, numbers were right-aligned in cells, so the % at the end was consistent (when present) and the plus/minus before the numbers didn't make a difference because of the alignment. But labels on the left like in some P&L or Cash Flow statement were always annoying
I've never thought about it, but that is somewhat annoying that the math symbols aren't a consistent width with each other.
By default, I always use old-style numerals, because they are much easier to read, especially for big numbers, for the same reason why the lowercase letters are easier to read, by having ascenders and descenders that break the uniformity of the characters.
I use lining numerals only in the same places where I would use uppercase letters, e.g. in titles or when a sentence begins with a number.
A font of antiquated faſhion doth boaſt moſt excellent and ſubſtantious qualities, yet prithee, what of olde ſtyle figures doſt thou deem hath benefit that I, in mine own diſcretion, might chooſeth?
In particular the `ttx` tool is great for digging into the innards of font files.
e.g. Wakamai Fondue lists 11 features for Googles version of Inter (some essential ones plus fractions, tabular numbers, numerators, denominators and contextual alts), while the full fat version of Inter has a whopping 44 features (too many to list, see https://rsms.me/inter/).
I wish all the effort the big four wasted fighting for emoji supremacy would have been used to normalize a decent set of full unicode fonts once and for all.
macOS used to ship with a beautiful Hebrew typeface that was like the open-source font Shofar, but it seems to have been removed. I do not see similar Hebrew letters in one of the remaining typefaces. I imagine that it is not easy to give a typeface a consistent feel, in all Latin and non-Latin character sets, to the fluent readers of those languages.
If anyone, then distro creators and maintainers will have to make that step. Google surely enjoys getting so much information due to hapless users loading Googlefonts on websites.
I am (clearly) clueless here, but isn't that what Noto's supposed to be?
> The Google Fonts API currently does not support requesting the inclusion of optional (also known as discretionary, or opt-in) OpenType Features, such as Stylistic Sets (salt) or Small Caps (smcp, c2sc). Instead the glyphs contained in these features may be published as a separate family… https://googlefonts.github.io/gf-guide/requirements.html#ope...
Mine is:
.mtki {
font-family: 'IosevkaNFM-ExtraLightItalic', monospace !important;
font-style: italic !important;
color: #757575 !important;
}
.comment {
font-family: 'IosevkaNFM-ExtraLightItalic', monospace !important;
font-style: italic !important;
color: #757575 !important;
}
.comment:not(.punctuation) {
font-family: 'IosevkaNFM-ExtraLightItalic', monospace !important;
font-style: italic !important;
color: #757575 !important;
}
Which looks like the last picture in this comment: https://github.com/microsoft/vscode/issues/36512#issuecommen...Just be prepared to experiment a lot, VSCode's (Electron's?) font handling is buggy.
Why are font features so difficult to support correctly?
Why are font features so difficult to support correctly?
Because the standards are mostly a result of slapping the name "OpenType" on existing behavior. There's maybe three or four ways to encode any given piece of information. The standards are a mess.You can identify a font as italic in four different places with varying semantics. Off the top of my head, three different places to mark a font as bold (and this may not jive with the weight). Three different ways to specify vector glyphs (five if you include 'COLR' and SVG). Raster glyphs? Do you want PNG, JPEG, TIFF, or raw bytes? Should the raw data be bit or byte aligned?
The result of that complexity is that fonts often have all sorts of conflicting information. Depending on what behavior you're referring to specifically I'd be that the fonts themselves may be to blame. TrueType style glyphs specifically put a lot of burden for getting the hinting right on the font designer. CFF/CFF2 doesn't.
Noto went full Google. Noto Display was abandoned a few years ago. In their own words it's not intended to be what most folks would consider a display font so there's no good replacement. The metadata in last release is all kinds of fucked up.
Names are a hilarious shit show, what constitutes an appropriate name varies from font to font leaving app makers to come up with their own magic and leaving font selection a huge mess. Plus names can be encoded in any number of encodings. Apple still has MacRoman encoded strings in some of their fonts. Is Arial Black the black weight of Arial or a whole new font family?
It is not.
From their update in february[1] this year it seems like it is basically complete but personal things got in the way and maybe they struggle to set up the systems for custom builds, ecommerce, etc. to ship it. People are constantly asking for the release, so I think it will eventually arrive, but good things often take longer than expected. :)
I am actually curious about this though, the Berkeley Mono font I found with a search does look quite nice. What's the deal with v2?
I think he got this style from classic reference books like Elements of Style. It does look super sharp.
I've bought two fonts from him and his font license is easily the most permissive of any paid professional font I've seen: no restrictions on the number of page views or anything, unlike most other pro fonts. Are his fonts open source? No. Are there good open source fonts? Of course. But are his fonts beautiful? You bet. I've got Valkyrie and Concourse. Concourse is particularly flexible when it comes to contextual alternatives and such.
Processing the font itself also is at least 500ms to a second depending on the device type.
We keep the total requests under 25, which cannot be done after multiple 3rd party fonts are added.
Additionally, some fonts can introduce CLS (content layout shift) after the font is loaded. Especially H tags because they shift a lot. CLS = your SEO is dead.
For speed purposes, especially mobile, using a 3rd party font is SEO suicide.
The sites we build for our clients are below 1.2 second mobile and 0.2 second desktop load time which gives these sites an enormous SEO advantage. These load times are complete loads, not initial draws or TTFBs. (results are provided by Google page speed insights - https://pagespeed.web.dev/) These load times change when we use the client's own fonts or the ones they pick from Google fonts. We have this discussion almost every time we onboard a new client.
https://web.archive.org/web/20091223045132/http://partners.a...
Though to check the features or variable ranges of an OpenType file, you can use something like fontdrop.info.
Or ugly ones I want some high-quality Comic Sans font.
That live demo on the page is solid by the way.
this brings me bad memories from the time websites were done by "desktop publishing" designers and html was crafted "pixel perfect" (with tables)
thankfully I can easily be a curmudgeon and just set all sites to use my favorite fixed width font and disable the designers choice with one checkbox on firefox.
Hard disagree.
> pixel perfect
I prefer that era of wob design to now.