Homebrew, open source, repurposed, hacked, software defined, open hardware

Monday, 27 June 2016

Outline font to centreline defined font and SVG conversion for gEDA PCB

Donald Knuth spent around a decade crafting a solution to the problem of reproducing fonts on different systems with varying screen resolutions and printer resolutions, and came up with Metafont.

Metafont enables glyphs to be compactly defined with strokes with various brush sizes and shapes, and an output file produced containing the necessary information to render the glyph at the selected resolution as a bitmap, whether it be on screen, or on a printer.

Metafont is therefore a stroked font, and differs to outline fonts such as those described by truetype or postscript fonts, which define the outline of the glyph, and fill the central portions.

Metafont glyphs can be hard to describe in terms of outlines, and various people have ported Metafont defined fonts to Truetype and Postscript, with some difficulty, owing to the complexity of converting a path describing the movement of a pen's shape, into a path defining the envelope of its travel.

Outline defined fonts lend themselves well to rendering on screen at various scales, but are not as useful for plotters, engraving or pcb design, where the pen, cutting bit or silkscreen line has a finite minimum size.

So, for PCB design, the output file of choice is the Gerber file, which defines features as lines, polygons and flashed apertures. A font used for copper or silkscreen lines must use these design elements to reproduce the text. The Gerber file was originally created to work with photo-plotters, and it's feature set reflects this.

Accordingly, the choices available for depicting text on a PCB are a bitmapped raster, lines, or polygons, with any of these needing to be equal to or larger than the minimum silk screen line size that can be reliably reproduced, typically in the order of 6-10mil, where 1 "mil" is a thousandth of an inch, or 25.4 microns.

Tools for font design such as FontForge are eminently suited to outline defined font creation, but less suited to centreline defined font creation. The only vaguely useful suggestions to be found on the internet for this conversion were the use of CorelDraw's centreline filter/function; not exactly a FOSS solution.

The brief, then, was how to convert existing outline defined fonts, such as the open source CAD font:

  https://github.com/hikikomori82/osifont

to a stroked format suited to plotters, Gerbers, and engravers, and related devices such as the Eggbot.

Fonts such as the free, GPL CAD font osifont can be readily obtained in Truetype (ttf) format.

The first task was to convert this to a format easily parsed. It turns out that this can be done with the Apache Batik utility ttf2svg:

https://xmlgraphics.apache.org/batik/tools/font-converter.html

Custom code has been written to convert the SVG font file created by ttf2svg into line elements within footprints for gEDA PCB. This is an example of the Hebrew Aleph, Unicode x5d0, converted from Maxim Iorsh's GPL 2.0 Miriam-CLM font:

http://opensiddur.org/wp-content/uploads/2013/12/Miriam-CLM.png

Here is a direct conversion of the outline to a gEDA PCB footprint


This SVG path parsing code will also be added to translate2geda in due course, to allow custom board outlines and vector graphics to be turned into footprints. Each quadratic bezier is drawn with six lines, which seems to give pretty smooth results.

This particular font was chosen for experimentation since the limbs of the font are of fairly uniform thickness, and the font is sans serif, simplifying conversion to a stroked font.

It turns out that gEDA PCB is a convenient tool for viewing converted stroked font glyphs, as well as being a target for the converted fonts.

The utility can be used to suppress endcaps, serifs, fillets and small degenerate vertical lines, and here is the output for Aleph with these filters enabled:


If the above filters are combined with centreline generation, the following output results: 


The utility will automatically analyse a group of glyphs to establish the limb width, allowing the centreline to be generated accurately. The limb width can be specified manually, however, with a suitable command line flag. The utility also extracts the font ascent and descent values to automatically scale the output consistently for all glyphs processed in an SVG font file.

With some minor hand tweaking of the design elements in the output file, the following results:


At this stage, most of the work has been done by the utility to create a centreline defined glyph.

Some additional work is needed for the utility to automatically connect isolated limbs to other limbs, and censor the redundant lines automatically.

