Subscribe to RSS Subscribe to Comments

All font metadata, all the time

A recurring obstacle within the problem of “making fonts work better for desktop Linux users” (see previous posts for context) is how much metadata is involved and, thus, needs to be shuffled around so that it can be exposed to the user or accessed by system utilities. People hunting for a font to install need to see metadata about it in the package manager / software center; people selecting a font from their collection need to see metadata about it in the application they’re using (and within the font-selection dialogs, if not elsewhere in the app’s UI). The computing environment needs to be aware of metadata to set up the correct rendering options and to pass along the right information to other components above and below in the stack.

As it stands now, there are several components on a GNOME-based system that already do track metadata about fonts: Pango, Fontconfig, AppStream, HarfBuzz, GTK+, etc. There are also a ton of metadata fields already defined in the OpenType font format specification. Out of curiosity, I decided to dig into the various data structures and see which properties are tracked where.

I put the results into a Markdown table as a GitLab “snippet” (a.k.a., gist…) and posted it as this font metadata cross-reference chart. For comparison’s sake, I also included the internal data structures of the old Fontmatrix font manager (which a lot of folks still reference as a high-water mark) and the … shall we say “terse” … font ontology defined in Nepomuk. I basically used the OpenType spec as the reference point, although some of the metadata in that column (the left-most) is more of a “derived property” than an actual field. Like “is this font a color font” — you might determine that by looking for one of the four possible color font tables (sbix, CBDT, SVG, or COLR), but there’s not a “color included” bit, exactly.

There are just over 50 properties, which is a soft number because it includes a lot of not-quite aligned items, such as where OpenType stores a separate field for the font vendor name and the font vendor’s URL, and some properties that are overly general in one or more implementations. That, and it includes several of the derived properties mentioned just above.

You’re welcome to suggest additions. I did focus on the user-visible metadata world, which means the table excludes some system-oriented properties like the em size and baseline height. My interest in primarily in things that directly tie in to how users select fonts for use. I’m definitely not averse to pull requests to add that system stuff to the table, though. That’s why I put it on a GitLab snipgist — personally, I find Markdown tables awful to work with. But I digress.

No idea where this goes from here. There was some talk around the Fonts BoF at GUADEC this past July about whether or not GNOME ought to cache font metadata in some sort of user-local database. My recollection is that this would be helpful in several places; certainly as it stands now, for example, the awesome work that Matthias Clasen has done reengineering the GTK+ font explorer seems to require mining each font binary, so saving those results for reuse seems like a clear win. If Pango and the top-level application are also parsing the font binary just to show stuff, that’s overkill.

In my impromptu GUADEC talk about font selection, I noted that other GNOME “content objects” like audio, video, and image files all seems to get their metadata taken care of by Tracker, and posited that Tracker could take that task on for fonts as well. Most developers there didn’t seem to think this was a great fit. Some people have issues with Tracker anyway, but Tracker is also (by design) a “user-level” service, so putting font metadata into it would not solve the caching needs of the various libraries and system components.

Nevertheless, I did toy with the idea of writing up a modern Nepomuk ontology for font objects based on the grand-unified-GitLab-snipgist table (Nepomuk being the standard that Tracker uses). That may just be out of personal self-interest in teasing out structure from the table itself. It might be useful, for example, to capture more structure about which properties are related in which ways — such as where they are nested within other properties, are duplicates, or are mutually exclusive. And a lot more for which Markdown isn’t remotely useful.

How many open fonts licenses are there?

Recently I’ve been stump-speeching at the various free-software conferences I haunt on the topic of some plumbing-layer issues that affect using fonts on Linux systems.

One interesting rabbit hole in this field of stumps is the subject of font licenses. Today, we live in a harmonious world where open and libre fonts are uniformly distributed under the SIL Open Font License, and all is simple in our garden. Or so people think.

Technically speaking, of course, there have been two versions of the SIL OFL, so it’s actually possible that some of the fonts you refer to as “OFL licensed” are yours under the terms of OFL 1.0, and others under the current version, 1.1. It’s also possible that some of those fonts were published with the Reserved Font Name clause activated and some were not. So there are four possibilities, if you count how that clause alters compliance tracking.

Nevertheless, that’s still a complexity-free environment in which to roam: four license variants, demarking a known-and-knowable world like the pillars of Hercules & whatever was directly opposite the pillars of Hercules.

