I've committed Levente's patch for the PNG hid, and a slightly modified version of Ineiev's for the gerber HID.
grep revealed no other cases jumping out to worry about (at least none testing the width for == 1 or any other inequality). I do wonder if nelma might be doing the "wrong" thing by not ignoring thin-draw lines around things like holes though. (Its brush creation code is slightly different to the png HID, so it doesn't look like it should crash - although I've not tested that explicitly). On Fri, 2009-03-06 at 12:30 -0500, DJ Delorie wrote: > Two thoughts: Both good ideas: > In the case of holes, I'd mentioned before that we should add a "draw > pin" hook that passes the whole Pin structure, rather than > interpreting it, for HIDs that want more control over how pins/vias > are drawn (example: gerber wants to flash them, not draw them). That > would bypass this problem as the gerber hid could do the right thing > on its own. I guess this could be done similarly to how I've added the hooks for drawing (and thin-drawing) polygons by passing raw PCB data. I suspect we need a more savoury way to allow the HIDs to include the PCB data-types. I wasn't particularly happy with moving the typedef of the PolygonType arbitrarily. It might just be my unfamiliarity, but PCB does seem to lack a coherent policy on what header files get included from where. (The #ifndef guards seem like they must get used a bit!). I don't expect my changes to introduce the "fill_pcb_polygon" hook made things any better (sorry!). > We could add a "supports thin-draw" flag to the HID flags definition. > Then we could move the thin-draw overrides out of the hid and into the > core (currently, some hids temporarly disable thindraw when they have > control). OTOH, I'd like to occasionally print a thin-drawn board to > paper, too. I guess the HID could toggle its acceptance of that flag at run-time. (As an override to force thin-draw off if the user requests it). In other cases, the current user setting for thin-draw would just be used. Btw.. I like the idea of having finer grained control over thin-draw. It was handy for polygons separately already, and I've found that a combination of outline drawing and transparent fill is quite productive (if slower than a plain fill). KiCad actually lets you control thindraw (sketch mode) separately for lines, pads and polygons. Their thin-draw lines are not quite like our centre lines.. they are a full outlines with arc caps, which looks quite appealing. The possibility of both is nice. For the GL stuff, eventually we might like the following: Drawing "modes" / options per object type. Perhaps we provide some pre-defined default styles. Each should be adjustable: Outline hair draw (on / off, colour, opacity) Solid fill (on / off, colour, opacity) Centreline hair draw (on / off, colour, opacity) Object manipulatable? (on / off) If you could think of the use-case / desired visual effect, you could also fiddle with the compositing modes (perhaps XOR, for example), and perhaps adjust the way masking / sub-compositing works (both of which might require defining / configuring, their draw-order). This brings hiding / showing certain objects to a special case of adjusting their drawing style. Presumably we'd still modulate object manipulability when toggling to invisible drawing styles, or perhaps certain thin-draw modes. (E.g. how we treat thin-draw polygons). Somewhat on this topic.. Our visibility groups allow toggling of pins / pads, and vias separately. Since Vias are presently all-layer constructs, as are pins, it makes more sense to group those two. Pads are surface layers only, and when editing a middle layer of a multi-layer board, you might often want to switch of pads, but _not_ pins. I'm minded to re-group the visibilities as "Pin/Via" and "Pads". Alternatively we could make all three separate, but it does mean more vertical space used in the layer stack list. For GL (which can do opacity quite easily), some kind of (optional) automatic fading (or just toggling) of surface features like pads might be useful, based on the active layer being worked on. Best regards, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
