Footprints made by Fped

Werner Almesberger werner at
Fri Jul 13 22:58:06 EDT 2012

Adam Wang wrote:
> About these footprints made by Fped, can be used in KiCad. So we collected
> footprints under KiCad Libraries, still some few footprints from else
> projects have not been added.

Great work ! A few comments:

- TO-252 component in to.fpd had a zero-width pad 2. This caused
  fped to emit incorrect Postscript and I wouldn't be surprised
  if KiCad could get confused, too.

  So I've made it an error (in fped) to have pads of zero width
  or height. I fixed to.fpd by simply deleting the table row for
  pad 2 (commit 359ccc048dbe6300aa4ef5aeb4853aa9421fe910). I hope
  that's correct.

- likewise, tssop5.fpd had a zero-width pad 5. Fixed in

- my meander-2450MHz.fpd also had a potential zero-sized "pad"
  in the form of the optional tail for tuning the antenna for
  different PCB thicknesses. Fixed in

- the distances between copper and outline in pads.fpd are a bit
  strange, particularly for the circular pads. How about
  introducing the distance as an explicit parameter and then
  calculating the radius as

  r = sqrt(x*x+y*y)/2+distance+w/2

  or, since x = y in this case, simply

  r = x/2+distance+w/2

- a lot of through-hole components only have a measurement on the
  hole but not on the ring. You may want to consider adding the
  ring diameter as well.

  Examples: RCA-3-RA (rca-3-ra.fpd), USB-A-DUAL-RECEPT-RA
  (usb-a-dual-recept-r.fpd), HE-1x2-100mil ... (he-2row-dip.fpd)

- in some of the c-t-smd.fpd components the measurements are very
  close to the pads, making them overlap in the catalog. Maybe
  "silk" (5 mil or 0.127 mm in this case) is a bit too tight a
  You could even consider expressing the distance in terms of
  Y-V1. But just a larger constant step size should do, too.

- in c-smt.fpd, the lines in "outline" and "outline_slope" don't
  always intersect at the same point. How about putting the two
  elements in the same frame, so that you can simply share the
  point ?

  Also, you work a bit too hard in the tables. You could simply
  have a table for a variable { d } { 1 } { -1 } and then
  multiply py with it, without having to duplicate px, x, y, and
  most of the formula of py.

- SOT-235 in sot.fpd: the overall width measurement intersected
  with the pads. I placed it at a constant distance from the pads.
  Commit 6ff4042bd2c480db411f41f7dd8c10c3cc3b6fc6

- eus.fpd (EUS): that's a terribly short name with a high risk of
  clashing. How about renaming it at least to TI-EUS or maybe
  R-PDSS-T6 (which seems to be synonymous) ?

- ir.fpd (TSOP348): very short name of the .fpd file. The
  footprint looks very cool, though :-)

- spacer.fpd: the ones with copper have solder paste on them.
  Are you sure you want this ? To get rid of the solder paste,
  change the pad type from "normal" to "bare".

I also made a few small changes:

- pads-array.fpd: didn't have measurements. I also enabled a few
  more pad types (all at a 100 mil spacing, up to 10 elements).
  Commit 71075ec7050b7f39d1124ff03cfa62a35e67553c

- header.fpd: added measurement of overall length
  Commit 6216a97c22b8a563fc35a616e8c353456a418ba6

- dip.fpd: didn't have any measurements, shame on me !
  Commit: 563e5944e3d90c4b28613930558eb34f20040541

- meander-2450MHz.fpd: the measurements of the *-left-* variants
  are at weird places. This is a known bug. Fped's logic for
  picking the location of measurements isn't prepared for
  handling mirroring. Not sure if there's a good way to fix this.

Updated catalog - now with 317 footprints - is at

- Werner

More information about the discussion mailing list