Five, if you count the fact that you may have fonts on your system that are published under the other major alternative, the GNU GPL with Font-Embedding Exception. Six if you include the MIT license, let’s say. Seven if you include Apache, eight or nine if you include BSD variants with a different number of clauses (ignoring for now how many, because I lose track; my point, after all, is that there are very few).

Still, that’s not that many. Ten if you include the IPA Font License. Eleven if you have X11 fonts. Twelve if you have an Artistic License font. Which exist.

That’s what we tell ourselves, anyhow. But although I didn’t mention it up front, we’re really just limiting the above list to the licenses currently included in the SPDX License List. Although SPDX is widely used as a machine-readable way to track licenses, it’s not the only place to look to see what licenses people are using for their open fonts.

If you run Debian or a Debian-based distribution, for example, then you don’t live in the small, confined world of ten-ish libre font licenses. You live, instead, in a funtastic world of broad historical context and twenty-plus-ish years of free software and, for much of that time period, there were no readymade, boiler-plate–like font licenses to select. Consequently, many people imbued with sudden inspiration rose up and boldly wrote their own licenses.

Since font packages tend to be things that reach a “completion point”, after which they get few-to-no further releases, many of these license-pioneering font packages persist to this day. As a result, their singleton licenses survive into the 21st Century as well.

A few such coelacanths belong to fonts well-known among Debian users, such as

  • The Bitstream Vera license (which also applies to DejaVu)
  • The Bitstream Charter license (which is not under same license as Vera, although it is comparable)
  • The Liberation Fonts License
  • The ParaType Free Font License
  • The Ubuntu Font License
  • The STIX Fonts License
  • The TUG Utopia License
  • The Larabie Fonts EULA

Others might not be as well-known, but are in fighting shape nonetheless:

  • The M+ Fonts Project License
  • The Arphic Public License
  • The GUST Font License
  • The Magenta Open License
  • The Mikachan Fonts License

If you have TeX installed, you have even more options to explore, including:

  • The Day-Roman Font License
  • The Luxi Fonts License
  • The Luxi Mono Font License
  • The Adobe Euro Font License
  • The Librerias Gandhi Font License
  • The Literat Font License
  • The IBM Courier License

That might seem like enough. But license authoring is a creative endeavor, and when the muse strikes, it can be hard to ignore. Yet not everyone so inspired is truly gifted with originality, so there are several  licenses to be found that may or may not actually be doppelgangers of other licenses (apart from the name itself). If you’re a lawyer, you can probably read and decide for yourself. If you’re unwilling to set aside that much of your day and that much of your soul, you might just assume that these other licenses are all distinct:

  • The Baekmuk License
  • The Open Government Data License
  • The Hanazono Font License
  • The UmeFont License
  • The BaKoMa Fonts License
  • The Misaki Fonts License
  • The Oradano Mincho Fonts License
  • The SazanamiFont License
  • The Hershey Fonts License

But that’s about it. Although, to be honest, that’s just as far as I got digging into packages in Debian, and there are a few I never could sort out, such as the license of WINE fonts and Symbola Fonts license. Maybe I should start looking again. Oh, and I guess there are LaTeX-licensed fonts.

The Font BoF at Libre Graphics Meeting 2018

(Call it What’s New in Open Fonts, № 003 if you must. At least this one didn’t take as long as the LibrePlanet one to get pushed out into the street.)

Libre Graphics Meeting (LGM) is the annual shindig for all FOSS creative-graphics-and-design projects and users. This year’s incarnation was held in Sevilla, Spain at the end of April. I barely got there in time, having been en route from Typo Labs in Berlin a week earlier.

I put a “typography BoF” onto the schedule, and a dozen-ish people turned up. BoFs vary wildly across instances; this one featured a lot of developers…


…which is good. I got some feedback to a question I posed in my talk: where is the “right” place for a font package to integrate into a Linux/FOSS help system? I could see that working within an application (i.e., GIMP ingests any font-help files and makes them available via the GIMP help tool) or through the standard desktop “help.”

Currently, font packages don’t hook into the help system. At best, some file with information might get stuffed somewhere in /usr/share/doc/, but you’ll never get told about that. But they certainly could hook in properly, to provide quick info on the languages, styles, and features they support. Or, for newer formats like variable fonts or multi-layer color fonts, to provide info on the axes, layers, and color palettes. I doubt anyone could use Bungee without consulting its documentation first.

