kicad-developers team mailing list archive

[Dick Hollenbeck <dick@...>]

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.


Dick