I quite disliked the Latin fonts at first sight, but I like the Arabic ones just as much as I dislike the former. An occasion to contemplate that what may be not that great in the context of Western culture may be still a great thing and useful for another one.
The Arabic scripts are breathtaking but I had some difficulty discerning the Reem Kufi examples. It might be just me, but I've never seen the right+left connected ع drawn that way in Kufi scripts. It seems both alien and a poor match for the rest of the characters in the Reem Kufi fonts - I first thought it was a ligature error!
Reem Kufi designer here, that is the original form of ع in Arabic and the only form used in manuscript Kufi. Kufi-inspired typefaces often use the more familiar form from later calligraphic styles. Reem Kufi has an alternate form as well, but it is not the default.
Next up is sound and interactivity in emojis, including a custom emoji scripting language and emoji platform, and then the inevitable "DOOM ported to emoji" projects.
And of course, web browsers and text rendering become increasingly more complex and expensive to build/maintain because Google single-handedly decided it.
After seeing the beautiful new Arabic fonts in this post, I can't go back to being happy with just simple text for the web. We're still so far from the beauty of calligraphy and even old metal typefaces, with their ligatures and all. We have to dream bigger.
While the parenrt is an ironic comment, color fonts were a staple of computer graphics design during 90s and palettized graphics like VGA 320x200x256 mode. The art was lost with TrueType and now it is coming back. People who have used Deluxe Paint Animator remember this.
Did you read the post? This is a new spec called COLRv1 which adds a bunch of complex rendering features to do what is effectively word art.
Why does this need to be a new spec? Nobody is going to use it for body text. If someone wants those ugly 3D titles, they could use SVG or Canvas.
One of the examples in the OP was colored arabic text for education. That’s an extremely narrow use case which could be entirely supported with custom rendering via SVG, Canvas, WebGL, etc.
This isn’t the end of the world or anything, but it’s annoying and frustrating to see as someone who thinks there should be more browsers and operating systems than the ones Google makes.
They could but then it would be less accessible for screen readers or bots that want to scrape text from a web page for indexing or anything else. Your user agent can also determine if rendering those "ugly 3D titles" is the right thing to do or not, so you could have a plugin that stops them from being rendered.
> there should be more browsers and operating systems than the ones Google makes
They in fact do not work at all in Firefox (or any other browser besides Chrome/Edge). If you go to fonts.google.com, they work because that page uses a custom renderer for them.
This is just an extension of the ISO Open Font Format (Opentype). I think it's great because it's so far the only standard way to specify color needed to render emojis.
There is also a Hangul adaptation of Gilbert called Gilbeot [1]. It also has an interesting feature that censors words that discriminate LGBT people (akin to Sans Bullshit Sans). I do have a feeling that they are clearly decorative and yet still being overused for non-heading text, maybe this is a major problem with many color fonts.
In fact, its design choice is questionable even as a title font. Normally the text color will be chosen so that it has enough contrast compared to the background. With color fonts you can't always change the text color, but you can still change the background. Gilbert however contains all hues in a single glyph, so some part of each glyph is always going to be hard to distinguish from the background without much care.
That is a beautiful font. Is it distributed in the same format as what's discussed in the material.io post (COLRv1)? It's still a good example of what's possible; I'm just curious.
Design is highly contextual, so I think it'll depend a lot on how they're used. These fonts seem a lot more polished than what you would find in old-school clip art packs. I can imagine some interesting use cases for these.
And even if these fonts don't hit, people will make more!
To me it's is not necessarily just the colors, but that with the Arabic script the new features are applied in a more tasteful, subtle way. Whereas the latin examples seem more like showing off what you could do, but probably shouldn't.
I've posted this link before (as a ShowHN) - this is my attempt to "replicate" color fonts using my JS canvas library. Getting the effects to be both responsive and amenable to user accessibility choices, while also including ways for developers to adapt the effects via CSS and/or HTML data- attributes ... it's frustrating work. But at least they look pretty. https://scrawl-v8.rikweb.org.uk/demo/snippets-006.html
That sounds like the entire internet is unlawful. How would a German access any content outside of Germany without going through the tens-hundreds of intermediate routers? There's nothing stopping those routers from logging IPs going through them.
I'm not saying that I agree with the current situation, but as of now it's risk for the developer to use Google Fonts.
To answer your question more specifically, I guess you could argue that it's a layer problem. Lower layers can't prevent "leaking" your ip with the current state of the internet, upper layers can and should.
Is that actually the test? That still sounds like it would make every third-party CDN (Cloudflare, Akami, etc) illegal - a CDN isn’t “necessary” and logs IP addresses all over the place. I can’t help but feel that the situation is much more complicated and nuanced than the original comment in this thread is making it sound.
So far, the courts have only selectively enforced it against Google, but any website which is controlled by an American entity, hosted by an American entity, or which embeds content controlled by or hosted in the US is de jure illegal under GDPR because it means an American court could theoretically get a warrant for EU citizens' IP addresses.
Shared CDNs (Google Fonts, jsdelivr, etc.) provide absolutely no advantage in modern browsers due to privacy concerns. The developer should be self-hosting the font instead of using Google's servers irrespective of German law.
The person claiming Google Fonts would be "illegal" in Germany is misinformed.
It is simply considered best practice to self-host Google Fonts now and you are absolutely safe doing so.
The basics of privacy law is basically don't violate the privacy of your users for no good reason. There is no technical justification to use a Google's third party service for fonts, especially as that potentially allows Google to track users. (You could still use Google's hosting if you were to get prior user consent though. Just have a fallback font. That wouldn't be worth it though.)
So yes, you can use third party services and CDNs on your website but it needs to be either technically necessary or you need for user consent beforehand.
To further contextualise the judgement: This was a trial before a medium level district court (Landgericht). So there has not yet been any landmark court decisions on this specific issue in Germany.
Cross-site caching doesn’t exist in any modern browser (IIRC each site gets it’s own separate cache) because it enables all sorts of tracking and leaks browsing history.
Do you have a source that backs up your interpretation of the situation? IP addresses are "leaked" (I think that's a really shitty term in this context tbh) to every single thing you communicate with, or via, on the Internet, and most of those things are operated by third parties.
If "necessary" or "unavoidable" is the test, then it gets really murky — is it really necessary for your ISP to buy wholesale IP transit from another ISP when they could build out their own infra instead? It's entirely avoidable for them to peer at IXes for more economical / efficient routing — and those IXes have switches and routers operated by third parties which can see your traffic — so is it illegal for them to offload your traffic there as well?
The issue isn't the existence of intermediary routing, it's the export of data outside the EU by an EU site.
A German resident that wants to access Google or any other US site is fine. The packets are allowed to exit the EU because that's what they asked for.
Using Google Fonts means that your EU users have to access Google, a US company, in order to read your site. Most browsers are configured to do this automatically and opting-out of that would be time-consuming and break the whole web. And using Google Fonts gives Google the unprecedented ability to snoop on third-party sites. Yes, they have promised not to do this, but their host government has also promised to break Google's promise for them.
Taking that same logic and applying it to intermediary routing, the only time in which you'd have a GDPR export case is if you tried to access an EU website and your traffic was rerouted into the US or China. Which actually happens way more often than it should.
Hosting a subresource of another website gives you `Referer`, at the very least. And the set of fonts requested is fingerprintable even if your browser didn't send that header. You can also fingerprint the browser further to tie that information into your ad profiles.
Google promises explicitly to not do this, and I believe them. However, they can still be compelled by law enforcement to break their own promise, and that's what the EU is reasonably angry about.
Irrespective of cross-origin caching, `Referer` should have been neutered long ago to always specify the base URL of the site hosting the resource (or killed entirely).
Also Browsers should send exactly the same headers when in image and page contexts - if I want to view an image it means I want to view an image on its own and there should be nothing the site can do about it.
If we lived in an alternate universe where the same-origin policy applied to all subresources from the get-go, then I would agree with you. But we don't. And in this universe - the one where every website can include subresources from any other by default - you absolutely need an opt-out to say, "no, I really don't want to host this one image for the entire WWW, just my own domain". Referer is that opt-out.
User privacy should always override website concerns - we are talking about what user agents should do here. If there is sufficient reason to believe that users would benefit from restrictions on cross origin embedding then we can always define a new header like was done for X-Frame-Options (which of course user agents are free to ignore if the user wants that).
For the longest time I thought that was not allowed, and I'm more worried about copyright violations (civil suit) than GDPR violations (criminal law, but I can't imagine a persecutor takes the time to look at my tiny websites. Here there is a saying "where there is no plaintiff there is no judge").
Yeah but that is really debateable. What most people do is just put really broad terms in their data protection declaration. I think there have been a couple "Abmahnungen" but this was never really tested in court, right?
Personally, I think hotlinking should not be considered leaking of PII. Setting a link should not imply endorsement, and embedding an image or an iframe should not create a derived work. The website just gives instructions to the user's browser. I could change the font myself or open another window with the embedded image next to the website, it is merely a convenience. But lawmakers try to put everything in the mold of yesterdays technologies, which is why we cannot have nice things.
Now, how to deal with the fact that Google does get your IP and/or can identify you with cookies? Just ban profiling. It's not so hard.
What's up with svg fonts? I suppose this is a binary format, and presumably smaller and faster to parse than compressed SVG fonts, but I admit I'm a bit surprised that this isn't an improvement to an existing SVG font ecosystem and is instead it's own thing.
It seems that if this was legitimately useful (instead of just one more thing competitors are obligated to spend money on implementing) we'd have seen SVG fonts used for it already.
the Mozilla position on COLRv1 is "Provides comparable design capabilities to OpenType-SVG, but in a more compact and lightweight form that integrates better into font rendering pipelines. Has the potential to supersede OpenType-SVG fonts in web use."
So this seems like a good thing overall. Note that Firefox doesn't support it at this time.
"OpenType-SVG is a font format in which an OpenType font has all or just some of its glyphs represented as SVG (scalable vector graphics) artwork. This allows the display of multiple colors and gradients in a single glyph. Because of these features, we also refer to OpenType-SVG fonts as “color fonts”.
OpenType-SVG fonts allow text to be shown with these graphic qualities, while still allowing it to be edited, indexed, or searched. They may also contain OpenType features that allow glyph substitution or alternate glyph styles."
Nobody wants to be responsible for introducing the security/performance nightmare that is SVG fonts into their codebase. SVG is too big and too unwieldy and does too much to make a good performant font rendering impl. Crucially, OpenType fonts already have their own custom vector format that authoring tools and renderers are used to working with, so this is a form of colored font support that builds on existing font principles instead of stapling an entire SVG renderer inside of it.
I'd say there are expectations, rather than rules. If you know your audience is likely to care about these sort of things then it's indeed a good idea to correct them, and it's usually best to be conservative in formal writing. But that doesn't really mean there are "rules" which cover any and all usage of the English language.
Joining words to one compound word is pretty much the example of language evolution.
I'm surprised at how fun this article is, and how gorgeous fonts can look. And, it makes me, at least for a few seconds, want to switch back to Chrome from Firefox.
"So this is pretty cool, but it turns out that the contextual substitution lookup type is really powerful. This is because the table that it references can be itself, which means it can be recursive."
[…]
"So thats a pretty powerful virtual machine. I think the above is sufficient to prove Turing complete-ness."
Postscript fonts? Fully programmable font glyphs in the 80's. Little used, but very fun. I recall a typewriter font that would vary the glyphs position, weight and edges a bit to simulate coming from a manual typewriter.
One could, if so inclined, build a complete COLRv1 font parser in PostScript.
Hard to argue that having this functionality in the type itself is better than having to do so in images. It has big advantages over SVGs, as well. I can copy styled text, for example.
So it's not like this would empower people to do ugly web design that they couldn't already do.
Per your point, I prefer CSS animations to having a blink tag, and people have managed to avoid using those too much the last 20 years.
On a vaguely related note, I recall that classic Macintosh, sometime in the 1990s, had (possibly unofficial and/or hackish) operating system support for colour bitmap fonts. But I can't find any reference to this on Wikipedia or Google searches.
I wonder if anyone else remembers this; perhaps there's an opportunity to document/archive something about typography which might otherwise get forgotten.
Even there, colorfont support was not part of the OS until 2.0 (or maybe 2.1, can’t remember). In the 1.x days you had to load the ColorFont wedge before you could use them
Unfortunately there is no support for COLRv1 fonts on Safari (desktop or mobile).[0] There is support for COLRv0, so hopefully this will come to Safari/Webkit at some point.[1]
Unfortunately there is no support for COLRv1 fonts on Safari (desktop or mobile).
The expectation that every user get's exactly the same experience regardless of what browser they're using has held the development of great user experiences on the web back for about two decades now. There's no reason why you shouldn't deliver a better experience for some users if their browser is more capable.
Design a working minimal app. It'll probably be close to a plain HTML and CSS site that's rendered on a server. Then add in things that make it nicer to use while checking that the browser supports that feature so you don't break anything if it doesn't. Build up to a really nice experience. Progressively enhance the usr experience. This is literally how websites were built 20 years ago, but then developers got lazy and only wrote apps for the lowest common denominator, which meant any new features in browsers rarely good used, and at the same time slightly unusual browsers like Lynx got abandoned entirely. It really annoys me.
The beauty of what I suggested is that it stops anyone forcing a new standard for something. If a browser vendor creates a new feature then it's up to developers to support it. If they choose not to that's fine. If developers were happy to pick and choose which features to support, and were willing to put in the effort to support different approaches, then Google wouldn't have any power to force change across the whole web. They'd just make something that only works in Chrome, and developers would choose to use it or not.
Exactly, at this point this should be a proposal for standardization with any implementations in browsers gatet behind flags, not something that google is shipping to end users on a whim.
> With the ability to add variable axes too, the possibilities for customizing a COLRv1 font are literally infinite!
Is it literally infinite, or is it a very large number? As far as I understand it, variable fonts are defined by ranges of finite length, and all CSS color spaces I know of are finite too. I'm being roughly a little pedantic, but mostly just wondering why they wrote it this way, and if I'm missing something. Big fans of Rob Lowe maybe?
This makes me feel old. I'm glad that the option is available for people that want and enjoy this kind of design, but for my part I'll probably disable this feature and continue to block custom fonts.
Still, it's interesting to see that there's still room for innovation in the font space, even if I'm not in the target demographic.
An interesting idea for a color font is a terminal font automatically supporting terminal colors (by the terminal escape characters). Sometimes you just pipe your output somewhere which isn't a real terminal, and having color support would be nice if all you needed to do was change fonts.
There are a few nice color fonts I have used in the past. One of my favorite is Raleway Color Semibold by Vidhunnan Murugan: https://typewithraleway.firebaseapp.com
Does anyone here know how to connect with the folks working on this at Google (or elsewhere)? My work focuses on the intersection of color and text, so I would be interested to know who else is thinking about these topics. (Contact is in profile.)
Colors (and gradients) per-stroke rather than per-glyph. (Coloring all of an "A" versus the three or more strokes that make an "A", for instance.)
The most obvious examples are emoji which may need hundreds of strokes in many colors to be properly colored as we see them in most places (that aren't HN). Many emoji were rendered as bitmap images on many platforms to be able to get the colors correct prior to font support for color fonts.
They're multi-color. For example, you could have a font with a 3D-effect, its shadow and lighting could be different from the actual block. Look at the first image of the post to see what I mean, the big "Color Fonts" text.
If you did that, what's the advantage? Instead of loading an image file, it loads a font file, which seems a lot like an image file when used that way.
Text is easier for screen readers to read, easier for search engines to parse, easier for control-F to find, easier to copy and paste. Text is a better format for text, and this allows for companies to embed their logotype design as text with a specific font as opposed to incentivizing them to use an image.
Screenreader: image "alt" tag should be equivalent, shouldn't it? Arguably better, because the intent of it is more widely understood.
Search engine parsing: image "alt" tag should be equivalent again.
Copy-Paste: Arguably not better with a font. A raster image will be the same regardless of where you copy-paste it. A logo implemented with a font will only look the same when copy-pasting between applications that are aware of that font. If every company creates their own font-logo, it will just break copy-paste everywhere except their domain.
WCAG specifically asks designers to avoid text in images because they're not equivalent.
If I embed an image in some text, like `foo <img alt="bar"> baz` then I doubt any search engine can find this for the search query `"foo bar baz"`.
I would like to copy and past text-like things as text, without having to copy and paste images. When I want to copy and paste text, I rarely care about matching exact styles. In cases where I want the exact style, I can just screenshot.
I'm painting the progression of where this is going. I'm not trying to describe this effort. I'm legit worried that Unicode will eventually fail, and we'll all just be sending streaming SVG to each other.
For some reason Google Fonts rendering is just awful on my (Windows) machines. I tried to investigate, but got nowhere. They seem extremely jaggy and with uneven strokes, like they were only tested on 4K displays. I don't have the budget to go beyond 1080 at the moment.
This has made me extremely averse to them, to the point where I simply avoid sites using them.
The maximum size at which 1080p (2K) works is 23".
The maximum size at which 1440p works is 30".
The maximum size at which 2160p (4K) works is 40".
If you’re using a larger size than the ones given above for a given resolution, you will have less than 96dpi, leading to fonts that break or become too thin, and icons that will be less recognizable.
________________________
P.S.: The same can be said for colors. While any CRT in the 90s but even early LCDs like the Fujitsu SIEMENS P17-2 from 2004 (now 30€ on eBay) gets 100% sRGB, full 8-bit colors at exactly 96dpi, many gaming monitors don’t even manage this today. There are still gaming monitors, 1080p at 30" or even 32" using 6-bit panels with FRC that barely hit 70% sRGB on sale today.
Can you send me some screenshots? Very possibly you have some ClearType parameters set wrong on your system. We absolutely do test on 1080p (though I admit my work machines are all retina/4k at this point).
The Arabic scripts look amazing! Gradient support is bigger than color support imo