The next step will be to convert the footprint into a format suited to font use within gEDA PCB or the footprintTextForPCB utility, or as a set of vector paths.

The utility is still a work in progress, and can be found at:

https://github.com/erichVK5/outlineFont2centrelineFont

If this seems like a lot of work, font designers spend many hours slaving over FontForge and the like to create aesthetically pleasing fonts. This utility leverages this design work and allows conversion into centreline defined formats to be achieved quite quickly and accurately by comparison.

In closing, this approach would also work to automatically create a gerber/plotter compatible font from a truetype source without determining the centreline, by simply following the outlines with a suitable offset inwards and stroke width, but would make for a less compact glyph, and more bloated gerber or gcode, as each limb or loop of the glyph would include endcaps, and the two edges of any given limb or loop.

Tuesday, 3 May 2016

Adding images to the silkscreen in gEDA PCB

There are a few ways to add images to the silkscreen layer in gEDA PCB.

On method is to use potrace or Inkscape to create a postscript file, and then use pstoedit to generate PCB layout data to insert into a layout; this is well described at:

http://letsmakerobots.com/node/38709

and at:

http://www.leniwiec.org/en/2012/02/09/adding-images-into-pcb-layout-with-geda-pcb-app/

i.e.

using potrace to convert an image to eps:

potrace -o picture.eps -H .4 -W .5 picture.bmp

Or save a picture as eps from Inkscape...

Then use pstoedit to turn it into PCB layout data:

pstoedit -f pcbfill picture.eps picture.pcb -ssp


Another option is to turn an image into a footprint.

I have written a small utility to convert jpeg or png images into a gEDA PCB footprint which has dots in the silkscreen layer of the footprint.

The size of each dot is based on the luminosity of each corresponding pixel in the original image.

The utility can be found at:

https://github.com/erichVK5/image2footprint

It is assumed that the pixels will be white silkscreen dots on a dark background soldermask on the manufactured PCB.

Unwanted features or transparent layers should be coloured black with a graphics editor like the gimp before conversion with the utility.

An additional use is to convert a photograph of a PCB into a footprint. Use of a graphic editor like the GIMP in such a scenario can be used to increase the contrast between the tracks and surrounding fibreglass, and provide an image against which tracks can be laid in gEDA PCB to duplicate the original PCB. Manually highlighting pads with white dots in the image before conversion would also simplify snapping elements to the PCB features. Ensuring the source image is sized to match the original PCB, and that a suitable dot pitch is selected to ensure the footprint width and height equal the PCB's width or height should allow for relatively accurate and rapid duplication of an existing PCB from a photograph or scan.

A source image


The footprint in PCB:



A rendered gerber of the exported footprint:


Saturday, 30 April 2016

Importing or converting gerber files into gEDA PCB layouts

Being able to convert gerber files into pcb layouts can be useful for a couple of reasons, namely:

- acquiring exotic footprints
- modifying existing designs
- reverse engineering designs
- snatching previous design efforts from the jaws of obsolescent, closed EDA software products, forced upgrade paths, or cloud based services

Luckily, most of the hard work was done at the turn of the century by Philipp Knirsch, who wrote some gerber parsing code in java that can be used to render gerbers. Philipp licensed his gerber parsing code as GPL2:

http://www.wizards.de/phil/java/rs274x.html

The code was modified to play nicely with translate2geda as a conversion option, and now exports gEDA PCB elements in a footprint file.

The footprint file allows new tracks and pads to be snapped to the locations very easily, and since each feature in the footprint file is uniquely numbered, mouse over on the features allows the identifier to be determined, and using the unique identifiers, the element or elements can be copied from the footprint file with a text editor, for example, if a grouping of elements is needed to duplicate a footprint.

I may try to implement layout export with tracks and pads in different layers, but this will be complicated, since some EDA tools paint features such as pads, polygons and tracks, rather than flashing them, making it hard to determine which features are pads vs trackwork.

Only four sided polygons are supported currently, in order to identify rectangular pads which have not been flashed. This may be extended to capture octagonal pads, such as those supported by Eagle and gEDA PCB, and the gEDA PCB fork pcb-rnd.

