Currently, QElectroTech exports PDF files using Qt's `QPrinter`/`QPainter`, which renders content flat — text and shapes are drawn correctly, but there is no support for embedded hyperlink annotations in the PDF output.

This is why the workaround Python script (using PyMuPDF/fitz) was created: it post-processes the exported PDF to detect cross-reference labels, calculate target page positions, and inject clickable link annotations (`/Annots`) into the PDF.

It would be great to have this functionality built directly into QET's PDF export.

**Why Qt5 is a dead end**

Qt5 has reached its end of life. No security patches, no bug fixes unless they also affect Qt6. Linux distributions are already phasing it out. The migration to Qt6 is not optional — it is a matter of survival for the project. Any energy invested in patching the PDF export on Qt5 is wasted effort.

**What Qt6 brings — and what it still doesn't**

Despite ongoing improvements to `QPdfWriter` across Qt6 releases (ColorModel, CMYK, OutputIntent...), there is still no official public API for writing link annotations (`/Annots`) as of Qt 6.11. This limitation has actually been tracked since 2015 (QTBUG-44563) with no resolution to date.

However, Qt's internal PDF engine does have a private method — `QPdfEngine::drawHyperlink(QRect, QUrl)` — that can write link annotations. It is accessible (unofficially) by casting the paint engine:

```cpp
dynamic_cast<QPdfEngine*>(painter.paintEngine())->drawHyperlink(rect, url);
```

This requires including the private header `qpdf_p.h` and is not part of the public API, so it could break between Qt versions. But it proves the underlying engine already supports it — it just isn't exposed.

**The right approach**

There are three realistic paths for QET:

1. **Use `QPdfEngine::drawHyperlink` (private API)** — works today, no external dependency, but fragile across Qt version updates.
2. **Port the Python post-processing to C++** — using a library such as libmupdf or QPDF to inject `/Annots` after export, same logic as Alfonso's script but integrated natively.
3. **Wait for Qt to expose this officially** — unlikely in the short term given QTBUG-44563 has been open for 10 years.

The Qt6 migration is the right moment to tackle this. The PDF export code will be touched anyway, and option 1 could be a pragmatic first step while option 2 is planned as a more robust long-term solution.

Thanks to Alfonso and the community for the Python workaround — it proves the concept and shows this is a real user need.

I can see that, between you all, you’re making the programme progress by leaps and bounds! It’s fantastic!

For example, at the company where I work, we’re developing a Python programme that uses .qetmak files to automatically generate a complete drawing. We’ve seen that it’s entirely feasible based on the tests we’ve run, but we’ve still got a lot of work ahead of us creating the .qetmak files to a specific standard, and we’re looking into how to maintain the link between elements with the same name, as they currently depend on their ‘uuid’, which is currently generated randomly and therefore changes from project to project.
The idea for the future is that, using AI to help understand client requirements, a code containing the schematic’s characteristics will be generated, and using this code and the Python programme, we will obtain a .qet file ready for minor adjustments.
Of course, we’ll share the solution once it’s more fully developed; although it might not be suitable for everyone, it could be useful for some people.

Thanks to Kellermorph for implementing .qetmak and other features!
I’d love to contribute code directly rather than Python applications, but we don’t have enough programming knowledge and much time to acquire it.

Currently, QElectroTech exports PDF files using Qt's QPrinter/QPainter, which renders content "flat" — text and shapes are drawn correctly, but there is no support for embedded hyperlink annotations in the PDF output.

This is why the workaround Python script (using PyMuPDF/fitz) was created: it post-processes the exported PDF to detect cross-reference labels, calculate target page positions, and inject clickable link annotations (/Annots) into the PDF.

It would be great to have this functionality built directly into QET's PDF export.

Why Qt6 is now the only way forward

Qt5 reached its end of life and is no longer receiving updates. This migration is not optional — it is a matter of long-term maintainability and security for QET. But beyond that, Qt6 also brings the technical solution to this very problem.

Qt5 was fundamentally limited to "painting" content onto PDF pages with no awareness of the document structure. There was no supported way to embed hyperlink annotations natively — hence the need for external post-processing tools like the Python script.

Qt6 introduced the QtPdf module, which works with PDF documents at a structural level rather than just drawing pixels. Starting from Qt 6.4, this module exposes proper PDF navigation and document structure capabilities, and the writing side is actively being extended. This makes it technically feasible to embed internal page-to-page hyperlinks (/Annots) directly at export time — no external library, no post-processing step, no Python script needed.

In short: the end of Qt5 support is already decided. The migration to Qt6 is inevitable. And Qt6 happens to bring exactly the PDF capabilities needed to implement native cross-reference links properly. This is the right moment to plan this feature as part of the Qt6 migration effort, rather than treating it as a separate task later.

Thanks to Alfonso and the community for the Python workaround in the meantime — it proves the concept works and that users genuinely need this feature!

I’ve continued developing the script.
To do this, I’ve configured and programmed a wide variety of settings from QET.
Could you please test it and give me some feedback? There might still be some errors, for example because the page size is significantly different and the scaling isn’t quite right yet, or something like that.

Features that aren’t included yet:
Position of the cross-reference for the slave component: text alignment. I’m not exactly sure how this works yet. Can someone tell me?
Also, the component information isn’t available in languages other than German and English yet.

As soon as the script runs without errors, I'll adapt it for the command line

Translated with DeepL.com (free version)

would it be possible, that u give me .qet to test it? I have tried with a single page with 2-1 and it works.

I think this should be possible.
i can take a look.

But that this works, i have to enter the different Settings from QET. This will take a bit of time. If u want, i can do that

I have implemented your idea.
The script is attached.

Currently, German and English are supported.
The settings currently supported in QET are:

Text alignment for slave elements: Top, Right, Bottom, Left
Settings for the master: Position below the master and display as contacts.

This means that the options for displaying as a table and showing the contacts at the bottom of the slide are still missing. I don't use these settings either.
For Commutator must be used slave elements which are marked with other

I have implemented an additional function:
You can also enter component information, such as manufacturer, function, etc.
To do this, an info box is placed on the upper left contact of the element. This allows you to see directly which component it is and you don't have to go to the component directory. Since I use the variables for my tool with the terminal diagram differently than their labeling, I have included the option to exclude any components of the terminal type for the info boxes.

Translated with DeepL.com (free version)

Thank you for moving forward with this kind of tools that greatly improve our diagrams!

As you know, my program reads the page+coordinate, and creates a link on the corresponding page of the PDF file with the row/column coordinate.

If the formatting is not correct, or the pages are not consecutive, there will be problems with the references in my program.
The tool adapts to our schema creation rules (use of row and column, use consecutive pages, etc.). We are trying to make it more universal by adding the most common cross-reference formats, but it will never be to the liking of all users.

Probably we can make a tool that reads the links directly from .qet, but we don't have the time to develop it right now.

This is why, the best thing would be to include this functionality directly in QET built-in PDF export tool.