But a big question here (particularly for feature support) is what’s the distinction between this “help” documentation and the UI demo strings that Matthias is working on showing in the GTK+ font explorer (as discussed in the LibrePlanet post).

The short answer is that “demo strings” show you “what you will get” (and do so at a glance); help documentation tells you the “why this is implemented” … and, by extension, makes it possible to search for a use case. For example: SIL Awami implements a set of features that do Persian stylistic swashes etc.

You could show someone the affected character strings, but knowing the intent behind them is key, and that’s a help issue. E.g., you might open the help box and search for “Persian fonts” and you’d find the Awami help entry related to it. That same query wouldn’t work by just searching for the Arabic letters that happen to get the swash-variant treatment.

Anyway, GIMP already has hooks in place to register additions to its built-in help system; that’s how GIMP plug-ins get supported by the help framework. So, in theory, the same hooks could be used for a font package to let GIMP know that help docs are available. Inkscape doesn’t currently have this, but Tavmjong Bah noted that it wouldn’t be difficult to add. Scribus does not seem to have an entry point.

In any case, after just a couple of minutes it seemed clear that putting such help documentation into every application is the wrong approach (in addition to not currently being possible). It ought to be system wide. For desktop users, that likely means hooking into the GNOME or KDE help frameworks.

Styles and other human-centric metadata

The group (or is it birds?) also talked about font management. One of the goals of the “low hanging fruit” improvements to font packaging that I’ve been cheerleading for the past few months is that better package-level features will make it possible for *many* application types and/or utilities to query, explore, and help the user make font decisions. So you don’t get just the full-blown FontMatrix-style manager, but you might also get richer font exploration built into translation tools, and you might get a nice “help me find a replacement for the missing font in this document” extension for LibreOffice, etc. Maybe you could even get font identification.

Someone brought up the popular idea that users want to be able to search their font library via stylistic attributes. This is definitely true; the tricky part is that, historically, it’s proven to be virtually impossible to devise a stylistic-classification scheme that (a) works for more than just one narrow slice of the world’s typefaces and (b) works for more than just a small subset of users. PANOSE is one such system that hasn’t take the world over yet; another guy on Medium threw Machine Learning at the Google Fonts library and came up with his own classification set … although it’s not clear that he intends to make that data set accessible to anybody else.

And, even with a schema, you’d still have to go classify and tag all of the actual fonts. It’d be a lot of additional metadata to track; one person suggested that Fontbakery could include a check for it — someone else commented that you’d really want to track whether or not a human being had given those tags a QA/sanity check.

Next, you’d have to figure out where to store that stylistic metadata. Someone asked whether or not fontconfig ought to offer an interface to request fonts by style. Putting that a little more abstractly, let’s say that you have stylistic tags for all of your fonts (however those tags are generated); should they get stored in the font binary? In fonts.conf? Interestingly enough, a lot of old FontMatrix users still have their FontMatrix tags on their system, so they say, and supporting them is kind of a de-facto “tagging solution” for new development projects. Style tags (however they’re structured) are just a subset of user-defined tags anyway: people are certainly going to want to amend, adjust, overwrite, and edit tags until they’re useful at a personal level.

Of course, the question of where to store font metadata is a recurring issue. It’s also come up in Matthias Clasen’s work on implementing smart-font–feature previews for GTK+ and in the AppStream project <font>-object discussion. Storing everything in the binary is nice ‘n’ compact, but it means that info is only accessible where the binary is — not, for example, when you’re scrolling through a package manager trying to find a font you want to install. Storing everything in a sidecar file helps that problem, but it means you’ve got two files to lose instead of one. And, of course, we all die a little on the inside whenever we see “XML”.

Dave Crossland pointed out one really interesting tidbit here: the OpenType STAT table, which was ostensibly created in conjunction with the variable-fonts features, can be used in every single-master, non-variable font, too. There, it can store valuable metadata about where each individual font file sits on the standard axes of variation within a font family (like the weight, width, and optical size in relation to other font files). I wrote a brief article about STAT in 2016 for LWN if you want more detail. It would be a good thing to add to existing open fonts, certainly. Subsequently, Marc Foley at Google has started adding STAT tables to Google Fonts families; it started off as a manual process, but the hope is that getting the workflow worked out will lead to proper tooling down the line.