Ground pour polygons and other complex polygons will not be supported, unless I implement the layout export option, since gEDA footprints do not support arbitrary polygons.

Here's a bottom copper layer gerber viewed in gerbv:


and here's the output from the translate2geda utility being viewed in gEDA PCB


To use the translate2geda utility to convert gerbers like this, you'll need to get yourself on over to github, get the java source and follow the build and use instructions.

I hope to implement Kicad export once the wrinkles have been ironed out and the translate2geda code refactored a bit.

The translate2geda utility will also convert manufacturer agnostic BXL files, Eagle XML libraries, BSDL (.bsd) files, IBIS (.ibs), symdef, LT-Spice and QUCS files into gEDA gschem and gEDA PCB compatible footprint and schematic symbols as well.

The KicadModuleToGEDA and KicadSymbolToGEDA  functionality will be merged into the translate2geda utility in due course, adding Kicad Symbol and Footprint conversion to gEDA gschem and PCB  formats as well.

Thursday, 3 March 2016

Converting IBIS, BXL, BSDL, symdef, Eagle, and Kicad design elements to gEDA

It's turning into something of a compulsion, but after writing the code for converting legacy and s-expression format Kicad footprints (modules) to gEDA PCB compatible footprints:

https://github.com/erichVK5/KicadModuleToGEDA

a converter for Kicad symbols, to convert them to gEDA gschem compatible symbols, seemed like the logical thing to do next:

https://github.com/erichVK5/KicadSymbolToGEDA/

With the basic software objects written, extending them with additional methods to support additional formats became easier and easier, and I have now put a working version of translate2geda on github:

https://github.com/erichVK5/translate2geda

It currently supports conversion of the following formats into symbols and footprints compatible with the FOSS gEDA EDA suite:

Eagle footprints (in XML .lbr files)
Eagle symbols (in XML .lbr files)
vendor neutral BXL files
BSDL files
IBIS files
symdef files

When time permits, I plan to incorporate the original Kicad module and symbol converter code into the now more modular translate2geda code. Until then, the individual converters can be used by those keen to convert Kicad design elements.

In addition, support for the upverter (.upv) open format is planned, and gerber -> footprint/layout is a work in progress.

Once things are behaving, I intend to implement export to Kicad as well. This should not be hard, since much of the code relies on Kicad flags and dimensions, around  which the original solution was designed.

With that done, export to Eagle is also planned, since they were nice enough to implement an open XML format.

FOSS EDA suites should ideally leverage each other's efforts, rather than reinventing the wheel, and being able to share symbols and footprints is an obvious way to do this.

Stretch goal:

schematic conversion

Here's a simple board intended for use in an eggbot designed in gEDA PCB, using an Arduino nano footprint, TO-220 footprint, electrolytic capacitor footprints, and a DIP16 Pololu footprint imported from Kicad modules.

The schematic used to design the circuit in gschem used symbols also imported from Kicad.

The board has deliberately been designed to be compact, since I aimed to fit it within a 5cm x 5cm layout, one of the sizes that gets preferential pricing with my usual PCB supplier, hackvana.com


Monday, 7 September 2015

Codec2 700B mode trellis decoding experiments and Reverend Thomas Bayes

The codec2 700B mode has been an improvement on the 700 mode, and employs vector quantisation (VQ) rather than scalar quantisation.

The characteristics of the 700B frames can be summarised as follows:

  bits_per_frame = 28;       % number of bits/frame for "700B" mode
  bit_fields = [1 5 3 6 6 6 1]; % number of bits in each field
  field_labels = ["voicing"; "logWo"; "energy"; "LSPmelVQ1"; "LSPmelVQ2"; "LSPmelVQ3"; "spare"];

which contrasts to the features of the 700 mode:

  bits_per_frame = 28;
  bit_fields = [1 5 3 3 2 4 3 3 2 2];
  field_labels = ["voicing"; "logWo"; "energy"; "LSP1"; "LSP2"; "LSP3"; "LSP4"; "LSP5"; "LSP6"; "spare"];

