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.
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.
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.
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.
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.
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
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!
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
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.
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).
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.
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.
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.
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.
"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."
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.
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 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.
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.
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.
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
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.
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.
"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.
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.
178 comments
[ 2.9 ms ] story [ 228 ms ] threadCouldn't the developer download and host the font locally instead of calling back to Google's servers to load the font?
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.
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.
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?
https://www.golem.de/news/landgericht-muenchen-einbindung-vo...
https://t3n.de/news/google-fonts-illegal-urteil-dsgvo-144769...
https://www.derstandard.de/story/2000138472819/datenschutzan...
All these sources lead back to this verdict:
https://rewis.io/urteile/urteil/lhm-20-01-2022-3-o-1749320/
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.
What 'snooping' is happening during a CSS import?
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.
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.
I have don't so for multiple bigger customers, the law departments were fine with that.
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.
https://rewis.io/urteile/urteil/lhm-20-01-2022-3-o-1749320/
Therefor selfhosting a Google Font is the way if you still want to use them.
And even if these fonts don't hit, people will make more!
I wonder if anyone else remembers this; perhaps there's an opportunity to document/archive something about typography which might otherwise get forgotten.
This has made me extremely averse to them, to the point where I simply avoid sites using them.
And now they add color...
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.
And of course, web browsers and text rendering become increasingly more complex and expensive to build/maintain because Google single-handedly decided it.
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
These fonts work fine in Firefox.
Screen readers can read SVG, and ARIA exists for adding accessibility to things like Canvas or WebGL (see: https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...).
> These fonts work fine in Firefox.
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.
See the duck demo here (need to scroll down): https://developers.googleblog.com/2022/09/updates-to-emoji-n...
The duck is invisible on Safari on my iPhone and in Firefox (104.0.1) on my desktop
as noted by jfk13 below, you have to enable `gfx.font_rendering.colr_v1.enabled` in about:config
Makes me think of Fontemon:
https://www.coderelay.io/fontemon.html#player
https://github.com/mmulet/code-relay/blob/main/markdown/HowI...
Perhaps combining this COLRv1 spec and the prior art it's doable today!
https://github.com/mmulet/font-game-engine
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.
https://color.typekit.com/
https://docs.microsoft.com/en-us/typography/opentype/spec/sv...
https://helpx.adobe.com/fonts/using/ot-svg-color-fonts.html
"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."
Google Chrome teams refuses to implement SVG-in-OT. Instead, they wanted to implemented their COLRv1. https://bugs.chromium.org/p/chromium/issues/detail?id=306078...
So this seems like a good thing overall. Note that Firefox doesn't support it at this time.
Where does Mozilla's revenue come from? Are they an impartial 3rd party?
The Arabic scripts look amazing! Gradient support is bigger than color support imo
[1] https://rainbowfoundation.co.kr/gilbeot
And then people who need it will use OCR to translate into text. Which won't always work very well.
More specifically:
The text is right there. It's still HTML.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.
"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."
[0] https://en.wikipedia.org/wiki/TrueType#Hinting_language
[1] https://suricrasia.online/iceberg/
One could, if so inclined, build a complete COLRv1 font parser in PostScript.
"every day". as in "each day". The word "everyday" is an adjective.
It's not something I would bring up in a forum, absent context or someone asking about it, but I'd definitely correct it in formal writing.
Joining words to one compound word is pretty much the example of language evolution.
That seems like a contradiction. If it were clearly wrong, most people would notice. The fact that they don't surely implies that it isn't very clear.
Descriptivism is "shush, if people are using it this way then it's correct".