On 10/13/2013 04:49 AM, Dick Hollenbeck wrote: > http://timeguy.com/cradek/truetype > > Is this anything? > On Oct 13, 2013 2:25 AM, "Lorenzo Marcantonio" <[email protected]> > wrote: > >> On Sun, Oct 13, 2013 at 04:28:58AM -0000, Daniel Santos wrote: >>> >From a cursory examination of the Gerber spec (which I've never worked >>> with before). It looks like the appropriate way to render an arbitrary >>> font from it's vector representation is to render each non-contiguous >>> shape of each glyph as a single contour (enable region mode with G36, >>> draw the contour and then end the region mode with G37). Now this is >>> tricky for many reasons.
This is the hard part and what I was eluding to in the previous conversation. I've never used the FreeType library but looking at the API it looks like it provides a way to convert any font type it supports to strokes as Lorenzo pointed out. The difficult part is accurately converting this output into the gerber or any other file format for that matter. Obviously it can be done. Other applications do it all the time. However, this will require a lot of testing and visual comparison which is always fraught errors. Over the years I've seen some very expensive board layout software do a very poor job of rendering fonts to gerbers. If we want to provide this for our users, I want make sure we do it properly. At least the current line drawn fonts are accurate which IMHO is more important when manufacturing PCBs than inaccurate fancy TT fonts. >> >> The recommended way to render arbitrary images/fonts in gerber (and >> AFAIK the approach used by every CAD supporting truetype fonts in >> gerber) is using horizontal rasters. Usually the raster pitch is wide as >> the aperture or maybe half of it for better edge quality; also the >> raster approach actually follows the mechanics of the silkscreen process >> (which *is* done on a raster of wires...) >> >> I did a proof-of-concept demo some year ago (about when we switched from >> the 'squared' font) but the idea wasn't pursued for lack of interest >> (and display performance reasons, too). Maybe with the forthcoming OpenGL rendering, the performance issues will be less of an issue. Of course, this means you would have to modify both the GAL and the wxDC renderer to support FreeType fonts until all of the KiCad rendering has been ported over to the OpenGL GAL. >> >> Another reason is that the plotting infrastructure need to implement >> text in postscript/PDF too and that is even more tricky than gerber. Yes. All of the output formats that KiCad supports would have to be modified to support the new fonts as well. Now we have a more accurate view of how large the task really is and there are probably some other parts of KiCad this will effect (file formats?) that we haven't even considered. I am all for high quality fonts for KiCad but I am opposed to a partial implementation for obvious reasons. I am not trying to discourage anyone and I think it is a great idea. I am only trying to make sure anyone who takes on this task understands what's involved. >> >> -- >> Lorenzo Marcantonio >> Logos Srl >> >> -- >> You received this bug notification because you are a member of KiCad Bug >> Squad, which is subscribed to KiCad. >> https://bugs.launchpad.net/bugs/668145 >> >> Title: >> Font preferences not available anymore, internal font changed >> >> To manage notifications about this bug go to: >> https://bugs.launchpad.net/kicad/+bug/668145/+subscriptions >> > -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/668145 Title: Font preferences not available anymore, internal font changed To manage notifications about this bug go to: https://bugs.launchpad.net/kicad/+bug/668145/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
