| ID: | 3692 |
| From: | ge...@igor2.repo.hu |
| Date: | Sat, 18 Jan 2020 04:47:36 +0100 (CET) |
| Subject: | Re: [pcb-rnd] Warning, clear poly frame annotation flag before |
| in-reply-to: | 3691 from Gabriel Paubert <pa...@iram.es> |
Hi Gabriel,
On Fri, 17 Jan 2020, Gabriel Paubert wrote:
> Hi,
>
>I don't consider the following strictly a bug, but people should be
>aware, that, among the many display options implement in pcb-rnd, there
>is one which may cause subtle (hard to see) errors in the Gerber output
>(and maybe others).
Sorry, I have to disagree on this: I classify this a critical bug. I
will look into it ASAP and see if it is safe to fix before the
upcoming release.
Rationale: anything that ruins our primary export, especially if it is
causing shorts on copper, is critical. On a dense board it is especially
easy to have all tests (netlist, drc) passed then have this bug cause
unnoticed shorts on the output, turning your fresh boards into expensive
industrial waste.
>As a testcase distilled from a much larger example, consider the
>attached files, which consist of a single polygon and a straight track.
>The first file is a standard pcb-rnd file, the second one the Gerber
>output of the top layer.
>
>When looking at the Gerber file under gerbv, you'll also see a line
>along the outline of the polygon. This is also seen on the display, so
>it may be reasonable to put it in the Gerber file, although the
>resulting Gerber file wouldn'pass DRC.
>
>What is worse is that the corresponding Gerber file is invalid: the
>frame is drawn with a very thin line. When nanometer resolution is
>selected, the file contains the following definition:
>
>%ADD13C,-0.000001*%
>
>while the Gerber specification explicitly says that the diameter of
>a circular aperture must be positive or zero. There are other arguable
>points in the specification but that one looks sensible.
>
>At least for my test cases, this problem does not happen when the
>polygon frames are not displayed, as no negative diameter apertures
>definitions appear in the Gerber files.
>
>When the resolution is not set to nanometer, the aperture diameter
>becomes zero, but the value still always starts with a minus sign.
>
>I don't know what the correct solution to this issue is: I have done
>some experiments and it seems that exporters (at least Gerber export
>through cam) ignore the state of the "Thin draw poly" {m d p} flag,
>should the {m d d} flag also be ignored?
This is a bug on multiple levels:
1. There are two concepts: board data and screen display. Board data is
what the data model encodes. The only one type of polygon we have is
filled polygon. We don't have polylines, polygon frames, and our polygons
don't have contour thickness (many other EDA data models have that). Then
on screen we often display helpers deduced from metadata - like the red
dashed frame of subcircuits, the red refdes printout, the mark ({a m}),
etc. These are called internally overlay^1. On (most^2) export output, we
should export the data model as-is, and we should not export any overlay -
because overlay is exclusive to the screen, for editing. Gerber definitely
shouldn't have any overlay leaked in. (This is a more generic wording of
your thin draw consideration)
2. An overlay is not in the stack, so it can not be copper. What you see
here is an overlay line turning into copper, which is wrong even if we
decide we want to see overlays in gerber. I.e. {c f} won't regard this
thin line conductive, while it will be conductive on your physical board.
3. Our exports should be reproducible. That means, especially with cam,
that you can store a script that you can run and get the same gerbers from
the same board, no matter what display settings you have in your GUI.
Which means configuration from editor/ and appearance/ subtrees should not
affect your output. (This is an even more generic wording of your thin
draw consideration.)
4. The negative thickness has a good reason: on screen rendering, we have
two different domains for thickness: positive values are real nanometer
thickness (zoom affects them) while negative values are interpreted
as pixel width. For example -1 means "draw this thin line 1 pixel wide, no
matter what zoom level we have". This trick is very useful on screen where
you can zoom freely. However, "zooming" and "pixel" is not meaningful on
any vector graphic output, so these objects shall never reach exporters.
Footnotes:
^1 overlay vs. virtual layer: the overlay mechanism happened way before we
had the layer system finalized. It continued the tradition of PCB for
drawing some edit helper (e.g. the "attached objects", the preview objects
while you are drawing). At the moment I think it'd be better to have these
on a separate virtual layer (like the subcircuit annotations). This would
obviously handle this problem, but it'd be then incosistent with the thin
draw, black&white rendering, etc. So probably it will remain a config
setting to keep it consistent with those.
^2 currently there are some exceptions. For example in png and ps we and
svg we do not ignore layer color, so screen leaks in the export. That's
fine, we just say there are a few exporters that reproduce more of the
screen while others reproduce raw data. However, there's still some
inherited mess with settings: png for example also exports selection
color while it has the --as-shown export flag that doing random things. In
the same time ps doesn't have --as-shown and handles selection color
differently. I have a few TODOs about unify these, most probably through
cam using standard transformation supplements (so it would work on export
render level, not plugin level, which means it would be available for all
export plugins in an unified manner and won't break backward
compatibility).
Regards,
Igor2
Reply subtree:
3692 Re: [pcb-rnd] Warning, clear poly frame annotation flag before from ge...@igor2.repo.hu