Gerber in linux kicad

Yes, everything works correctly, but on condition that the site is not in a single instance … The second and very big drawback in the case of replacing the footprint is that the coordinates on the stencil file are lost, the previous coordinate binding at the place of replacement breaks … Because how to find out what the footprint was to not possible due to missing board file

Are you sure about that?
It is very common to snap track ends to the centers of pads during the design of a PCB. In the reverse gerber article I just did it the other way around: I snapped the center of one of the pads of a footprint to a left over open track end. Pads of for example a TQFP may shift a bit inward or outward, but that is also easy to check in KiCad’s PCB Editor. For a more elaborate reverse engineering job you can also create or modify footprints to have the exact same pitch by measuring distances of track ends. KiCad does not place many restrictions on how you want to use it.

And for today, I think I’ve put enough time in it…

I think that it is possible to adjust exactly, but for this you need to have a suitable footprint, it is quite easy to check after generating a new gerbera, compare it with the old method of overlaying one on top of the other … we have slightly different tasks, you need to conditionally make a new device from gerberas and I will edit at the same time, the board itself already exists … it turns out that when making the aperture, footprints will leave me, since in my case the center remains unchanged and only the shape changes. if you happen to see something similar for linux let me know

I am not sure if you understand what you are talking about. A viewer is not an editor. You can also edit it with a text editor, as others are saying. But I recommend you post your questions on how to do such things on the Gerber Editor forum. Here is not the right place for such a question since Kicad does not have such a tool.

1 Like

Since it’s a text format, there might be a python plugin that we don’t know about…

It’s not surprising at all. First, the gerber file format has clearly not been designed with edit-save cycle in mind. It’s for exporting from other software, from other formats where the shapes are edited.

My reference there was the geda viewer IIRC. Even that simple task which it can do wasn’t done without rewriting the whole file structure. For most tasks editing the file in place, just replacing some text, would be practically impossible.

The problem is that there will probably be 10 editors for win10, both paid and free, starting from giants like sam350 ending with herbmagic and on Linux 0) There is more of a problem with the operating system and its popularity, the only work-saving option is a virtual machine … On the other hand, in its own time the eagle had a cam editor

For those who don’t know: (Although you may have meant just Windows?)

For complex applications preferably a virtual machine it is more reliable…
I’ll try to compile for Linux to see what it can do

1 Like

can you build it in win?
which command and environment do you use?
From the repo it seems it does’nt have any dependency limited to win… it seems instead it has been developed in Linux

Just started to figure it out, I wrote to the author … I definitely won’t master one, but I have a friend for this)) probably like everyone who knows Linux well) At the moment, it doesn’t start when building, I used a Linux ubuntu compiler

Cam350 is not a ECAD package. It is software for PCB manufacture, merging Gerber jobs from various customers and also adjusting supplied files to suit the production process - changes to via tenting, solder resist between pads etc.
I doubt most of the Cam350 users would be interested in a Linux or Mac version

Here is a small part of the program that can do this … Prepare gerber files for production, make changes without the board file … They are all under win
FAB 3000
As you can see, this is only a small part, but they all know how to do it.

Certainly, but until someone who can do and wants to do and has the time to do this steps in, we won’t have it in KiCad or on Linux. The user base for a gerber editor would be much smaller than for an EDA package, and we would rather see KiCad EDA features developed further.

This is now (again) getting borderline acceptable.

Yesterday we discussed the limitations and workarounds for KiCad quite exhaustively. There is no need to keep on repeating KiCad’s limitations again and again. There are a lot of reasons why it currently is the way it is now, and such statements change nothing.

If only it was so easy. Developing a production editor would require a lot of interfacing with actual PCB fabs to test it properly and they wont want to take the risk of losing production.
Free is not an attraction when so many Cam350 cracks are in use

I don’t think this thread is going to do anything more useful

I have opened this topic again to give you a chance to add something constructive.

But I do understand davidrsb’s reason for closing it.
You have received at least one PM about similar behavior like this recently, and it’s been going on for at least 4 months. Behind the scenes there is a discussion going on of whether it’s time to take more drastic measurements.

I hope you treat this as a serious (last?) warning.

1 Like

Here are my points:

  • 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.