Frage zu PDF-Export mit Links

Hello everyone,

I have an existing schematic that I’d like to save as a PDF with hyperlinks.

Although the schematic does generate a PDF with links, the links do not use relative links to page xy within the PDF; instead, they contain a full web link:

file:///complete/path/to/file/and/filename.pdf#page=3&fitr=57_257_171_371

None of my PDF viewers can handle this format, so the links don’t work.
Even if the links did work there, they would break if the PDF file were renamed or moved.

Unfortunately, I can’t post the QET file here, which is why I’m asking:
- What requirements must be met for the links in the PDF export to work?
- Can I modify the existing plan with minimal effort so that the links work?

Best regards,
  plc-user

P.S.: A newly created file with links also works as a PDF export.

Hallo plc-user,

kurze Klarstellung: Die Querverweis-Hyperlinks im PDF-Export stammen nicht von mir, sondern von ispyisail (PR #490, schließt Issue #417 „Internal links in PDF export"). Danke an ihn dafür!

Zum eigentlichen Problem: Die internen Links werden in zwei Schritten erzeugt. Zuerst wird für jeden Querverweis ein file://...#page=N-Link geschrieben, danach wandelt eine Nachbearbeitung diese file://-URIs direkt in den PDF-Bytes in interne /GoTo-Sprungziele um. Wenn das klappt, sieht man am Ende gar keine file://-Links mehr.

Dass es bei einem neuen Testfile funktioniert, beim bestehenden Plan aber nicht, deutet auf einen Sonderfall in dieser Nachbearbeitung hin: Sie sucht im PDF nach der ersten Fundstelle von /Type /Pages, um die Seitenliste zu finden. Enthält der bestehende Plan eingebettete Bilder (Logo im Schriftfeld, Hintergrundbild o.ä.), könnte deren Binärinhalt zufällig diese Zeichenfolge enthalten und die Erkennung durcheinanderbringen — die Umwandlung würde dann still übersprungen, und die ursprünglichen file://-Links blieben stehen.

Um das einzugrenzen, ohne dass du die Datei posten musst:

Enthält dein Plan eingebettete Bilder (Logo, Hintergrund, Bild in einem Textfeld/Schriftfeld)?
Testweise: Plan duplizieren, alle eingebetteten Bilder entfernen, erneut als PDF exportieren — funktionieren die Links dann?
Wie viele Seiten/Pläne hat das Projekt ungefähr?
Falls sich das bestätigt, ist das ein echter Bug in der Nachbearbeitung, den wir fixen sollten.

Gruß

English:

Hallo plc-user

Quick correction: the cross-reference hyperlinks in the PDF export weren't written by me — that's ispyisail's work (PR #490, closing issue #417 "Internal links in PDF export"). Credit where it's due!

On the actual issue: internal links are produced in two steps. First, each cross-reference gets a file://...#page=N link written out; then a post-processing pass rewrites those file:// URIs directly in the PDF bytes into internal /GoTo destinations. When that succeeds, you shouldn't see any file:// links in the final PDF at all.

The fact that it works on a fresh test file but not on your existing plan points to an edge case in that post-processing step: it locates the page list by searching for the first occurrence of /Type /Pages in the raw PDF bytes. If your existing plan has embedded images (a logo in the title block, a background image, etc.), their binary content could accidentally contain that same byte sequence and throw off the detection — the conversion would then silently be skipped, leaving the original file:// links in place.

To help narrow this down without needing the file itself:

Does your plan contain any embedded images (logo, background, image in a text/title field)?
Quick test: duplicate the plan, remove any embedded images, re-export to PDF — do the links become internal then?
Roughly how many pages/folios does the project have?
If that's confirmed, it's a real bug in the post-processing step that should get fixed.

Best regards,
Laurent

@kellermorph no I don't speak german.

History
https://github.com/qelectrotech/qelectr … c79f080262
https://github.com/search?q=repo%3Aqele … pe=commits

Salut Laurent !

Indeed there are some embedded pictures in my plan!
But even when removing them the links in PDF stay the same as before. 

I'll try to compile with your patch from above and keep you informed!

For this point so far: Thanks!

I’m old-school when it comes to Linux – I never use spaces in file or directory names, let alone square brackets, or brackets...On Linux and Windows..

filename that does (not) work.qet -> filename_that_does-not-work.qet

It was a bad experience I had back in 2000 with Windows files being read on Linux that has stuck in my mind…

Exemples on my personal wiki on my NAS:

Fichier transféré d'une partition Windows sur une partition UTF-8 ext3:

convmv -f cp1252 -t utf-8 -r --notest <fichier_a_convertir>

Fichier extrait d'une archive:

convmv -f iso-8859-1 -t utf-8 -r --notest <fichier_a_convertir>

Exemples:

enlever espaces dans noms de fichier

for i in *; do mv "$i" "$(echo $i | tr " " "-")"; done

supprimer les majuscules

for i in *; do mv "$i" "$(echo $i | tr A-Z a-z)"; done

for i in *; do mv "$i" `echo $i | tr [:upper:] [:lower:]

I don't think the problem is solved!
The links are generated when the PDF file is created by QET.
Why does QET care about the file name if all links point to a destination within the same PDF file?
The QET-filename shouldn’t matter then!

I don't like restrictions!

Please try my fix in https://github.com/qelectrotech/qelectr … r/pull/784