yosch is currently certified at Master level.

Name: Nicolas Spalinger
Member since: 2007-05-05 17:55:05
Last Login: 2014-09-19 17:07:00

FOAF RDF Share This

Homepage: http://planet.open-fonts.org/


Co-author of the Open Font License, contributor to the OFDK (open font design toolkit), contributor to various open font projects, advocate of FLOSS methodologies and best practises to font designers and script engineers, editor of Planet Open Fonts.


Recent blog entries by yosch

Syndication: RSS 2.0
AFDKO released under Apache2

David Lemon from Adobe has just announced during his AtypI talk that the AFDKO has now been officially re-released under the Apache2 license and pushed to this public git repo.

Thank you, Adobe!

The next step is adjusting the installation steps for Debian/Ubuntu and making it easier to integrate in existing workflows and toolkits...
12 Sep 2014 (updated 14 Sep 2014 at 13:17 UTC) »
Update to the OFL FAQ published: version 1.1-update4

Check out the newly updated FAQ (Frequently Asked Questions) for the Open Font License: version 1.1-update4.

It probably has many answers you're looking for on the - rather complicated and subtle - topics of using, distributing, creating and modifying open fonts.

This (small) update takes into account feedback from existing users of the license and clarifies some (small) aspects of the intent and the well-established working model.

The OFL FAQ is getting rather long but then again, it's not the easiest set of related subjects to cover... I hope this continues to be a good and useful resource for the many open font designers out there. If you haven't read it yet, now is probably a good time, otherwise search for your topic in the various sections :-)

IMHO, nobody should have to become a copyright or trademark lawyer - or pay massive legal fees - just to maximise access to some of their creation but still maintain over control the corresponding canonical version. Type designers mostly want to focus on creating and all the rest just seems like a distraction at best or a big headache at worst... but getting a better understanding of the ins and outs of the legal environment of collaborative font design and how the OFL model works practically is always helpful and should spare people some unnecessary surprises.
15 Jun 2014 (updated 15 Jun 2014 at 20:53 UTC) »
Brötli compression and aggressive default subsetting

Working drafts of the Brötli compression spec and the WOFF2 format have been published. For those among you who don't know any Swiss-German, -li is the diminutive form and Brot is bread, so brötli = small bread. Interestingly, it's based on previous optimization work released as zöpfli: Zopf being another kind of bread. Notice a pattern? I wonder if the cantine's menu or local pastry shop had an influence (but it looks like the Umlaut has been lost in translation, oh well).

These small breads come in wide ranges, textures and flavours but it strikes me that the whole point is that, while good bread on its own can sometimes be tasty, it's really the variety of toppings and fillings in these "mini-sandwiches" that create something everyone can choose from and enjoy.

So, while I sincerely applaud all the amazing work done on compression and improving the common webfonts format, I think it's also worth pointing out that many webfont hosting services still strongly push towards a bland taste by default, i.e. without the varied ingredients as filling, i.e. serving a limited subset of the bigger fonts designed for more than one language. They tend to make it harder to use the original wider non-roman Unicode coverage and smart features but instead serve only the basic Latin, especially if you are interested in a lesser-known language and a more complex script. Ugh. Could taste a lot nicer.

For example in Google Fonts, various users keep complaining about how many fonts have been "optimized" to the point where they are broken and useless in various languages. You have to dig deep in the documentation to learn that to restore original functionality, you need to explicitly turn off the subsetting via &subset=all. Some people are less concerned with shaving off a few milliseconds and more with "will this actually work in my target language?".

Hopefully, smaller breads will not mean even less tasty filling IOW the compression gains will also allow fonts and web content in other languages beyond the Latin boundary to become more prominent and accessible. Making the subsetting less aggressive and limiting will result in a much tastier multilingual web.

25 May 2014 (updated 25 May 2014 at 16:27 UTC) »
Recent significant open font releases: Fira Sans, Fira Mono and Source Serif Pro

Don't miss the newest version of Fira [Sans|Mono] (3.1 or 3.106 currently) commissioned by Mozilla from the Spiekermann and Carrois foundries. It should soon appear on http://github.com/mozilla/Fira and http://github.com/mozilla-b2g/moztt (FirefoxOS-specific).

And check out Adobe's Source Serif Pro now also available on https://github.com/adobe/source-serif-pro.

There are lots of interesting questions ahead in terms of how best practises will be defined and applied to open format workflows with multiple tools, DVCS tree structures and ongoing maintainership and release engineering of open fonts such as these...
10 May 2014 (updated 10 May 2014 at 19:46 UTC) »
open fonts vs. DRM-ized online services and desktop distribution channels

The various online webfonts services which now also include open fonts (like fonts under OFL) to bring added value to their existing libraries have a strong tendency to hide the authorship and licensing information as well as put up some DRM walls to make it harder to actually exercize your freedoms or using, distributing, modifying and redistributing these fonts.

The reality is that they have simply dropped open fonts into their proprietary DRM-ized workflows and not done enough due diligence or given enough respect to these authors' copyright, despite all the fancy PR and promises.

If font authors have released their work under a FSF/OSI/community-recognized copyright license then no overarching EULA or subscription agreement can prevent users (and fellow designers) from extracting these open fonts and using them accordingly. And when these online webfont hosting services start providing rich clients to connect into their libraries directly from desktops apps, the DRM scenarios are even worse: they tend not to install them in your font folder directly but into an intermediary hidden folder that you are not supposed to know about or have much control over so they can turn access to the fonts on and off as they wish.