Last but not least, the Inkscape team indicated that they’re interested in expanding their font chooser with an above-the-family–level selector; something that lets the user narrow down the fonts to choose from in high-level categories like “text”, “handwriting”, “web”, and so on. That, too, requires tracking some stylistic information for each font.

The unanswered question remains whose job it should be to fix or extend this sort of metadata in existing open fonts? Particularly those that haven’t been updated in a while. Does this work rise to the level of taking over maintainership of the upstream source? That could be controversial, or at least complicated.

Specimens, collections, and more

We also revisited the question of specimen creation. We discussed several existing tools for creating specimens; when considering the problem of specimen creation for the larger libre font universe, however, the problem is more one of time x peoplepower. Some ideas were floated, including volunteer sprints, drives conducted in conjunction with Open Source Design, and design teachers encouraging/assigning/forcing(?)/cajoling students to work on specimens as a project. It would also certainly help matters to have several specimen templates of different varieties to help interested contributors get started.

Other topics included curated collections of open fonts. This is one way to get over the information-overload problem, and it has come up before; this time it was was Brendan Howell who broached the subject. Similar ideas do seem to work for Adobe Typekit. Curated collections could be done at the Open Font Library, but it would require reworking the site. That might be possible, but it’s a bit unclear at the moment how interested Fabricatorz (who maintains the site) would be in revisiting the project in such a disruptive way — much less devoting a big chunk of “company time” to it. More discussion needed.

I also raised the question of reverse-engineering the binary, proprietary VFB font-source format (from older versions of FontLab). Quite a few OFL-licensed fonts have source  available in VFB format only. Even if the design of the outlines is never touched again, this makes them hard to debug or rebuild. It’s worse for binary-only fonts, of course, but extending a VFB font is not particularly doable in free software.

The VFB format is deprecated, now replaced by VFC (which has not been widely adopted by OFL projects, so far). FontLab has released a freeware CLI utility that converts VFB smoothly to UFO, an open format. While VFB could perhaps be reverse-engineered by (say) the Document Liberation Project, that might be unnecessary work: batch converting all OFL-VFB fonts once and publishing the UFO source may suffice. It would be a static resource, but could be helpful to future contributors.

It probably goes without saying, but, just in case, the BoF attendees did find more than a few potential uses for shoehorning blockchain technology into fonts. Track versioning of font releases! Track the exact permission set of each font license sold! Solve all your problems! None of these may be practical, but don’t let that stand in the way of raking in heaps of VC money before the Bitcoin bubble crashes.

That about wraps it up. There is an Etherpad with notes from the session, but I’m not quite sure I’ve finished cleaning it up yet (for formatting and to reflect what was actually said versus what may have been added by later edits). I’ll append that once it’s done. For my part, I’m looking forward to GUADEC in a few weeks, where there will inevitably be even more excitement to report back on. Stay tuned.

Fontstuff at LibrePlanet 2018

I’m going to try and capture some thoughts from recent conferences, since otherwise I fear that so much information gets lost in the fog.

* (If you want to think of it this way, consider this post “What’s New in Open Fonts, № 002”)

I went to LibrePlanet a few weeks ago, for the first time. One of the best outcomes from that trip (apart from seeing friends) was the hallway track.

[FYI, I was happy to see that LWN had some contributors on hand to provide coverage; when I was an editor there we always wanted to go, but it was never quite feasible, between the cost and the frequent overlap with other events. Anyway, do read the LWN coverage to get up to speed on the event.]


Dave Crossland and I talked about Reserved Font Names (RFNs), an optional feature of the SIL Open Font License (OFL) in which the font publisher claims a reservation on a portion of their font’s name. Anyone’s allowed to make a derivative of the OFL-licensed font (which is true regardless of the RFN-invocation status), but if they do so they cannot use *any* portion of the RFN in their derivative font’s name.

The intent of the clause is to protect the user-visible “mark” (so to speak; my paraphrase) of the font publisher, so that users do not confuse any derivatives with the original when they see it in menus, lists, etc.

A problem arises, however, for software distributors, because the RFN clause is triggered by making any change to the upstream font — a low bar that includes a lot of functions that happen automatically when serving a font over HTTP (like Google Fonts does) and when rebuilding fonts from source (like Debian does).

