Some additional reference from the pstoedit manpage:
[-ssp]
simulate sub paths. Several output formats don't support PostScript pathes containing sub pathes, i.e. pathes with inter?
mediate movetos. In the normal case, each subpath is treated as an independent path for such output formats. This can lead
to bad looking results. The most common case where this happens is if you use the -dt option and show some text with let?
ters like e, o, or b, i.e. letter that have a "hole". When the -ssp option is set, pstoedit tries to eliminate these prob?
lems. However, this option is CPU time intensive!
AVAILABLE FORMATS AND THEIR SPECIFIC OPTIONS
...
pcb - pcb format
See also: http://pcb.sourceforge.net and http://www.penguin.cz/~utx/pstoedit-pcb/
[-grid missing arg name]
attempt to snap relevant output to grid (mils) and put failed objects to a different layer
[-snapdist missing arg name]
grid snap distance ratio (0 < snapdist <= 0.5, default 0.1)
[-tshiftx missing arg name]
additional x shift measured in target units (mils)
[-tshifty missing arg name]
additional y shift measured in target units (mils)
[-grid missing arg name]
attempt to snap relevant output to grid (mils) and put failed objects to a different layer
[-mm]
Switch to metric units (mm)
[-stdnames]
use standard layer names instead of descriptive names
pcbfill - pcb format with fills
See also: http://pcb.sourceforge.net
No driver specific options
Looking at my bash history, I recently had to use both of these options to get an OSHW logo with text to render properly: (I think the letters had some holes incorrectly filled until I added -ssp)
pstoedit -f pcbfill oshw-logo-200.pdf oshw-logo-200.pcb -ssp
Btw. It is strange for me that guys from gEDA didn't add this feature by default, and we need to make this fancy operations to put image into our boards...
Such is the unfortunate nature of niche open source software. You say "fancy operations" and I don't disagree, but it could also be called "there's already a way to do that and it gets the job done". The software developers (who are actually EEs in this case) have more satisfying things to (like designing boards) do than polish up their tools which are presently getting the job done for them as-is. An unfortunate consequence of this is that you almost have to be one of the developers in order to use the tools. That is, you pretty much have to be an EE and a linux software hacker to get the most out of the gEDA suite at present. Fortunately however, I think we can expect to see hoards of just such individuals flocking to join us in the near future thanks to the attractive forces of projects like Arduino and the maker movement in general. Bigger numbers is all we need. Currently, the number of people familiar with the gEDA codebases could probably all fit inside Dave's old lab, never mind those among them who are actually working on it with any regularity.