[Gerbv-devel] libgerbv Qt realization

[Александр Курганов]

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev

[Sergey Alyoshin]

Hello.
I am working on a project which is about using QPainter from Qt rather than
cairo in libgerbv for vector graphics.
The project is incomplete and I would need some help, obviously; I would
like to ask you to put a link to the project on gitHub on the gerbv web
page, so people would know that such a thing exists and that they can help.
I know that there is a cairo experimental feature "Qt surface", but this is
an experimental feature and today it doesn't seem even to compile right.
Besides, a straight QPainter realization may be more stable.
https://github.com/sx107/gerbvQt

Added in "Other Gerber software" at http://gerbv.geda-project.org/

[Joerg Wunsch]

I'm currently thinking of what would be needed to make gerbv
a full-featured panelization tool.

I think we've already got much:

. a good Gerber and Excellon parser (better than many other parsers)
. the option to translate, mirror or rotate layers
. the option to write the output file back
. a GUI giving the user an idea about what's going on

I think the next feature that would be needed for panelization is
an option to merge two layers. I'm trying to find my way through
gerbv_image_t. Is there a bit more of explanation beyond the few
comments in gerbv.h?

My current guess, after digging through an image read from a RS274X
file is about that:

. obviously, make sure both images have the same layertype

. apertures need to be merged
Well, for a start, I guess it's ok to not optimize, and just
start at APERTURE_MAX/2 for the merged-in image, but later on,
apertures should be optimized; a temporary translation table will
result

. layers
What about multiple layers, just append them? Where are they
referenced?

. states, amacro
I have no idea about these. Just concatenate the lists?

. info
Calculate new max bounds?

. netlist
Concatenate the lists, rewriting the aperture number according to
the translation table from above.

. gerbv_stats, drill_stats
Just add both.


Well, I see there is already a function merge_images() in callbacks.c.
I don't think it follows the idea I have in mind though, but maybe
both ideas could be combined?

Would appreciate any feedback.

[Sergey Alyoshin]

Post by Joerg Wunsch
I'm currently thinking of what would be needed to make gerbv
a full-featured panelization tool.
. a good Gerber and Excellon parser (better than many other parsers)
. the option to translate, mirror or rotate layers
. the option to write the output file back
. a GUI giving the user an idea about what's going on
I think the next feature that would be needed for panelization is
an option to merge two layers. I'm trying to find my way through
gerbv_image_t. Is there a bit more of explanation beyond the few
comments in gerbv.h?
My current guess, after digging through an image read from a RS274X
. obviously, make sure both images have the same layertype
. apertures need to be merged
Well, for a start, I guess it's ok to not optimize, and just
start at APERTURE_MAX/2 for the merged-in image, but later on,
apertures should be optimized; a temporary translation table will
result
. layers
What about multiple layers, just append them? Where are they
referenced?
. states, amacro
I have no idea about these. Just concatenate the lists?
. info
Calculate new max bounds?
. netlist
Concatenate the lists, rewriting the aperture number according to
the translation table from above.
. gerbv_stats, drill_stats
Just add both.
Well, I see there is already a function merge_images() in callbacks.c.
I don't think it follows the idea I have in mind though, but maybe
both ideas could be combined?
Would appreciate any feedback.

I have done panelization with "RS-274X Merge (Gerber)..." which use
merge_images().

------------------------------------------------------------------------------

[Joerg Wunsch]

Post by Sergey Alyoshin
I have done panelization with "RS-274X Merge (Gerber)..." which use
merge_images().