There’s not a lot of good information out there on the effects that RFN-invocation has on downstream software projects. SIL has a section in its FAQ document, but it doesn’t really address the downstream project’s needs. So Dave and I speculated that it might be good to write up such a document for publication … somewhere … and help ensure that font developers think through the impact of the decision on downstream users before they opt to invoke an RFN.

My own experience and my gut feeling from other discussions is that most open-font designers, especially when they are new, plonk an RFN statement in their license without having explored its impact. It’s too easy to do, you might say; it probably seems like it’s built into the license for a reason, and there’s not really anything educating you about the impact of the choice going forward. You fill in a little blank at the very top of the license template, cause it’s there, and there’s no guidance.  That’s what needs to change.


We also chatted a little about font packaging, which is something I’m keen to revisit. I’ve been giving a talk about “the unsolved problems in FOSS type” the past couple of months, a discussion that starts with the premise that we’ve had open-source web fonts for years now, but that hasn’t helped open fonts make inroads into any other areas of typography: print, EPUB, print-on-demand, any forms of marketing product, etc. The root cause is that Google Fonts and Open Font Library are focused on providing a web service (as they should), which leaves a
lot of ground to be covered elsewhere, from installation to document templates to what ships with self-contained application bundles (hint: essentially nothing does).

To me, the lowest-hanging fruit at present seems to be making font packages first-class objects in the distribution packaging systems. As it is, they’re generally completely bare-bones: no documentation, no system integration, sketchy or missing metadata, etc. I think a lot can be done to improve this, of course. One big takeaway from the conversation was that Lasse Fister from the Google Fonts crew is working on a specimen micro-site generator.

That would fill a substantial hole in current packages: fonts tend to ship with no document that shows the font in use — something all proprietary, commercial fonts include, and
that designers use to get a feel for how the font works in a real document setting.

Advanced font features in GTK+ and GNOME

Meanwhile Matthias Clasen has been forging ahead with his own work enhancing the GNOME font-selection experience. He’s added support for showing what variation axes a variable font contains and for exposing the OpenType / smart-font features that the font includes.

He did, however, bring up several pain points he’s encountered. The first is that many of the OpenType features are hard to preview/demonstrate because they’re sparsely documented. The only substantive docs out there are ancient Microsoft material definitely written by committee(s) — then revised, in piecemeal format, by multiple unrelated committees. For example, go to the link above, then try and tell me the difference between `salt` (stylistic alternates), `ccNN` (character variants) and `ssNN` (stylistic sets). I think there’s an answer, but it’s detective work.

A more pressing concern Matthias raised was the need to create “demo strings” that show what actually changes when you enable or disable one of the features. The proper string for some features is obvious (like `onum` (oldstyle numerals): the digits 0 to 9). For others, it’s anybody’s guess. And the font-selector widget, ideally, should not have to parse every font’s entire GSUB feature table, look for all affected codepoints, and create a custom demo string. That might be arbitrarily complex, since GSUB substitutions can chain together, and might still be incorrect (not to mention the simpler case, of that method finding you random letters that add up to unhelpful gibberish).

At lunch on Sunday, Matthias, Dave, Owen Taylor, Felipe Sanches, and a few others … who I’m definitely drawing a blank on this far after the fact (go for the comments) … hashed through several other topics. The discussion turned to Pango, which (like several other storied GNOME libraries), isn’t exactly unmaintained, but certainly doesn’t get attention anymore … see also Cairo….). There are evidently still some API mismatches between what a Pango font descriptor gives you and the lower-level handles you need to work with newer font internals like
variation axes.

A longer-term question was whether or not Pango can do more for applications — there are some features it could add, but major work like building in hyphenation or justification would entail serious effort. It’s not clear that anyone is available to take on that role.


Of course, that ties into another issue Matthias raised, which is that it’s hard to specify a feature set for a “smart” font selector widget/framework/whathaveyou for GTK+ when there are not many GTK-based applications that will bring their own demands. GIMP is still using GTK2, Inkscape basically does its own font selection, LibreOffice has a whole cross-platform layer of its own, etc. The upshot is that application developers aren’t bringing itches needing to be scratched. There is always Gedit, as Matthias said (which I think was at least somewhat satirical). But it complicates the work of designing a toolkit element, to be sure.

