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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
