← Back to team overview

kicad-developers team mailing list archive

Re: Re: Vector fonts


Vesa Solonen wrote:
Wayne, have you had time to research wxGC and if so what would you say about it? I mean to draw attention that wxDC API may get depreciated by more vector oriented design. Also could wxGraphicsPath be of value to allow object caching?

wxGC is only a different face on top of wxGraphicsContext. And when I looked at it a year ago, that face was getting in the way of the real work horse, wxGraphicsContext.

They are not distinctly different code paths. wxGC uses a wxGraphicsContext underneath, but tries to look like a wxDC, and in doing so, sometimes shields you from what you need.

I agree that the critical design point is the path to gerbers. And Jean-Pierre raised the concern that wxFonts may not appear to be the same across systems. I think we would have to determine if using the *exact same* underlying font would appear to be the same across systems.
If so, then
we can provide one or two with Kicad. Additionally, we can add support into the
board file to identify a font file exactly, by name and checksum for
example. We could offer a font registry on the internet, where those
fonts and checksums are shareable for the international requirements,
in the case where the font was not included as part of the Kicad distribution.

Regarding the exactness of the agreement between pcbnew on screen font support and what gets put into the gerber: I think this is doable on the fly. Let's see if this would work in theory, a rasterization algorithm. (The outline capture/bezier algorithm would be different, and harder IMO.) So here we are, about to plot to gerber: each character in use within a board file is uniquely identified by 1) glyph, 2) size, and 3) angle. You would have to rasterize every unique combination of character(size, angle), by drawing it into a bitmap. The bit map width and height would have to be determined to exactly match the width used on screen. This establishes the inter character spacing. Then that bit map could be scanned row by row horizontally, and each row gets translated into G or D code line or lines. The coordinates of those lines would have to be relative to some "angled glyph" anchor point, say the lower left corner. One of the harder steps is to find the anchor point in the gerber file when handling angled text. You have to traverse an angled line, by the width of each succeeding character.

But it seems doable. A beneficial fallout from some of this is an easy path to support bitmap logos.


Follow ups