Gerbv was originally developed as part of the gEDA Project but is now separately maintained.

Official releases are published on GitHub Releases. Moreover, CI generated binaries are published on gerbv.github.io. Be aware however that they are not manually verified!

• Gerbv is a viewer for Gerber RS-274X files, Excellon drill files, and CSV pick-and-place files. (Note: RS-274D files are not supported.)
• Gerbv is a native Linux application, and it runs on many common Unix platforms.
• Gerbv is free/open-source software.
• The core functionality of Gerbv is located in a separate library (libgerbv), allowing developers to include Gerber parsing/editing/exporting/rendering into other programs.
• Gerbv is one of the utilities originally affiliated with the gEDA project, an umbrella organization dedicated to producing free software tools for electronic design.

This is basically a fork of the fork. There have been many chefs trying to fix this soup, but they have never gotten to the bottom of the problems. I (the original creator and maintainer of the gerbv project) have taken over this branch. I gave up the role of maintainer many years ago due to me becoming a consultant with my own business and didn't feel I had time for this.

Since then a lot of things in the software world have revolutionized the way software is developed. From as simple things as Git and github, up to todays AI coding tools. The compilers have become much better at finding problems and errors (you have to enable flags) and also open source tools for static analysis is available.

I have plans on what to do. Some plans may upset people. If this upsets you I welcome you to create your own fork, I see no problems with that.

I have started the develop branch to back out of some completely and utterly useless code formatting changes. There are more serious problems than reformatting the code to some style that is not used anywhere in the code. I admit the code style is broken, but it is really not the first on the agenda to fix. The original main branch will stay as it is for the time being.

This is a list of things I hope to be able to fix

• CMake
  • Fix Linux/general CMake target
  • Fix Windows CMake by cross compilation using Mingw64
  • Remove files that are not used anymore or just ancient
  • Make Github pipeline compile the new targets
  • Fix outstanding tests/targets that are in use on the Github pipeline
    • Rebuild and deploy website properly (missing variables at the moment)
    • Enable unit tests
    • Enable Valgrind (maybe)
    • Enable Coverage (maybe)
• Fixing first set of trivial bugs
• Packing
  • deb
  • rpm
  • Windows NSIS
• More updated Gerber specifications
• Port over to GTK-3.0
• Fixing misunderstandings of the original specification
• General documentation
• Code reformatting

First order of business is to use CMake, which is a more modern tool to create builds compared to autotools. Autotools were born in an era of diversified releases of different Unix systems. Now it is basically Linux everywhere. I have anyhow never liked autotools with its obscure syntax.

Hopefully it can simplify things like MacOS, Windows and packaging. Since we are using GTK, it will probably never be trivial I guess.

CMake Presets are a thing. Also some sourcecode directory structure can and will probably be updated at a later stage.

When I was porting the code to CMake I found a bunch of trivial but serious errors. So I fixed them. Upgrading the compiler version have also reveled a number of compilation errors.

Current packing of binaries are zipping it all together. It is always nicer to have the code in the - for the operating system/distribution - native way.

Since we now use CMake we should be able to use the packing support available. For Debian/Ubuntu that would mean .deb and for Red Hat/Fedora that would mean .rpm. When creating the CMake build system I spent considerable time to make the install target to be as good as it possible could, looking at the Ubuntu/Debian gerbv package as a role model.

For Windows builds we should use the NSIS toolchain. For the Windows packing there is a need for distributing all the .dll files as well (30+), but my limited experience says it shouldn't be a problem.

When I started this project the "specification" at the time was around 60 pages. Now it is over 200 pages and most things are more clearly defined. And there are updates with new things as well. Hopefully at least try to parse without warnings on missing syntax.

There is (at least was) a lot of broken Gerber files out there. Just look in the examples directory. The question is if it still is so, and if we should support every little quirk, and error or omission.

GTK-2.0 is obsoleted since some year(s) back. Already GTK-2.0 have developed since gerbv went there and obsoleted a couple of things that are still used in gerbv. That makes it even harder to update to GTK-3.0.

It is not trivial, a lot of things have changed. There is an excellent patch waiting from @LemonBoy which I have high hopes for. And with a little help from Claude I hope we can pull this together.

The biggest change for gerbv is probably that GDK is removed. That was our fastest drawing frontend. But with faster computers and graphics it hopefully works out OK. If anyone feels adventurous, a frontend using OpenGL is always welcome.

I am not a graphics guy, I always liked the parsing part more. So from the tiny "standards" paper to the full-blown standards paper of today there are bunch of things that has been misunderstood or not even implemented.

