Mailing list archives : pcb-rnd

Date:Fri, 18 Nov 2022 09:17:41 +0100 (CET)
Subject:[pcb-rnd] new in librnd4: more flexible drawing area handling
Hi all,
one of the long standing bugs/misfeatures we inherited from PCB was the 
way the drawing area ("board size") was handled. 
I started to relax this earlier in pcb-rnd, for example we stopped trying 
to enforce drawing within the drawing area and made it more of a hint than 
a constraint. Later on half of the code moved out to librnd, so librnd 
inherited the limitations too.
The last remainin limitation was significant: while you could set its 
size, you couldn't set its origin, it always started at 0;0. For pcb-rnd 
this was not a big deal, but it was a real problem in sch-rnd and 
Now, after a bit more than net 9 hours of coding, I have good news on 
1. in librnd
I've changed the API so that the drawing area is not defined by width and 
height, but a bounding box. This means two pairs of coordinates for 
opposing corners. In other words, the origin corner doesn't have to be 
0;0, it can be any number, negative or positive.
I've upgraded all the generic exporters (svg, ps, eps, png) to export non 
0;0 origin drawings properly.
I've upgraded all our HIDs to display/scroll/pan/zoom non 0;0 origin 
drawings properly.
2. camv-rnd
The most important upgrade is in camv-rnd: some EDA tools export 
gerbers/excellons with all-negative coords. Before this upgrade, camv-rnd 
could display them but you couldn't really pan and zoom freely because the 
GUI tried to enforce the 0;0 corner constraints.
This is all fixed now, you don't even see where 0;0 on the render (only on 
the top right numeric coord readout).
3. sch-rnd
The main reason for librnd4 was the new requirements arisen during sch-rnd 
development. Compared to pcb-rnd where we manually set drawing area size 
(not because we want to, but because of historical reasons...), in sch-rnd 
I always planned to deal with this more freely. 
With this upgrade, when you draw outside of the drawing area, the drawing 
area is automatically adjusted. 
At the end, in sch-rnd, the drawing area is literally nothing else but the 
area with brigther background and grid. Especially that we have no 1:1 
unit for export but we just "fit page".
4. pcb-rnd
Funnily pcb-rnd code took the most time to switch over (because of the 
huge amount of internal dependency on the "board size" concept that got 
changed to "drawing area size" earlier), while it causes the least amount 
of changes in pcb-rnd at the moment.
For now, pcb-rnd will continue to emulate the 0;0 limitation. While I was 
upgrading the code for the new API, I tried to implement the upgrades to 
be able to deal with non-zero top-left corner, so later on it probably 
won't be very hard to lose this limitation.
The reason I don't relax it now is backward compatibility: the file format 
can't express non-zero top-left corner. But even if it could, if you used 
it with the new version of pcb-rnd and saved the board with the most 
recent lihata board format, an earlier pcb-rnd couldn't deal with it.
The way forward here is simple. I've added a TODO entry for extending the 
file format in the next format version, which won't happen too soon. Once 
it's done, I will relax the 0;0 restriction and you will be able to grow 
your board in whatever direction, but the IO code will throw compatibility 
errors (and will suggest to use the autocrop() action) when you try to 
save the board in any file format that assumes 0;0.
5. new librnd apps
I plan to write some more librnd based apps in the future; those won't be 
affected by the old 0;0 limitation in any way because I've got rid of 
the width/height model in librnd API and we only have the bbox based 
model, which is generic. So new apps will meet the generic API and unless 
they implement extra code to restrict the drawing's bbox, it is 
Best regards,

Reply subtree:
5880 [pcb-rnd] new in librnd4: more flexible drawing area handling from