Recent blog entries for GrahamAsher

I just created an entry for my CartoType project, which is a commercial project. Looking at the Advogato home page I surmise that perhaps I should have done this only if CartoType was free.

Well, if the Advogato people (Raph Levien?) don't like it I suppose they will just take it off. Oh well.

9 Jan 2006 (updated 9 Jan 2006 at 23:09 UTC) »

Spent the day writing a parser for LDML (the XML format invented by the Unicode people for storage locale data: it stands for Locale Data Markup Language) for one of my clients.

This has been brewing a long time. My collation routines have been using a mixture of ad-hoc file formats and general hackery, and if there's now going to be an authoritative repository of locale data maintained by www.unicode.org I am going to use it.

LDML is certainly not mature yet, and even contains an absurd spelling mistake ('quarternary' for 'quaternary', as the name of an attribute and part of the name of another) and is going to be hard to parse, but it's a lot better than the alternatives.

I use Expat for XML parsing. I also use Expat in Cartotype, and it's one of the nicest little open source components I've come across.

My friend Frank came round this evening and had a look at the latest version of CartoType and said some encouraging things, which put some heart into me. We fiddled around with style sheets for a bit to try to get more street names to appear at 1:15000 scale, which is roughly what you get in a printed street atlas, and compared it with Nicholson's Greater London Street Atlas to see how we were doing. Not bad, but I think I'll have to start doing more to fit names into impossibly small spaces. CartoType jiggles each name around to find a place where it doesn't overlap, and then tries abbreviating it and jiggles it some more, and then changes to a condensed font and tries again, which is good, but not good enough: I need to get it to try folding the name on to two lines, which brings in more problems when the name has to be drawn on a curved path, because one of the two lines of text is going to be on the inside of the curve and have to turn a sharper corner, which can look ugly.

This is my first entry for a hell of a long time, I see. Well, I worked for Artifex for two periods of several months with a gap in the middle, ending in April 2003. I eventually finished the GhostScript incremental font loading system and general bridge between GhostScript and FreeType, but unfortunately it is unlikely to become an official part of GhostScript because of difficulties in matching up what GhostScript wants and what FreeType can provide; Artifex eventually put the whole thing aside, and that was the right thing to do. I wasn't working on this full-time, and wasn't able to get familiar enough with GhostScript internals to sort out the problems. GhostScript is very complicated, and entirely C, and makes use of many home-grown conventions; and it has grown like the accretion disk of a nascent galaxy, and over roughly the same timescale.

It was very pleasant working with the Artifex people, especially Raph and Miles. They tolerated my slow progress for a long time ;-)

In my spare time I am working on a new mapping project, CartoType. This isn't open-source, or freeware, or even shareware, but makes use of whatever open-source components it can, like FreeType. I'll be feeding back any fixes and other useful new stuff I discover into the open-source components that I use, so it won't be all take and no give.

I now have a very rough design worked out for the incremental FreeType font system. The idea is to support any kind of font loaded by GhostScript that can be added to incrementally. I am doing this generically by designing an interface that contains a very small number of functions (well, two at the moment) for getting font information. (It's a pain doing this in C - it would be easier and cleaner in C++. I have argued ad nauseam for a C++ rewrite of FreeType, and have actually done some of this work myself, but not for public release unfortunately. So you will have to take my word that it works like a Swiss watch;- ) ) Anyway, the idea is that to open an incremental font, like, say, a Type 42 font with no glyph table, you supply a new member of FT_Open_Args that points to your object implementing the new interface. FreeType stores this new arg in the FT_Face object and uses its functions where appropriate - in this case, to get glyph data from the PostScript font's GlyphDirectory.

Yesterday I started working for Artifex on adding a new module to FreeType to enable it to render dynamically modifiable fonts presented to it by GhostScript. This stuff is to be released publicly so I guess I can talk about it here.

First task: get hold of the latest versions of FreeType and GhostScript, build them from source, and figure out how GhostScript loads fonts. And try to understand the existing bridge between GhostScript and Agfa-Monotype's UFST.

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!