Cool, now I can see it under "Exports" (didn't look there before),
and I think I'm getting an idea about how to use it.

спасибо большое!

[Joerg Wunsch]

Post by Sergey Alyoshin
I have done panelization with "RS-274X Merge (Gerber)..." which use
merge_images().

Works like a charm.

That raises the question about a new release with these fine new
features ... the previous one is now almost two years old.

[Joerg Wunsch]

Post by Sergey Alyoshin
I have done panelization with "RS-274X Merge (Gerber)..." which use
merge_images().

I have been using it now in order to produce a large panel.

It's indeed a very nice option, thank you!

I have one suggestion: when merging the copper layers, gerbv suddenly
told me about being unable to rotate rectangular and oval shapes,
claiming the rotation angle would be non-multiple of 90 degrees (which
is basically impossible here).

This is due to the comparison of the double value trans->rotation
against absolute numbers. Such comparison is valid for absolute
0.0 (which always has a well-defined binary represantation), but
it's error-prone for values like M_PI etc.

The following patch makes it work as intended:

diff --git a/src/gerb_image.c b/src/gerb_image.c
index 257f055..1436702 100644
--- a/src/gerb_image.c
+++ b/src/gerb_image.c
@@ -590,20 +590,16 @@ gerbv_image_copy_all_nets (gerbv_image_t *sourceImage,
case GERBV_APTYPE_OVAL:
if (trans->scaleX == trans->scaleY
&& trans->scaleX == 1.0
- && (fabs(trans->rotation) == M_PI
- || fabs(trans->rotation) == DEG2RAD(180)))
- break; /* DEG2RAD for calc error */
+ && (fabs(trans->rotation - M_PI) < 1E-6))
+ break;

aper = gerbv_image_duplicate_aperture (
destImage->aperture[newNet->aperture]);
aper->parameter[0] *= trans->scaleX;
aper->parameter[1] *= trans->scaleY;

- if (fabs(trans->rotation) == M_PI_2
- || fabs(trans->rotation) == DEG2RAD(90)
- || fabs(trans->rotation) == (M_PI+M_PI_2)
- || fabs(trans->rotation) == DEG2RAD(270)) {
- /* DEG2RAD for calc error */
+ if (fabs(trans->rotation - M_PI_2) < 1E-6
+ || fabs(trans->rotation - (M_PI+M_PI_2)) < 1E-6) {
double t = aper->parameter[0];
aper->parameter[0] = aper->parameter[1];
aper->parameter[1] = t;

[Joerg Wunsch]

Post by Joerg Wunsch
+ && (fabs(trans->rotation - M_PI) < 1E-6))
+ break;
+ if (fabs(trans->rotation - M_PI_2) < 1E-6
+ || fabs(trans->rotation - (M_PI+M_PI_2)) < 1E-6) {

After thinking more about it, of course, two times fabs()
is needed.

diff --git a/src/gerb_image.c b/src/gerb_image.c
index 257f055..fe72305 100644
--- a/src/gerb_image.c
+++ b/src/gerb_image.c
@@ -590,20 +590,16 @@ gerbv_image_copy_all_nets (gerbv_image_t *sourceImage,
case GERBV_APTYPE_OVAL:
if (trans->scaleX == trans->scaleY
&& trans->scaleX == 1.0
- && (fabs(trans->rotation) == M_PI
- || fabs(trans->rotation) == DEG2RAD(180)))
- break; /* DEG2RAD for calc error */
+ && (fabs(fabs(trans->rotation) - M_PI) < 1E-6))
+ break;

aper = gerbv_image_duplicate_aperture (
destImage->aperture[newNet->aperture]);
aper->parameter[0] *= trans->scaleX;
aper->parameter[1] *= trans->scaleY;

- if (fabs(trans->rotation) == M_PI_2
- || fabs(trans->rotation) == DEG2RAD(90)
- || fabs(trans->rotation) == (M_PI+M_PI_2)
- || fabs(trans->rotation) == DEG2RAD(270)) {
- /* DEG2RAD for calc error */
+ if (fabs(fabs(trans->rotation) - M_PI_2) < 1E-6
+ || fabs(fabs(trans->rotation) - (M_PI+M_PI_2)) < 1E-6) {
double t = aper->parameter[0];
aper->parameter[0] = aper->parameter[1];
aper->parameter[1] = t;

[Sergey Alyoshin]

Post by Joerg Wunsch

Post by Sergey Alyoshin
I have done panelization with "RS-274X Merge (Gerber)..." which use
merge_images().

I have been using it now in order to produce a large panel.
It's indeed a very nice option, thank you!
I have one suggestion: when merging the copper layers, gerbv suddenly
told me about being unable to rotate rectangular and oval shapes,
claiming the rotation angle would be non-multiple of 90 degrees (which
is basically impossible here).
This is due to the comparison of the double value trans->rotation
against absolute numbers. Such comparison is valid for absolute
0.0 (which always has a well-defined binary represantation), but
it's error-prone for values like M_PI etc.

I can't reproduce it on 64 and 32-bit systems with file
example/protel-pnp/SE_SG_IF_V2.GTL

Do you do rotation from command line or GUI?

[Joerg Wunsch]

Post by Sergey Alyoshin
I can't reproduce it on 64 and 32-bit systems with file
example/protel-pnp/SE_SG_IF_V2.GTL

It's not easy to reproduce. It happened as part of a complex panel
(panelizing 13 sub-PCBs). When using the files that caused the
problem in a single, separate project, they did work though.

Anyway, comparing floating-point numbers other than ±0.0, NaN or ±Inf
for equality is always error-prone. It would probably work if gerbv
internally consistently used constants like M_PI for both assignment
and comparison, but as of now, it flips back and forth between degrees
and radians.

Thus, I think the really only safe option is to compare for less than
a small epsilon rather than equality.

Post by Sergey Alyoshin
Do you do rotation from command line or GUI?

GUI. It's a rather complex job consisting of 112 layers for all
sub-PCBs. Apart from the rotation issue, Gerbv did indeed a fine job
on that.

The only addition that were on my wishlist is to allow for a kind of
output batch file that can remember which input layers to be merged
into which output layer, so this stackup has to be defined only once,
and then can be re-run again if needed. I wonder whether this could
be done using the embedded scheme interpreter?

[Sergey Alyoshin]

Post by Joerg Wunsch

Post by Sergey Alyoshin
I can't reproduce it on 64 and 32-bit systems with file
example/protel-pnp/SE_SG_IF_V2.GTL

It's not easy to reproduce. It happened as part of a complex panel
(panelizing 13 sub-PCBs). When using the files that caused the
problem in a single, separate project, they did work though.
Anyway, comparing floating-point numbers other than ±0.0, NaN or ±Inf
for equality is always error-prone. It would probably work if gerbv
internally consistently used constants like M_PI for both assignment
and comparison, but as of now, it flips back and forth between degrees
and radians.
Thus, I think the really only safe option is to compare for less than
a small epsilon rather than equality.

Maybe for clarity check against DBL_EPSILON instead of 1e-6?

Post by Joerg Wunsch

Post by Sergey Alyoshin
Do you do rotation from command line or GUI?

GUI. It's a rather complex job consisting of 112 layers for all
sub-PCBs. Apart from the rotation issue, Gerbv did indeed a fine job
on that.
The only addition that were on my wishlist is to allow for a kind of
output batch file that can remember which input layers to be merged
into which output layer, so this stackup has to be defined only once,
and then can be re-run again if needed. I wonder whether this could
be done using the embedded scheme interpreter?

You can make for _each_ merged layer a project file with positioning, rotation
and layer visibility. But merge function is not called from command line for
now. So each project needs to be opened in GUI and exported. Scheme (for now)
is only used to parse project files.

[Joerg Wunsch]

Post by Sergey Alyoshin

Post by Joerg Wunsch
Thus, I think the really only safe option is to compare for less than
a small epsilon rather than equality.

Maybe for clarity check against DBL_EPSILON instead of 1e-6?

OK, I'll give that a try. I wasn't aware such constant exists.

In theory, for a true epsilon, the difference would need to be divided
by the base value, but since all relevant base values (π/2, π·3/2) are
close enough to 1, I think this step can be skipped.

(Layer stack script)

Post by Sergey Alyoshin
You can make for _each_ merged layer a project file with positioning, rotation
and layer visibility.

That doesn't help much for panelization. There's two kind of layer
groups: one group forming each sub-board, each using the same
translation / rotation values (to be defined / refined while
panelizing), and one group forming each output layer. In order to be
useful, all the input layers need to be present in a single project.

Thanks for your response anyway, so at least, I know there's no easy
and obvious option I've been missing. The merge feature itself is
already useful enough as it is now, so a „болшое спасибо“ to you for
implementing it.

Maybe I should ask again for release plans, so this nice feature could
be more publically announced. ;-)

[Joerg Wunsch]

Post by Joerg Wunsch
(Layer stack script)

Post by Sergey Alyoshin
You can make for _each_ merged layer a project file with positioning, rotation
and layer visibility.

That doesn't help much for panelization.

OK, upon re-thinking, I guess I know what you mean.

Yes, a little more cumbersome than the scheme script I had in
mind, but maybe easier than re-arranging the stackup all the
time.

[Sergey Alyoshin]

Post by Joerg Wunsch

Post by Sergey Alyoshin

Post by Joerg Wunsch
Thus, I think the really only safe option is to compare for less than
a small epsilon rather than equality.

Maybe for clarity check against DBL_EPSILON instead of 1e-6?

OK, I'll give that a try. I wasn't aware such constant exists.
In theory, for a true epsilon, the difference would need to be divided
by the base value, but since all relevant base values (π/2, π·3/2) are
close enough to 1, I think this step can be skipped.
(Layer stack script)

Post by Sergey Alyoshin
You can make for _each_ merged layer a project file with positioning, rotation
and layer visibility.

That doesn't help much for panelization. There's two kind of layer
groups: one group forming each sub-board, each using the same
translation / rotation values (to be defined / refined while
panelizing), and one group forming each output layer. In order to be
useful, all the input layers need to be present in a single project.
Thanks for your response anyway, so at least, I know there's no easy
and obvious option I've been missing. The merge feature itself is
already useful enough as it is now, so a „болшое спасибо“ to you for
implementing it.

I am not the original author, just fixing some bugs.

Post by Joerg Wunsch
Maybe I should ask again for release plans, so this nice feature could
be more publically announced. ;-)

Export with merge was added in 2011 (and not by me).
I don't have release plans, but gerbv should be checked and released.

[Joerg Wunsch]

Post by Sergey Alyoshin
I don't have release plans, but gerbv should be checked and released.

So the big question is: who feels responsible for rolling a
new release?

[Dan McMahill]

Post by Joerg Wunsch

Post by Sergey Alyoshin
I don't have release plans, but gerbv should be checked and released.

So the big question is: who feels responsible for rolling a
new release?

we need to follow the release procedures this time as one of the recent
ones made it out without passing some of the simple Q/A checks. If the
procedure needs updating (which it may because it was written a long
time ago) then we should do that.

-Dan

[Joerg Wunsch]

Post by Sergey Alyoshin

Post by Joerg Wunsch
Thus, I think the really only safe option is to compare for less than
a small epsilon rather than equality.

Maybe for clarity check against DBL_EPSILON instead of 1e-6?

DBL_EPSILON didn't help … so I analyzed a bit more – and found it.

The issue is that this is a project loaded from a .gvp file.

Inside the .gvp file, you can find the following:

(define-layer! 73 (cons 'filename "HP10466A/HP10466A-B.SilkS.gbo")
(cons 'visible #f)
(cons 'color #(47802 47802 47802))
(cons 'translate #(5.688976 2.283465))
(cons 'rotation #(1.570796))

And that's exactly what you can find in trans->rotation then:
1.570796.

That explains why all the comparisons fail.

Thus, either the .gvp file needs to store full double precision, or
we must be tolerant in the comparison when producing the merged
Gerber layer.

[Sergey Alyoshin]

Post by Joerg Wunsch

Post by Sergey Alyoshin

Post by Joerg Wunsch
Thus, I think the really only safe option is to compare for less than
a small epsilon rather than equality.

Maybe for clarity check against DBL_EPSILON instead of 1e-6?

DBL_EPSILON didn't help … so I analyzed a bit more – and found it.
The issue is that this is a project loaded from a .gvp file.
(define-layer! 73 (cons 'filename "HP10466A/HP10466A-B.SilkS.gbo")
(cons 'visible #f)
(cons 'color #(47802 47802 47802))
(cons 'translate #(5.688976 2.283465))
(cons 'rotation #(1.570796))
1.570796.
That explains why all the comparisons fail.
Thus, either the .gvp file needs to store full double precision, or
we must be tolerant in the comparison when producing the merged
Gerber layer.

As this explain 1e-6 in you patch, I think you should add #define
GERBV_PROJECT_PRECISION 1e-6 in gerbv.h

------------------------------------------------------------------------------