Naturally, trellis decoding seemed worth trying on 700B.

Here are the transition probability plots for the 700B bit fields, when the ve9qrp10s sample is processed.





It is interesting to note the quite striking difference in appearance between the very uniformly dispersed nature of the 700B VQ bit field transition probability mesh plots and the "peakier" 700 scalar LSP bit field mesh plots with more marked central tendencies ( see: codec2-700-mode-trellis-decoding )

This suggests that the VQ is doing a pretty good job of encoding information without much redundancy, which is likely to have implications for maximum likelihood decoding strategies. It is harder to derive a useful measure of the central tendency and then meaningfully apply it when the mesh plot looks like a square of uniformly cut lawn, as opposed to a nice mound in the middle of the lawn.

codec2's author, David Rowe, also discusses this issue of information redundancy in his blog.

It seems to be all about that hoary old chestnut that was first discussed in 1763 by the Reverend Thomas Bayes in "An Essay towards solving a Problem in the Doctrine of Chances". The posterior odds, i.e. our estimation of the most likely received codeword, can only be improved if we have useful information regarding the prior distribution of likely codewords. In the absence of useful information, we are left with a non-informative entropy maximizing distribution.



Here are some summary statistics from the first decoding runs:

Passing through bitfield 4 LSPmelVQ1 without trellis decoding
Passing through bitfield 5 LSPmelVQ2 without trellis decoding
Passing through bitfield 6 LSPmelVQ3 without trellis decoding
Passing through bitfield 7 spare     without trellis decoding
processing 700B mode parameter: 1, nbits: 1, label: voicing                         
Eb/No: 0.00 dB nerrors 25 13 BER: 0.10 0.05 std dev: 0.31 0.23
processing 700B mode parameter: 2, nbits: 5, label: logWo                           
Eb/No: 0.00 dB nerrors 121 82 BER: 0.10 0.07 std dev: 4.71 4.67
processing 700B mode parameter: 3, nbits: 3, label: energy                          
Eb/No: 0.00 dB nerrors 67 63 BER: 0.09 0.08 std dev: 1.20 1.32

And an attempt to trellis decode the VQ encoded bitfields (four hours of octave on a dedicated 64 bit 2.7GHz intel cpu):

Passing through bitfield 7 spare     without trellis decoding
processing 700B mode parameter: 1, nbits: 1, label: voicing                         
Eb/No: 0.00 dB nerrors 25 13 BER: 0.10 0.05 std dev: 0.31 0.23
processing 700B mode parameter: 2, nbits: 5, label: logWo                           
Eb/No: 0.00 dB nerrors 121 82 BER: 0.10 0.07 std dev: 4.71 4.67
processing 700B mode parameter: 3, nbits: 3, label: energy                          
Eb/No: 0.00 dB nerrors 67 63 BER: 0.09 0.08 std dev: 1.20 1.32
processing 700B mode parameter: 4, nbits: 6, label: LSPmelVQ1                       
Eb/No: 0.00 dB nerrors 246 115 BER: 0.17 0.08 std dev: 15.57 10.97
processing 700B mode parameter: 5, nbits: 6, label: LSPmelVQ2                       
Eb/No: 0.00 dB nerrors 277 115 BER: 0.19 0.08 std dev: 15.42 10.80
processing 700B mode parameter: 6, nbits: 6, label: LSPmelVQ3
Eb/No: 0.00 dB nerrors 285 114 BER: 0.19 0.08 std dev: 14.55 10.52

Judging by the large increases in errors from our attempt to apply maximum likelihood decoding to the VQ bit fields, it seems reasonable to conclude that the VQ encoded bit fields are doing an excellent job of conveying a lot of information with minimal redundancy. Unfortunately for us, this would suggest that we can't profitably employ maximum likelihood decoding for the VQ bit fields directly.

While experimenting, we have also seen that Reverend Bayes' insights are quite relevant to low bit rate audio codec R&D some 250 years later!

