PCB silkscreen text printed behind copper (footprint fields are OK)

[Todor Todorov]

I have custom text on Fsilk and Bsilk layers. When I printed out the PCB layout via the print dialog (to PDF file), my selection was to include top copper, edge, and top silk layers. The printout included only the component references, my custom text was not added. The same text was included without issue in the corresponding gerber file.

I will include the gerber files for the top copper, top silk, and edge layers, as well as the resulting PDF file to this bug report.

Using KiCad nightly 64bit on Windows 10.

Application: kicad
Version: (6.0.0-rc1-dev-271-g539ca5aa3), release build
Libraries:
    wxWidgets 3.0.3
    libcurl/7.54.1 OpenSSL/1.0.2l zlib/1.2.11 libssh2/1.8.0 nghttp2/1.23.1 librtmp/2.3
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
    wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8)
    Boost: 1.60.0
    OpenCASCADE Community Edition: 6.8.0
    Curl: 7.54.1
    Compiler: GCC 7.1.0 with C++ ABI 1011

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

[Jeff Young (jeyjey)]

I can't reproduce this. (I'm on OSX, but it seems unlikely this would be platform-specific.)

@Todor, by "custom text" do you mean a user-defined text item in a footprint, or text added directly to the board (with the text tool)?

Also, a screenshot of the Items tab in your Layers Manager might provide some clues.

[Jeff Young (jeyjey)]

Never mind; I didn't see that you had posted your board.

It appears that for whatever reason we're printing the copper in front of the silkscreen. Note in the attachment that you can see the board text where the copper has gaps.

[Jeff Young (jeyjey)]

Hmmm.... legacy canvas doesn't really do layers at all, it just relies on the commutative nature of OR (which doesn't help for printing).

It was drawing objects in the order:

Tracks
PCB objects
Zones
Modules

Since PCB objects are going to be predominantly human-readable stuff, and it seems like the copper should go together, I'd propose changing it to:

Tracks
Zones
PCB objects
Modules

for 5.1. Hopefully it's all gone in 6.0, but I wouldn't want to count on that.

[Todor Todorov (ttodorov)]

@Jeff, when you say "...legacy canvas...", do you mean that the printing uses legacy canvas to draw before sending to the spooler, or do you think that I am using legacy canvas? If the latter, I can assure you, I am not.

Also, when you say "it's gone in 6.0", do you mean it's fixed on the master branch (not the case as of commit gc91e51f68), or that it's just planned to be changed while 6.0 is being developed?

Thanks!

[Jeff Young (jeyjey)]

@Todor, sadly it's the former. We never re-wrote printing to live on the new architecture (since most of our energy goes into Plot rather than Print).

The master branch, while it says 6.0, is actually 5.1. In 5.1 we're moving eeschema to the modern canvas -- but that's mostly so it will work on GTK3 and so printing probably won't be addressed.

Later on in 6.0 we hope to remove the legacy canvas entirely -- but it's possible even then that we'll still be using the old printing code (with a compatibility mapping to the new canvas underneath it).

[KiCad Janitor (kicad-janitor)]

Fixed in revision 8fe5ff612dde91b8759a57ee5a58da9ba2d455ab
https://git.launchpad.net/kicad/patch/?id=8fe5ff612dde91b8759a57ee5a58da9ba2d455ab

[Maciej Suminski (orsonmmz)]

Slightly related: the printing related code is being refactored to take advantage of GAL too.

[Jeff Young (jeyjey)]

Excellent!