← Back to team overview

kicad-developers team mailing list archive

Re: Re: Vector fonts


Thanks Lorenzo,

Let's please start by identifying what problems we are trying to solve, enumerate them in a list please. Then more folks will be able to contribute to a solution.

I have split this posting into Problems and Potential Solutions. There are a number of different usages of fonts: drawing on screen while in Kicad programs, plotting to gerber, plotting to svf, plotting to hpgl, plotting to ps. Speed is most important for the drawing on screen usage. The other usages can take a performance hit.


I am bringing in Jean-Pierre's comment about wxFonts not being scaled within a wxDC properly.

Never told I want to yank out Hersheys when I've just finished the Latin-1 repertoire :D:D

The problem is people wants to use international characters (example: polish ones, I have no ideas of what strange letters they use apart of U+0142 LATIN SMALL LETTER L WITH STROKE :P). (ISO apparently doesn't want... 3098 only specifies latin, greek, cyrillic and diacritics but, as usual with ISO standards, who cares :D And, anyway, Hersheys predates 3098 so who cares, DOUBLY :D:D)

At the moment the repertoire includes:
- Standard ISO 646 ASCII
- Cyrillic (no idea if it is complete or not)
- ISO 8859-1 right hand (i.e. Latin-1 accented letters and such)
- Some greek (but IIRC not enough to write in greek :P)

Also available in the Hersheys (but need to be encoded, probably... I don't know if GNU plotlib already contains codepoint for these...)
- Kana (hiragana and katakana)
- The most usual kanjis

Once integrated the japanese glyph, the repertoire is more or less the same of QCad unicode.cxf and (I think) AutoCAD bigfont. So we shouldn't be too ashamed of it :P

Potential Solutions:

As for adding the 'missing' characters (i.e. the rest of Unicode :P:P):
- Latin Extended-A is mostly done by composition (i.e. just adding diacritics or single strokes to letters)
- All the other stuff need to be drawn :((

Extended characters are readily available as TrueType (even as free font, like DejaVu) BUT TrueType is an a OUTLINE format (it describe the outline of the font and then FILLs it). What we use now is a STROKE font (describe the lines constituting the glyph and STROKE them).

The simple way is to simply stroke the outline: with a light enough body the border strokes simply 'fill' the interior (but, sadly, they could fill the eyes in letters like P and B). Some AutoCAD release just do this by default (you need to set the TEXTFILL variable, and then it becomes slow as an Apple II LOGO :D maybe they fixed it recently).

The real trouble with outline font is for Gerber and HPGL... HPGL fill model isn't really the same used by fonts (and anyway is an 'advanced' function). Gerber polygon fills are known to be buggy on some photoplotters. Postscript is not an issue since it can do the Right Thing, when given the right operators.

The other way to handle outline fonts is to rasterize them (maybe only during plotting?). Either feed the outline to the zone filler (or something similar), or just ask freetype for a B/W bitmap of the glyph, hinted and such at a resolution of one half of the line size. Then scan convert it to horizontal lines (it's trivial :D). I think that most PCB programs do it in this way. And in the same way bitmap logos could be handled. CONS: it is slow, like a zone fill :P

If wxWidgets is promoting itself as a general purpose graphics platform, *for drawing on screen*, then have we really already gotten to a full understanding of the wxFont usage problem? Is there a different way to use wxFont's within wxWidgets where fonts are scaled properly?

There are several forks in the road ahead, and each fork depends on which turns were made previously. The rasterization idea is an interesting one. In effect it takes a vector font through a bit map, and then back to a horizontal line vector array. The rasterization step could be isolated within one or more of the plotting usages.


Follow ups