Older blog entries for yosch (starting at number 158)

Libre Graphics Magazine issue on fonts

Go check out the latest edition of the Libre Graphics Magazine.

The issue (2.3) is about type, libre/open fonts and related topics from the perspective of a fairly wide selection of authors.

Go ahead: preview, buy, subscribe :-)
24 Sep 2014 (updated 29 Sep 2014 at 13:17 UTC) »
FontLab VI demo at AtypI2014 Barcelona: new drawing features, smarter workflows and better interop with native UFO support and fontgate cross-platform library

During AtypI2014 in Barcelona, Thomas Phinney invited some participants to a special evening presenting the upcoming FontLab VI based on the Victoria re-write and re-architecturing that has been in the works for a few years. (BTW, if you missed it, there is a public video recording from part of a similar talk/demo at AtypI2013 Amsterdam.)

These are the notes I jotted down during the demo evening:

drawing-related features:
  • on-canvas editing of multiple glyphs at the same time
  • smart multi-selection of BCPs
  • drag'n'drop and rich copy'n'paste directly on the canvas
  • dedicated sketchboard to emulate paper-sketching
  • import bitmaps assets and trace directly on canvas
  • smart zooming, scrolling and infinite canvas
  • lasso selection
  • smart guidelines and snapping
  • sliding beziers points (g2 continuity)
  • special selection to move two BCPs at the same time with automatic harmonizing (Tuni line)
  • eraser for more natural point simplification directly on canvas
  • linked clones, with each change propagating independently
  • smart anchors expressed using fractional coordinates with keywords and autosuggested formulas for transforms and boolean operations
  • glue tool to copy only a portion of an outline and a few BCPs
  • in-place measuring tool
  • preview waterfall panel


workflow-related features:
  • context-sensitive side panels to declutter the interface (TAB key hides them quickly)
  • font comparison tool with multiple layers
  • zip file containing assets and font sources can be imported directly
  • easier navigation of character groups and unicode blocks
  • bookmark and history panel as you navigate into your existing and desired blocks
  • in-place OpenType feature editing with an advanced source code widget
  • support for multiple monitors
  • exporting your workspace to PDF and SVG
  • Harfbuzz integration for high-end realistic rendering of OpenType features
  • ClearType integration for realistic rendering (no need to export to Windows for testing)
  • git integration with commands in a dedicated menu with the goal of enabling better tracking of changes with visual diffing


interoperability-related features:
  • native support of UFO2 and UFO3, both for import and export
  • improved python APIs, compatible with robofab
  • full exposing of the APIs via QT UI designer


Soooo, plenty of great new features both in the UI, around the new workflows and in the internal engine but still no release schedule. The private beta program has yet to start. They kept talking of a codebase in alpha stage. Maybe a public beta program will happen as well...

Being made with QT, cross platform porting is now much easier. FontLab is being developed on OSX and tested there primarily but the codebase for the Windows version is only 3% different. The main developer said that a Linux version is doable but there is no definite plan or decision made in that area yet. Until other more open editors catch up, FontLab is still the (albeit proprietary) industry heavyweight. Many people are looking forward to the new features... if they haven't switched yet that is.

Glyphs is the editor most people start with nowadays - including at the MATD in Reading and it's getting glowing reviews and wider support from various parts of the typeface design community. FontLab should be seeing the glyphs on the wall (!) and hurrying up the release. The announcements will probably appear on the forum and the blog.

I've been promised a Debian/Ubuntu version of fontgate for testing server-side interop between font formats, testing, generation with python bindings. This would be fantastic for bridging FontLab with newer, more collaborative workflows and other tools in the OFDK and would increase value in FontLab's UI features. Wait and see...

AFDKO progress

It's good to see that the recently re-released AFDKO is starting to get some attention and (small) things are starting to get merged back in.

There is packaging work underway by ChangZhuo Chen (陳昌倬) from the Debian pkg-fonts team.

There are still various issues to deal with for this codebase to be brought in line with Debian policies, but I was able to successfully rebuild Adobe Source Serif and Adobe Source Sans on Ubuntu 14.04.

This means we are now closer to the long-term goal of a containerized, autobuildable, open-standards-based crossplatform buildpath for complex fonts. New development and testing workflows will be much easier to integrate, so that's good news for everyone :-)

23 Sep 2014 (updated 23 Sep 2014 at 18:35 UTC) »
Open and collaborative font design in a web fonts world: AtypI2013 Amsterdam presentation and panel on open fonts by Victor Gaultney and font industry representatives

Even if you didn't attend the AtypI2013 conference in Amsterdam, you can now watch the video recording of "Open and collaborative font design in a web fonts world" a presentation Victor Gaultney followed by a discussion panel with various key font industry representatives.

Thanks to the video team for their efforts in making more of these AtypI presentations publicly available!

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!

149 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!