kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Fri, May 03, 2013 at 10:27:12AM -0500, Adam Wolf wrote:
> Because the call that opens the file doesn't know anything about what layer
> you're on, there's no way for the PLOT CONTROLLER to honor your "Use Gerber
> Extension" option.  Because there's logic in the dialog box, PLOT

That's by design. You can plot *more* than one layer on a plot, so you
can't tell what layer are you on (for example I do a layout pdf with
both silks, masks, pastes, pcb edges *and* the sheet border: what would
be the layer for this plot?); however an entry point for computing the
'usual' file names could be useful: it should be already *somewhere*
(GetGerberExtension, which is static), need to be more accessible from
the plotcontroller maybe. Also for some people both the default layer
filenames and the 'gerber extension' (which are somewhat arbitrary since
every cad use its set) are not the right ones. Example: our express
fabricator wants the board cuts with extension .gko, drills with
extension .dri (instead of drill) and drill reports with extension .tol
(in fact they want a slightly different format for the drill report).
And the file name must be the 'item code' (they assign it).  In other
words the 'gerber extension' feature (while useful) is arbitrary and
definitely not universal.

You have python (which is turing-complete) so you can compute correctly
whatever name you need. Exporting the function to build the name however
is a good idea (GetGerberExtension, and BuildPlotFileName essentially).
However there could be a better python (system) routine for handling
filenames than the last one (scripting languages tend to be rich in
pathname handling).

> If we have part of the API take in open file-like objects, then we get a
> bunch of fun things on the Python side.  We can pass in StringIO, so we
> could generate these files and squirt them out a socket without a temp file
> on disk.  We could write directly into a compressed file, or any number of
> other things.
> 
> Thoughts?

File-like objects are not enough, sorry... plotting is not always like
writing a sequential file.

Can't do that for PDFs, since they are processed in multiple steps and
need random access (I don't remember if the compression is done in core
now or still need a temporary file).

Can't do that for gerbers either since you need to declare apertures at
the beginning (so the file is rewind and rewrote with the aperture table
during plot close).

Also, can you bind these 'objects' to FILE* or something like that without
breaking pcbnew? (some wxStreamStuff, maybe...)

Remember that for now python is an optional feature, not a requirement.

So: for filenames 'tools' could be added for aiding in generating the
'correct' one; the completed plot file is ready *only* when the plot is
closed, so no pipelining for you, sorry. In fact you could even redesign the
interface to take the file name at close time, for some plotters..

With a huge work everything could be changed to build the file in core
and then write/return it as string, but does it really matters? Often the
/tmp storage is in ramdisk anyway and these file should fit completely
in the filesystem cache, so I don't think that using a scratch file
would be so bad. You could even mmap it at the end (is this worth the
trouble?)

One last thing. Are you really worried about performance of the board
plotter? It's not one of the thing you use every second....

-- 
Lorenzo Marcantonio
Logos Srl