Here are some .wav files of the trellis decoded ve9qrp_10s sample which has had additive gaussian white noise added after 700B encoding, in keeping with the method used for the other codec2 mode trellis decoding experiments....

No bit fields trellis decoded:
ve9qrp_10s_700B_0.50_simple_700B.wav

Bit field 1 trellis decoded:

ve9qrp_10s_700B_0.50_trellis_700B_dec1.wav

Bit field 2 trellis decoded:
ve9qrp_10s_700B_0.50_trellis_700B_dec2.wav

Bit field 3 trellis decoded:
ve9qrp_10s_700B_0.50_trellis_700B_dec3.wav

Bit fields 1,2 trellis decoded:

ve9qrp_10s_700B_0.50_trellis_700B_dec12.wav

Bit fields 1,3 trellis decoded:
ve9qrp_10s_700B_0.50_trellis_700B_dec13.wav


Bit fields 2,3 trellis decoded:

ve9qrp_10s_700B_0.50_trellis_700B_dec23.wav


Bit fields 1,2,3 trellis decoded:
ve9qrp_10s_700B_0.50_trellis_700B_dec123.wav


Bit fields 1,2,3,4,5,6 trellis decoded
ve9qrp_10s_700B_0.50_trellis_700B_dec123456.wav


Bit field 4 trellis decoded:
ve9qrp_10s_700B_0.50_trellis_700B_dec4.wav

Bit field 5 trellis decoded:

ve9qrp_10s_700B_0.50_trellis_700B_dec5.wav


Bit field 6 trellis decoded:
ve9qrp_10s_700B_0.50_trellis_700B_dec6.wav


The intelligibility of the samples with bit fields 4, 5, or 6 decoded are not improved, as would be expected based on the very uniform distribution of the encoded VQ values evident in the transition probability plots, and also from the significantly increased number of bit errors and  standard deviation seen in the summary statistics.

From the above samples, it is clear that bit fields 1,2 and 3, either singly or in combination, benefit from direct trellis decoding, but the VQ bit fields would require decoding before attempting trellis decoding of their encoded information.


Codec2 700 mode trellis decoding experiments

Further to the codec2 1600 bit/second mode experiments with trellis decoding, the octave script has been modified further with a view to allowing any mode of interest to be specified.

As part of this refactoring and testing of the modified octave script, the 700 mode has been put through the script, with a combination of trellis decoded and passed through bit fields.

Here are the transition probability mesh plots for all of the bit fields showing the likelihoods (in Z axis height) of a given bitfield transitioning from a given value (X-axis) to a corresponding value on the Y axis. These plots were generated with the ve9qrp10s sample which was also used for the 1600 mode trellis decoding experiments.

The voicing bit field appears to be the least impressive in terms of predictability, and this bitfield may not lend itself to trellis decoding without excess errors being introduced.











Here are the summary statistics for the bitfields following the addition of additive Gaussian white noise (AGWN) and then trellis decoding.

Passing through bitfield 10 spare   without trellis decoding
processing 700A mode parameter: 1, nbits: 1, label: voicing                       
Eb/No: 0.00 dB nerrors 23 17 BER: 0.09 0.07 std dev: 0.30 0.26
processing 700A mode parameter: 2, nbits: 5, label: logWo                         
Eb/No: 0.00 dB nerrors 121 85 BER: 0.10 0.07 std dev: 4.95 4.83
processing 700A mode parameter: 3, nbits: 3, label: energy                        
Eb/No: 0.00 dB nerrors 63 65 BER: 0.08 0.09 std dev: 1.28 1.31
processing 700A mode parameter: 4, nbits: 3, label: LSP1                          
Eb/No: 0.00 dB nerrors 64 55 BER: 0.09 0.07 std dev: 1.06 1.29
processing 700A mode parameter: 5, nbits: 2, label: LSP2                          
Eb/No: 0.00 dB nerrors 47 50 BER: 0.09 0.10 std dev: 0.63 0.71
processing 700A mode parameter: 6, nbits: 4, label: LSP3                          
Eb/No: 0.00 dB nerrors 63 66 BER: 0.06 0.07 std dev: 1.83 2.41
processing 700A mode parameter: 7, nbits: 3, label: LSP4                          
Eb/No: 0.00 dB nerrors 78 61 BER: 0.10 0.08 std dev: 1.30 1.25
processing 700A mode parameter: 8, nbits: 3, label: LSP5                          
Eb/No: 0.00 dB nerrors 42 64 BER: 0.06 0.09 std dev: 0.87 1.31
processing 700A mode parameter: 9, nbits: 2, label: LSP6                          
Eb/No: 0.00 dB nerrors 32 42 BER: 0.06 0.08 std dev: 0.49 0.66