There are today lots of tools to document your code. One great thing I have discovered by switching to a more modern IDE is to document the API of all functions using Doxygen.

This is more of a continuous task. For every file touched some documentation can be updated.

Of course a code reformatting will be done. This will be a stepwise update, one file at a time. One of the problems with a complete reformatting is the loss of history. You need the history when coming into a project first time to try to understand why something is like it is.

This goes slightly hand in hand with the General documentation updates. Step-wise and when the file is updated for some other reason.

As the project goes on in rewriting, more and more trivial and not-so-trivial bugs are surfaced. Those will be fixed asap when they are discovered. There can be platforms developers don't have access to, that might delay things. But the urgency will be based on severity.

• Compilation error/warnings. Code should always compile.
• Crashes. Segfaults and similar memory crashes. They can be hard to recreate though.
• Other annoyances.

You need:

• gcc
• gtk+-2.0 (use dev package)
• glib-2.0 (use dev package)
• cmake (>=3.28)
• ninja

To configure the build process, run

cmake --preset linux-gnu-gcc

That will create a directory called build with all configuration.

To compile you can choose debug build (default) or release build and then run

cmake --build --preset linux-gnu-gcc

or

cmake --build --preset linux-gnu-gcc-release

There is already an installation process available. You can test it out until I get the energy to write it down properly. It is quite easy if you want to install it under /usr/local. Basically you run

cmake --install build

If you want to install it somewhere else, then YMMV.

Status: compiles

For creating Windows binaries, the Fedora distribution is used. It provides all the development libraries that is needed for Mingw64 cross compilation, especially GTK2.0+ and Cairo.

Compilation have been tested on Fedora 43 with the following libraries installed:

• mingw64-cairo-static
• mingw64-gtk2.static
• cmake
• ninja
• mingw64-gcc
• mingw64-gcc-c++
• gettext

As the binaries are not tested at the moment it might not work or crash horrible. But I would appreciate any report.

The preset is called mingw-w64-gcc and the toolchain file is located in cmake/toolchains/mingw-w64-gcc.cmake.

To configure you do

cmake --preset mingw-w64-gcc

and to compile you do

cmake --build --preset mingw-w64-gcc

To create another cross compilation target, check the directory cmake/toolchains/.

To create another preset, check out the directory cmake/preset/ and add the new preset file as an include in CMakePreset.json.

• Patch #77: Fix double-freeing memory, applied in PR#24 as Commit a96b46
• Patch #81: Fix casting pointer to different size integer, applied in PR#23 as Commit e4b344
• Patch #83: Crash may occur on opening/saveing files, applied in PR#8 as Commit 242dda

Gerbv has been built and tested on

• Debian 13 (amd64)
• Fedora 43 (amd64)
• Ubuntu 22.04 (amd64)
• Windows 10 (amd64 cross compiled from Fedora as well as native x86/amd64 using MSYS2)

There is a build for both Fedora 43 and for Windows using Fedora 43 (previously 38). Both builds suffer from missing DXF support libraries. Fedora have another DXF library available, but that requires porting work and support for two different DXF libs. Of course neither Debian nor Ubuntu have that library available.

There is a problem switching to Ubuntu 24.04, which should be the better choice. The Docker image for Ubuntu 24.04 defines a user with UID/GID 1000, the toolchain used to do the cross compilation (see https://github.com/ooxi/mini-cross) tries to define a new user with same UID/GID and thus fails.

Using the mini-cross builder is a problem in itself, but that issue is for another day.

The problem might only be when running the application locally, but it is hard to develop and test without being able to run locally. When installing Ubuntu, the first user created is always UID/GID 1000.

This problem have been deferred at the moment, running on Ubuntu 22.04 should be good enough for the time being.

Gerbv is split into a core functional library and a GUI portion. Developers wishing to incorporate Gerber parsing/editing/exporting/rendering into other programs are welcome to use libgerbv. Complete API documentation for libgerbv is here, as well as many example programs using libgerbv.

The current focus of gerbv is to provide a utility to view and manipulate trusted gerber files. When using gerbv, you should not view files from untrusted sources without extra precautions.

Nevertheless, we acknowledge that libgerbv will be used to handle untrusted input, maybe even provided over the network. In those cases we strongly advise to treat libgerbv as any codec and isolate its operations from the rest of your application.

If you are aware of a security issue, we recommend full public disclosure as a GitHub issue. This way our users are warned and can act accordingly while we work on providing a mitigation.

Gerbv and all associated files is placed under the GNU Public License (GPL) version 2.0. See the toplevel COPYING file for more information.

Programs and associated files are: Copyright 2001, 2002 by Stefan Petersen and the respective original authors (which are listed on the respective files)