Nice patch series. I'll push those into the main repository if you're asserting that they are tested, and don't cause any regressions in hatching output. I had a few issues though - which you could fix, or I could fix as I applied them:
BTW.. there is no great need to add things like: + g_return_if_fail(toplevel != NULL); + g_return_if_fail(fp != NULL); To the various functions called internally within libgeda. I'm not so against it that I'd take it out, but it would be nice to define somewhere, just where we're adding these tests, and which code-paths assume the input is sensible. This function is called from inside libgeda only IIRC, so we should take its input as not needing testing. APIs called from outside libgeda "might" need a little more validation. Seems there is an unrelated change here. Was this the old behaviour? + /* Avoid printing line widths too small */ + if (fill_width <= 1) fill_width = 2; If not, please don't change it - certainly not in an unrelated patch. Postscript / PDF will special case "0" as meaning "minimum representable line width, and that's why gEDA allows "0" specified as a line-width. If we're going to change the line-width behaviour, that needs to be a separate patch. (But I'd suggest not changing it). If I applied the patches (baring the line-width change), I'd probably merge the first two together - does that seem sensible? If you want to be able to log the progression between one and the other in the code-base, I'd also be OK with applying them separately, so long as they both compile and "basically" work. As I've mentioned before, I really like this refactor you're doing. A natural extension is to use this for rendering other objects in the GUI. Could we talk before you spend too much time writing that code though.. I'm hoping cairo is the way forward, so it would be good to coordinate on top of that. However.. keeing GDK (for now) is also on the table. If we do use this code to support the current GDK rendering, out of selfishness, I'd like to know what is happening with the code so it doesn't cause too much unexpected breakage against the cairo rendering branch. 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-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