The discussion also touched on how design applications like Inkscape might want to provide a user interface for the variable-font settings that a user has used before. Should you “bookmark” those somehow (e.g., “weight=332,width=117,slant=10” or whatnot)? If so, where are they saved? Certainly you don’t want users to have to eyeball a bunch of sliders in order to hit the same combination of axes twice; not providing a UI for this inevitably leads to documents polluted with 600-odd variable-font-setting regions that are all only slightly off from each other. Consensus seemed to lean towards saving variable-axes-settings in sort of “recently used” palette, much as many applications already do with the color picker. Still waiting to see the first implementations of this, however.

As we were leaving, Matthias posed a question to me — in response to a comment I’d made about there needing to be a line between a “generic” font selector and a “full-featured” font selector. The question was what sort of UI was I envisioning in the “generic” case, particularly where variable fonts are concerned, as I had suggested that a full set of sliders for the fonts variation axes was too complex.

I’m not sure. On the one hand, the simple answer would be “none” or “list the variation axes in the font”, but that’s not something I have any evidence for: it’s just a easy place to draw a line.

Perhaps I’m just worried that exposing too many dials and controls will turn users off — or slow them down when they’re trying to make a quick choice. The consumer/pro division is a  common tactic, evidently, for trying to avert UI overload. And this seems like a place where it’s worth keeping a watchful eye, but I definitely don’t have answers.

It may be that “pro” versus “consumer” user is not the right plane on which to draw a line anyway: when I was working on font-packaging questions, I found it really helpful to be document-first in my thinking (i.e., let the needs of the document the user is working on reveal what information you want to get from the font package). It’s possible that the how-much-information-do-you-show-in-the-UI question could be addressed by letting the document, rather than some notion of the “professionalism” of the user, be the guide. More thinking is required.

Have typography, will travel


I realize that I’m a bit late in publishing this news but, to be honest, I never was great about the blogging regularly anyway.

In any case, this post is a bit of a public announcement: I’m happy to say that I recently completed an extremely busy year working on my Master of Arts in Typeface Design (MATD) degree at the University of Reading. Consequently, I am now back out in the real world, and I am looking for interesting and engaging employment opportunities. Do get in touch if you have ideas!

For a bit of additional detail, the MATD program combines in-depth training about letterforms, writing, non-Latin scripts, and typeface development with rigorous academic research. On the practical side, we each developed a large, multi-style, mutli-script family of fonts (requiring the inclusion of at least one script that we do not read).

My typeface is named Sark; you can see a web and PDF specimen of it here at the program’s public site. It covers Latin, Greek, Cyrillic, and Bengali; there is a serif subfamily tailored for long-form documents and there is a sans-serif subfamily that incorporates features to make it usable on next-generation display systems like transparent screens and HUDs.

My dissertation was research into software models for automatic (and semi-automatic) spacing and kerning of fonts. It’s not up for public consumption yet (in any formal way), as we are still awaiting the marking and review process. But if you’re interested in the topic, let me know.

Anyway, it was a great experience and I’m glad to have done it. I’m also thrilled that it’s over, because it was intense.

Moving ahead from here, I am looking forward to reconnecting with the free-software community, which I only had tangential contact with during my studies. That was hard; I spent more than thirteen years working full-time as a journalist exclusively covering the free-and-open-source software movement. I did get to see a lot of my friends who work on typography and font-related projects, because I still overlapped with those circles; I look forward to seeing the rest of you at the next meetup, conference, hackathon, or online bikeshedding session.

As for what sort of work I’m looking for, I’m keeping an open mind. What I would really love to find is a way (or ways) to help improve the state of type, typography, and documents within free-software systems. The proprietary software world has typefaces and text-rendering technology that is determined by things like sales figures; free software has no such limitations. The best typesetting systems in the world (like TeX and SILE) are free software; our documents and screens and scripts have no reason to look second-best, compared to anyone.

So if I can do that, I’ll be a happy camper. But by all means, I’m still going to remain a camper with a lot of diverse and peculiar interests, so if there’s a way I can help you out in some other fashion, don’t be shy; let me know.

I have a few contract opportunities I’m working on at the moment, and I am contributing to LWN (the best free-software news source in the dimension) as time allows. And I’m gearing up to tell you all about the next editions of Texas Linux Fest and Libre Graphics Meeting. Oh, and there are some special secret projects that I’m saving for next time….

So that’s it from me; how are you?

Next Page »

Based on FluidityTheme Redesigned by Kaushal Sheth