And another run:

Passing through bitfield 1 voicing without trellis decoding
Passing through bitfield 10 spare   without trellis decoding
processing 700A mode parameter: 2, nbits: 5, label: logWo                         
Eb/No: 0.00 dB nerrors 140 103 BER: 0.11 0.08 std dev: 5.20 5.28
processing 700A mode parameter: 3, nbits: 3, label: energy                        
Eb/No: 0.00 dB nerrors 60 55 BER: 0.08 0.07 std dev: 1.08 1.21
processing 700A mode parameter: 4, nbits: 3, label: LSP1                          
Eb/No: 0.00 dB nerrors 70 61 BER: 0.09 0.08 std dev: 1.21 1.36
processing 700A mode parameter: 5, nbits: 2, label: LSP2                          
Eb/No: 0.00 dB nerrors 34 33 BER: 0.07 0.07 std dev: 0.53 0.53
processing 700A mode parameter: 6, nbits: 4, label: LSP3                          
Eb/No: 0.00 dB nerrors 72 71 BER: 0.07 0.07 std dev: 1.85 2.63
processing 700A mode parameter: 7, nbits: 3, label: LSP4                          
Eb/No: 0.00 dB nerrors 58 50 BER: 0.08 0.07 std dev: 1.23 1.17
processing 700A mode parameter: 8, nbits: 3, label: LSP5                          
Eb/No: 0.00 dB nerrors 42 63 BER: 0.06 0.08 std dev: 0.85 1.21
processing 700A mode parameter: 9, nbits: 2, label: LSP6                          
Eb/No: 0.00 dB nerrors 34 37 BER: 0.07 0.07 std dev: 0.57 0.59

And another run:

Passing through bitfield 1 voicing without trellis decoding
Passing through bitfield 2 logWo   without trellis decoding
Passing through bitfield 10 spare   without trellis decoding
processing 700A mode parameter: 3, nbits: 3, label: energy                        
Eb/No: 0.00 dB nerrors 44 53 BER: 0.06 0.07 std dev: 1.07 1.15
processing 700A mode parameter: 4, nbits: 3, label: LSP1                          
Eb/No: 0.00 dB nerrors 80 65 BER: 0.11 0.09 std dev: 1.17 1.31
processing 700A mode parameter: 5, nbits: 2, label: LSP2                          
Eb/No: 0.00 dB nerrors 32 39 BER: 0.06 0.08 std dev: 0.53 0.62
processing 700A mode parameter: 6, nbits: 4, label: LSP3                          
Eb/No: 0.00 dB nerrors 69 70 BER: 0.07 0.07 std dev: 1.68 2.51
processing 700A mode parameter: 7, nbits: 3, label: LSP4                          
Eb/No: 0.00 dB nerrors 69 61 BER: 0.09 0.08 std dev: 1.27 1.25
processing 700A mode parameter: 8, nbits: 3, label: LSP5                          
Eb/No: 0.00 dB nerrors 38 65 BER: 0.05 0.09 std dev: 0.85 1.27
processing 700A mode parameter: 9, nbits: 2, label: LSP6                          
Eb/No: 0.00 dB nerrors 27 35 BER: 0.05 0.07 std dev: 0.49 0.58

After all of that, here is what the ve9qrp_10s_700A.bit sample sounds like with simple decoding after the addition of the AWGN:

ve9qrp_10s_700A_0.50_simple_700A.wav

