| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000340 | QElectroTech | other | public | 2026-09-09 10:29 | 2026-09-25 12:03 |
| Reporter | Alf | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Platform | Windows | OS | Windows 10 | ||
| Summary | 0000340: PDF text appears artificially bold in Adobe Acrobat after migration to Qt 6 | ||||
| Description | Since QElectroTech migrated from Qt 5 to Qt 6, small text in exported PDF files appears excessively thick or artificially bold in Adobe Acrobat Reader at certain zoom levels. When zooming in, the text is rendered correctly. The same PDF is displayed correctly in Google Chrome and PDFX. Disabling text smoothing in Acrobat makes the text excessively thin, while disabling “Enhance thin lines” has no effect. PDF files exported from the previous Qt 5 version did not show this behavior. This appears to be a rendering compatibility issue between the PDF output produced with Qt 6 and Adobe Acrobat Reader. | ||||
| Tags | No tags attached. | ||||
|
|
Thanks for the detailed report, Alf. The "bold at certain zoom levels, correct in Chrome/other viewers, worse with smoothing off" pattern points more toward how Qt6's PDF engine embeds/draws text than toward a QET-specific bug, but I'd like to narrow it down before assuming that. Could you attach: The actual exported PDF (not just the screenshot) — that lets me inspect the font embedding directly. The QElectroTech version you're using (Help > About), and if possible whether you're on the CMake/Qt6 build or an older Qt5 build for comparison. If you can, a minimal test file — a diagram with just one or two text labels, nothing else — so we can tell whether this is specific to certain elements (title block fields, terminal labels, etc.) or happens with any text QET exports to PDF. Which font the affected text uses in your diagram (a default QET font, or a custom one you've set). That should let us determine whether this is something fixable on our side (e.g. how we call QPainter::drawText during PDF export) or an upstream Qt6/Acrobat rendering interaction we'd need to track separately. |
|
|
Thanks for investigating this. I have attached a .zip file containing three files: Test.qet: minimal test project (Created using the QT6 version). Test QT5.pdf: exported using Qt 5.15.19. Test QT6.pdf: exported using Qt 6.11.2. Both PDFs were exported directly from the same Test.qet project and have not been reprinted or modified by another application. The Qt 5 build information is: QElectroTech V 0.200.1-dev Compilation : GCC 16.2.0 Built with Qt 5.15.19 - x86_64 - Date : Sep 4 2026 : 08:35:27 Git Revision : f997550e0723582e765ed36e8188f101364ff545 Run with Qt 5.15.19 using 16 thread(s) CPU : RAM Total : 24 GB RAM Available : 13 GB GPU : GPU RAM : RAM Total : B OS : winnt - x86_64 - Version : Windows 11 Version 2009 - Kernel : 10.0.26200 *** Qt screens *** ( 1 : 1920 x 1080 ) ( 2 : 1920 x 1080 ) The Qt 6 build information is: QElectroTech V 0.200.1-dev Compilation : GCC 16.2.0 Built with Qt 6.11.2 - x86_64 - Date : Sep 9 2026 : 06:12:39 Git Revision : c1f9af85441bb30d3a939bf3df95565e4f2eea65 Run with Qt 6.11.2 using 16 thread(s) CPU : RAM Total : 24 GB RAM Available : 14 GB GPU : GPU RAM : RAM Total : B OS : winnt - x86_64 - Version : Windows 11 Version 25H2 - Kernel : 10.0.26200 *** Qt screens *** ( 1 : 1920 x 1080 ) ( 2 : 1920 x 1080 ) Test QT5.pdf is displayed correctly in Adobe Acrobat Reader. In Test QT6.pdf, the text appears excessively thick at certain zoom levels, although it becomes correct when zooming in. |
|
|
Thanks Alf, this pinpoints it. I compared the font embedding in both PDFs (pdffonts + inspecting the FontDescriptor objects directly): | | Qt5 | Qt6 | |---|---|---| | Embedded font | Tahoma | Arial-0-400 | | StemV | 63.48 | 73.24 (~+15%) | | Ascent | 1000.49 | 905.27 | | CapHeight | 1000.49 | 716.31 | The text in Test.qet uses `font-family:'MS Shell Dlg 2'`, which is a virtual Windows alias for the system dialog font — not a real font name. On your machine that alias normally resolves to Tahoma. Qt5 (GDI-based font matching) resolves it to Tahoma and embeds that font as-is. Qt6 (DirectWrite-based font matching on Windows) resolves the same alias to Arial instead — a different font with noticeably thicker stems (StemV +15%) and different metrics. So this isn't an Acrobat rendering quirk: the Qt6 PDF genuinely contains a different, heavier-stroked font. The fact that it only looks wrong at certain zoom levels in Acrobat is just Arial's hinting behaving differently from Tahoma's at small sizes — Chrome/PDF-XChange happen to mask that difference with their own smoothing. Root cause: Qt6's Windows font backend (DirectWrite) resolves the `MS Shell Dlg 2` system alias differently than Qt5's (GDI) did. This is a known category of behavior change in Qt5→Qt6 Windows font matching, not something specific to how QET calls QPainter::drawText. Likely fix on our side: stop relying on Qt to resolve `MS Shell Dlg 2` at export time, and either map that alias explicitly ourselves (Tahoma/Segoe UI depending on Windows version) or default to a concrete font instead of an ambiguous system alias. Separately, we already bundle libre fonts in our packages precisely to avoid this kind of OS-dependent font resolution — they render identically regardless of platform. We ship both osifont (GPLv3 with font-embedding exception, purpose-built as an open replacement for OS UI fonts like Tahoma/Segoe UI) and the Liberation family (SIL OFL, metric-compatible with Arial/Times New Roman/Courier New). osifont in particular is the more fitting default here, since it's designed to stand in for exactly this kind of system dialog font rather than for Arial. Defaulting QET's text elements to one of these instead of an ambiguous system alias like `MS Shell Dlg 2` would sidestep this whole class of issue rather than just patching this one instance of it. |
|
|
Thanks Alf, your test files made this easy to pin down. A fix is proposed in https://github.com/qelectrotech/qelectrotech-source-mirror/pull/1012 On Windows it tells Qt 6 to use Tahoma for "MS Shell Dlg 2" again, as Qt 5 did. Your existing projects don't need any change. It hasn't been tested on Windows yet. Once a build with this change is available, could you export Test.qet again and say whether the text looks right in Acrobat? |
|
|
Thanks ispyisail! I tested the new build, but unfortunately the text still looks wrong in Adobe Acrobat Reader, but looks good in others PDF apps. The font has changed, so the proposed mapping is clearly being applied. I also compared the two PDFs internally. Both PDFs now embed Tahoma as a CID TrueType font, and the main metrics match: Qt 5 | Qt 6 fixed StemV 63.4766 | 63.4766 Ascent 1000.4883 | 1000.4883 Descent -206.5430 | -206.5430 FontBBox identical | identical However, the CapHeight value is still significantly different: Qt 5: 1000.4883 Qt 6: 727.0508 The embedded font names are also different: Qt 5: Tahoma Qt 6: tahoma-0-400 I extracted both embedded TrueType fonts as well. They contain the same 41 glyphs and have identical horizontal metrics, OS/2, maxp and name tables. However, the embedded font data is not completely identical: the glyf, loca, head and hhea tables differ slightly. Therefore, the Tahoma mapping fixes the font selection, but Qt 6 still embeds or describes Tahoma differently from Qt 5. I have attached the new PDF so that these remaining differences can be investigated. image.png (38,304 bytes) |
|
|
Thanks Alf, that comparison is very useful. The font is now right, so something else in how Qt 6 writes the file makes Acrobat draw it bold. I can't run a current Acrobat here, so could you help with one more test? The zip has your Qt 5 file (A), your new Qt 6 file (B), and five copies of B with one difference each put back to the Qt 5 value (C–G, the letter in the file name says which). Please open each in Acrobat at a zoom where B looks bold, and say which ones look like A. |
|
|
Thanks ispyisail. I tested A–G in Acrobat Reader at a zoom where B looks bold. A looks correct; B and every variant from C through G still look bold. None of those individual changes fixes the problem. I continued isolating the difference. The trigger is an unused PDF/X namespace declaration in the XMP metadata that Qt 6 adds to the PDF: xmlns:pdfxid="http://www.npes.org/pdfx/ns/id/" Removing only that declaration from B fixes its appearance in Acrobat. The test PDF was changed directly: only those 46 bytes were replaced with spaces. Its fonts, drawing instructions and all other bytes remain unchanged. I repeated the same change on a separate 23-page QET PDF that showed the problem, and it also displays correctly. I am attaching QET-340-diagnostic-confirmed.zip with B, the corrected test PDF, a control PDF with the XMP reference removed, the investigation notes and a proposed Qt patch. The 23-page document is not included. In Qt 6.11.2’s PDF code, pdfxid is declared unconditionally, while its GTS_PDFXVersion property is written only for PDF/X-4 output. The proposed change declares the namespace only for PDF/X-4. The patch has not yet been built or tested in Qt; the PDF-level change has been confirmed in Acrobat on both documents. |
|
|
Thank you Alf, that is an excellent find. I checked your corrected file: it differs from B only in that one declaration. QElectroTech now removes the declaration from every PDF it exports, the same way you did: https://github.com/qelectrotech/qelectrotech-source-mirror/pull/1029 I can't run Acrobat here, so once a build with this change is available, could you export Test.qet (and your 23-page project if you can) and check them in Acrobat? Your Qt patch looks right to me. Would you like to report it to Qt yourself (https://bugreports.qt.io), or shall I, crediting you? |
|
|
Thanks for the fix and for crediting me. I’ll test a Windows build containing PR #1029 as soon as one is available. I’ll export both Test.qet and the 23-page project, then check the resulting PDFs in Acrobat Reader at the zoom levels where the problem occurs and report the results here. Please go ahead and report the underlying issue to Qt, crediting me for the diagnosis and Acrobat testing. I can provide the minimal before-and-after PDFs if they would help with the upstream report. |
