Adding editor features to a gerber viewer isn’t as simple as it may look like – even changing a simple shape may require rewriting the whole file structure.
It doesn’t make sense to add some random simple editing features; it should be a full-blown editor.
It should fulfill professional needs, not just some few random hobbyist use cases.
Those professional needs may be more complicated than we can guess.
It would require gathering user requirements to find out what the target feature set should be.
Few people would benefit of those features. There are much, much more of those who design with EDA than of those who ever want to edit gerbers directly.
This would require a whole new application or rewriting an existing one, not just some small additions to KiCad gerber viewer.
One thing might be semi-reasonable, depending on how the KiCad viewer is currently implemented. If the internal representation of the structures is fitting for this, it might be possible to expose them in a python API and let them be scripted. Even then it would need totally new internal structure → gerber file structure conversion which doesn’t exist ATM. So, even this may have bad “cost”/benefit ratio, but at least would make it possible to script editor features so that the core developers wouldn’t need to think about use cases and the user interface etc.
since kicad does not have a permanent api, I think it is possible, given that gerber is a text format that python understands well … all libraries and descriptions for the gerber format are available this description was used in the production file generation section … another option is further development gerbv has already been done a lot … at this stage, it makes sense to try ready-made options … I see this so that gerber goes into the plugin as a pit from the viewer and returns back … according to this principle, panelization now works, for example, and by the way, a very useful function …
One more major issue about a true Gerber editor is that it has to deal with the flawed output of all ECAD software packages. KiCad has placed great emphasis on getting strictly compliant Gerber over the years, but I wouldn’t like to claim 100%.
Then there has been pressure to actually cheat, to work around a well known bug in one common Cam350 version affecting silkscreen circles, but a way round that strictly follows the spec was found.
Now how do you edit the Gerber so that a slightly broken downstream editor at the fab copes?
The problem is that when converting to a board, the gerber becomes just a picture; if we draw an analogy, this happens when converting a board file, for example, to svg … the board editor does not understand that this is an aperture or a primitive
I did not quite understand how silkscreen affects gerberas? You superimpose a picture on the coordinates, which is what silk screen printing is … When editing a gerber file, there are three main parameters - the shape for x1 primitives for x2 are more complex shapes plus macros and the coordinates themselves … In case of a file breakdown, cam 350 restores these parameters and if if you try to do it in the PCB editor with conversion, then the primary and generated file will be different for the PCB editor, there is no concept of macro primitives and form descriptions
Yes, and that’s a problem even when editing the gerber directly. The root of the problems is in the gerber specification itself and in the widely differing implementations and interpretations. There’s more than one way to define shapes, pads etc. and there’s no canonical order for items in the file. There are also differing needs for different kinds of shapes. In the end the file is meant for being translated to some mechanical device’s CAM format which doesn’t know about pads or differences between apertures, regions etc.
For example KiCad creates different kinds of pad shapes with different strategies. It doesn’t use negative flashes for inner layer via annulars but draws a whole continuous zone fill as one polygonal region.
Think about old gerbers with zone fills made with side by side segments contra the recommended way of using regions.
This non-standard standardized mess makes an idea of an editor much more difficult than what it may seem.
I would rather add a python API to the viewer’s internal representation and then explore the possibilities for exporting gerbers to the PCB editor with some intelligence using the API. An API would also make gerber file export possible through a plugin. Again, that way the core developers would be responsible only for the core viewer functionality and the API, and anyone could develop editing capabilities and exporters.
When editing gerberas directly, there are no such problems if the editor follows the 274x or x2 standard … This is how most modern adult programs work … Any shape for a gerbera is a set of coordinates, more complex shapes are described in a macro, and it turns out that when editing a gerbera, you can not change coordinates to change the shape and even more complex shapes are available in x2 … Yes, I also tend to the plugin as the beginning of this function
I have used gerbv to correct registration of gerber files when the original designer somehow created X and Y offsets in only some of the layers in their PADS projects…
Good point … I wonder if the gerberber is transferred to the board and set there to 0 then generate new ones whether they will differ from direct editing in gerbv ?
Actually X2 added attributes, but left the image as it was for compatibility. X2 has exactly the same image capabilities, no additional complex shapes are available.
The editor may strictly comply with the spec, and follow all good practices and guidelines, but it will still have to make sense of the crap that roams the wild. Some files do not even comply with the spec. Mentor files especially are all too often horrible.
A second problem is that rs274X is purely an image, without link to what it is in CAD. There is a circle. What is it? Different CAD objects can be represented by the same Gerber construct, and vice versa. You will have to write software reverse engineer this information, and this is a massive task. This is different in X2, where via’s, fiducials etc are identified as such.
An editor for perfect X2 files is one thing. An editor for the files that roam the wild is an entirely different thing.
And what has this to do with KiCad, which is CAD system. Yes, it produces Gerber files, but also other formats. Should it also contain a PDF editor? And anyhow, there are Gerber editors, such as gerbv.
Visually, this is a complex shape … It is she who describes the structure
For example, white in the photo is x2 in x1, it will be just white throughout the office of the site
in continuation of the topic … I managed to build an editor for Linux … of course it is raw and does not understand all forms, but it works … in the future I will try to combine it with gerbv or finish it as a separate application …
Be careful, gerbv moves everything in seemingly random directions a tiny bit when saving. I don’t use for editing gerbers because of that. Even stuff that has whole coorrdinates (i.e. even something that is exactly at 1mm, 1mm).