Here is what the ve9qrp_10s_700A.bit sample sounds like with trellis decoding of all bit fields except for the  spare bit field (10) after the addition of the AWGN:

ve9qrp_10s_700A_0.50_trellis_700A_dec123456789.wav

Here is what the ve9qrp_10s_700A.bit sample sounds like with trellis decoding of bit fields 2-9, skipping the voicing (1) and the spare (10) bit fields after the addition of the AWGN:

ve9qrp_10s_700A_0.50_trellis_700A_dec23456789.wav

Here is what the ve9qrp_10s_700A.bit sample sounds like with trellis decoding of bit fields 3-9, skipping the voicing (1), logW0 (2) and the spare (10) bit fields after the addition of the AWGN:

ve9qrp_10s_700A_0.50_trellis_700A_dec3456789.wav

Having confirmed that the modified script still works with the codec2 700 mode, the next step is to support the 700B and 1300 bit/second modes.

In closing, all of this experimentation serves to highlight that black box vocoders subject to intellectual property protection being marketed by commercial equipment vendors do not allow this sort of experimentation by interested amateurs.

Sunday, 6 September 2015

gEDA PCB footprint text utility

When creating footprints in gEDA, the addition text elements other than the overlaid refdes is not supported.

Here is a command line java utility that allows text to be generated as an element which can then be loaded and added to a gEDA PCB footprint or layout.

https://github.com/erichVK5/FootprintTextForPCB

Without a utility of this nature, those making footprints and seeking to add text have to hand draw the desired text.

v1.1 of the utility uses the free Hershey Sans 1 Stroke Font and outputs 0.01mil (imperial, square bracketed) units.

This builds on the previous font work discussed previously:

geda-pcb-font-utilities-and-options

I plan to incorporate this utility into the Kicad to PCB footprint importer utility,

https://github.com/erichVK5/KicadModuleToGEDA

to allow text defined in Kicad modules to be rendered when converting to gEDA PCB format.

I may also add support for other ported fonts in due course.

Hints for usage:

Step 1)

decide on the text (or texts) needed in the footprint being designed

Step 2)

generate each needed bit of text as a footprint with this utility, i.e.
 
java FootprintTextForPCB -t "You Shouldn't Have Unsoldered This" -m 1.3

which will generate a footprint file
 
You_Shouldn_t_Have_Unsoldered_This.fp

that will contain the text. It will recognise spaces and any of the usual ASCII characters that PCB can ordinarily display as text, but, you will need to escape characters that the shell might take exception to, and the escape character may end up getting rendered in the footprint text, until such time as I support escape characters a bit better.

Step 3)

When generating the new footprint in PCB, use

"File:Load Element To Buffer"

to load the newly generated footprint onto the layout.
Place the text in a suitable position. If it is the wrong size, go back and play with the magnification ratio option.

Step 4)

Select the text by clicking on it.

CTRL-x to cut the text to buffer

Go to "Buffer:Break Element To Pieces" to convert the text footprint into silk line primitives, and click to place the broken up element where it is needed.

Hit "Esc" to deselect.

Step 5)

Proceed now, as you normally would, to convert your collection of elements (which now include the silk lines showing the text) making up your footprint in its entirety into a footprint.

Usage:
 
java FootprintTextForPCB -t "my Text For Conversion To Silkscreen Stroke Elements" -m X.XXXX

"my Text For Conversion To Silkscreen Stroke Elements" is ASCII text, which can include spaces,
and X.XXXX is an optional magnification ratio; default = 1.0)

If run without any command line arguments, a demonstration footprint file
called demonstration1234567890.fp, will be generated

Installation:

1) install a java compiler and java virtual machine (JVM) using your preferred package management system/source, if it isn't already installed.

2) clone the FootprintTextForPCB git repository. Failing that, download the java source file and put it in a suitable directory with the same subdirectories and contents.

3) in the FootprintTextForPCB directory, type:

user@box:~$ javac FootprintTextForPCB.java

and that should be it, you are now ready to use the FootprintTextForPCB utility.