You can understand their desire to lock up the proprietary fonts but they can't do that to the open fonts available through the same channels: in the owning versus renting dichotomy, open fonts are firmly in the camp of owning and even better being able to make it your own and redistribute the modified version. The rights granted to you by any author releasing their creation under an open license doesn't disappear when the software channel is turned off or your subscription is invalid. The whole point of releasing a font under an open license is that it's not under exclusive control any longer and the relationship between the font author(s) and the font user(s) is more direct.

The OFL FAQ is quite clear on this:

1.17 Can Font Software released under the OFL be subject to URL-based access restrictions methods or DRM (Digital Rights Management) mechanisms?

Yes, but these issues are out-of-scope for the OFL. The license itself neither encourages their use nor prohibits them since such mechanisms are not implemented in the components of the Font Software but through external software. Such restrictions are put in place for many different purposes corresponding to various usage scenarios. One common example is to limit potentially dangerous cross-site scripting attacks. However, in the spirit of libre/open fonts and unrestricted writing systems, we strongly encourage open sharing and reuse of OFL fonts, and the establishment of an environment where such restrictions are unnecessary. Note that whether you wish to use such mechanisms or you prefer not to, you must still abide by the rules set forth by the OFL when using fonts released by their authors under this license. Derivative fonts must be licensed under the OFL, even if they are part of a service for which you charge fees and/or for which access to source code is restricted. You may not sell the fonts on their own - they must be part of a larger software package, bundle or subscription plan. For example, even if the OFL font is distributed in a software package or via an online service using a DRM mechanism, the user would still have the right to extract that font, use, study, modify and redistribute it under the OFL.

1.23 Can OFL fonts be included in services that deliver fonts to the desktop from remote repositories? Even if they contain both OFL and non-OFL fonts?

Yes. Some foundries have set up services to deliver fonts to subscribers directly to desktops from their online repositories; similarly, plugins are available to preview and use fonts directly in your design tool or publishing suite. These services may mix open and restricted fonts in the same channel, however they should make a clear distinction between them to users. These services should also not hinder users (such as through DRM or obfuscation mechanisms) from extracting and using the OFL fonts in other environments, or continuing to use OFL fonts after subscription terms have ended, as those uses are specifically allowed by the OFL.

1.24 Can services that provide or distribute OFL fonts restrict my use of them?

No. The terms of use of such services cannot replace or restrict the terms of the OFL, as that would be the same as distributing the fonts under a different license, which is not allowed. You are still entitled to use, modify and redistribute them as the original authors have intended outside of the sole control of that particular distribution channel. Note, however, that the fonts provided by these services may differ from the Original Versions.

Practically, users of Skyfonts with the Google fonts service can simply go to ~/Library/Application Support/skyfonts-google/ on OSX (or C:\Users\%username%\AppData\Roaming\skyfont-google\ on Windows) and retrieve the open fonts they have synchronised.

Similarly users of Creative Cloud with Typekit desktop can go to ~/Library/Application Support/Adobe/CoreSync/plugins/livetype/.r/ on OSX (or C:\Users\%username%\AppData\Roaming\CoreSync\plugins\livetype\r on Windows) and retrieve the open fonts they have synchronised. Note the .r hidden folder and the . in front of the various fonts to hide them. You have to reveal hidden files to be able to see them.

Notice the difference between the two: Skyfonts isn't hiding their dedicated folder any longer and newer versions of the desktop client even provide a menu entry "Reveal in Finder", Typekit Desktop still hides fonts and gives them an arbitrary numerical filename.

Of course, users should always double-check the metadata inside a font to make sure they are not retrieving a restricted proprietary font by mistake but an open font. Various tools are available to expose the font properties. Or just open them in FontForge and go to Element -> Font Info.

Surely it would be simple for them not to apply these DRM measures to any open fonts in their catalogues and keep them in a dedicated separate folder which has no need to be hidden and could just be in the normal user font folder? Or is it because, despite all the noise about open fonts being so horribly dreadful, lots of people are finding them good and useful and they actually continue to draw in subscribers for the proprietary fonts?

Sorry but you can't have the flexibility of taking advantage of open fonts without properly propagating the rights attached to them by their original authors. OK, it's a pretty weak DRM that can be worked around but it's still something that goes against the wishes of original authors and the general spirit of open fonts. If you want complete control and exclusivity then pay the authors the corresponding price and don't just leech off their open fonts without keeping them open. So, please drop that obfuscation trick and give these fonts the place they deserve in your font catalogues. Everybody will benefit.

150 older entries...


yosch certified others as follows:

  • yosch certified mako as Master
  • yosch certified raph as Master
  • yosch certified bdale as Master
  • yosch certified mjg59 as Master
  • yosch certified rms as Master
  • yosch certified roozbeh as Master
  • yosch certified glasseyes as Master
  • yosch certified hub as Master
  • yosch certified jamesh as Master
  • yosch certified seb128 as Master
  • yosch certified menthos as Master
  • yosch certified karlberry as Master
  • yosch certified gerv as Master
  • yosch certified pabs3 as Master
  • yosch certified caolan as Master

Others have certified yosch as follows:

  • redi certified yosch as Journeyer
  • fzort certified yosch as Journeyer
  • glasseyes certified yosch as Journeyer
  • murajov certified yosch as Journeyer
  • karlberry certified yosch as Master

[ Certification disabled because you're not logged in. ]

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

Share this page