Recent blog entries for yosch

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.




29 Oct 2013 (updated 29 Oct 2013 at 18:57 UTC) »
Wiki[p|m]edia doesn't like tofu and takes action

No, not that kind of tofu, which is quite delicious actually, but the much less tastier electronic equivalent: empty squares that show up in your digital content when you don't have access to the proper font, which usually leaves you with a bitter taste, especially if it's your own native script and you can't use it.

It's very good to see Wiki[p|m]edia joining others (like Google and Monotype's Noto for example: Noto as in no tofu, see what they did there?) looking into tackling these limitations on the web with their minimal but still quite ambitious Autonym font project.

And I find the font name quite clever too: autonyms (sometimes also called endonyms) are how speakers of a particular language itself call it and also write it ideally: see ScriptSource's list of languages with alternate names.

I suspect it will a huge help in driving home the problems many people still face with not having access to a high-quality open font as a reference implementation of their script but ending up with infamous electronic tofu instead. Starting with getting the name itself right is a great stepping stone.

Go Wiki[m|p]edia!
Update to the OFL FAQ published: version 1.1-update3

Don't miss the newly updated OFL FAQ version 1-1-update3. It may well have the answers you're looking for on the - rather rich and complex - topic of using, distributing and creating open fonts with practical tips and examples.

It takes into account feedback from a wider variety of users of open fonts as well as significant issues within the type design community, like, among other things, delivering optimized webfonts.
Fuentes libres en Madrid, España

Plenty of libre/open font-related sessions on the program at this year's LGM in Madrid...
8 Feb 2013 (updated 9 Feb 2013 at 22:11 UTC) »
New open fonts shipping with LibreOffice 4.0

Interesting to see that LibreOffice 4.0 increases the number of open fonts bundled by default: the release notes mention - among quite a few other nifty new features - that Open Sans by Ascender, PT Serif by ParaType, Source Code Pro and Source Sans Pro by Adobe join the existing Dejavu, Liberation, Gentium and Libertine font families that LibreOffice users can enjoy without having to go through any installation steps.

More quality entries in your font menu :-D

Of course this font repository integration idea sounds very good too!


Some promising aspects of Source Sans Pro, Adobe's recently published open font

So, it looks like Adobe's recent decision to release Source Sans Pro as an open font under the OFL has been well-received in various parts of the interwebs.

I'd like to add big congrats to Paul D Hunt, Ken Lunde, Robert Slimbach, Miguel Souza and Ernie March (and as few others at Adobe I imagine) as well for going open with all this work. May they reap many benefits for this move.

Besides the design quality and the unusual fact that Adobe-affiliated designers and font engineers are directly involved, I think there are some very promising aspects worth pointing out: Source Sans comes with an AFDKO buildpath and the corresponding full set of source files, various smart behaviours (via OpenType), initial focus on supporting languages using extended latin (like Vietnamese and Navajo) and tentative plans for newer writings systems in the published roadmap in which they invite outside participation to the project.

Seeing the authors interact and reply to community input directly in the blog discussion thread is quite promising too: making adjustments to the zip structure of the release, explaining how people can make their own branch if they want, promising more technical documentation on the buildpath, exploring the use of a DVCS and possibly fontforge, etc. IMHO it shows a great willingness to think and act beyond a simple code drop by looking at ongoing maintainership. Many miles ahead compared to somewhat similar open font releases by corporations I've been able to observe previously. Well-done.

I'm looking forward to the Monospace version in the pipeline...

Maybe Adobe will even consider making the AFDKO toolkit more open in the future? There were queries about releasing AFDKO more openly earlier (the python scripts themselves are already under the MIT license)...


145 older entries...

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!