mirror of
https://github.com/qelectrotech/qelectrotech-source-mirror.git
synced 2026-08-15 11:04:12 +02:00
ispyisail
d988054aca
Follow-up to #740, which fixed the slave-side "(n-Xn)" cross-reference label. The master-side item - the small table/cross drawn next to a report or master element, listing where each of its slaves is used - was still missing from DXF export. Measured against examples/ industrial.qet with the PDF export as an oracle (renders the whole scene, so it shows what should be there): before after PDF slave xrefs "(n-Xn)" 41 41 41 (already fixed, #740) folio/position strings 358 403 403 DXF now matches the PDF exactly. ## Why this needed a different approach than #740 The slave label is a plain QGraphicsTextItem - one string, trivial to walk and re-emit as a single DXF TEXT entity, which is what #740 did. The master-side item (CrossRefItem) is not: it paints itself with ~600 lines of hand-written QPainter calls across three modes (drawAsCross/drawAsContacts/drawAsPlcTable), including a header table, contact symbols, and rules. Hand-porting that logic to emit DXF primitives directly would mean maintaining two divergent implementations of the same drawing that have to be kept in sync by hand forever. ## Approach: a QPaintEngine that intercepts CrossRefItem's own paint() DxfPaintEngine/DxfPaintDevice (sources/dxfpaintdevice.{h,cpp}) is a QPaintEngine/QPaintDevice pair - the same mechanism QPrinter and QSvgGenerator use to redirect QPainter output elsewhere. Constructing a QPainter on a DxfPaintDevice and calling item->paint() on it produces DXF entities instead of pixels, using the exact same drawing code that already renders correctly on screen. CrossRefItem::paint() is unmodified. Scope is deliberately narrow - only the QPainter calls CrossRefItem's paint() is observed to make: drawLines -> LINE, drawRects/drawPath's fill case -> outline-only LWPOLYLINE (no HATCH support in v1 - DXF's fill primitive is a separate, more involved entity type; documented as a known limitation rather than attempted here), drawEllipse -> CIRCLE or a flattened polygon for rotated ellipses, drawPath's arc case (from drawArc/drawPie) -> chord-flattened LINE segments, drawPolygon -> LWPOLYLINE, drawTextItem -> TEXT. drawPixmap is intentionally unimplemented (qWarning + skip) since CrossRefItem never calls it - this is not a general-purpose DXF paint engine, and isn't meant to be in this PR. CrossRefItem::paint() is protected, per the normal QGraphicsItem contract - added a small paintForExport() wrapper rather than making paint() itself public, or reaching around access control. ## Explicitly out of scope QetShapeItem::toDXF() and QetGraphicsTableItem::toDXF() (both already implemented and working) are untouched. Rewriting working exporters onto this engine to prove an architectural point would be a large, unrelated diff with no user-visible benefit - if that consolidation is wanted later, it's a separate proposal once this engine has shipped and proven out on the one item that currently has no DXF export at all. ## Testing Built clean on Qt5/Linux. Verified via the GUI export dialog (Fichier > Exporter > DXF) against examples/industrial.qet, 50 folios: export completes without error or crash, all 50 .dxf files are structurally well-formed (balanced SECTION/ENDSEC, single EOF each), and grepping the folio-position pattern gives the before/after/PDF numbers above. Spot-checked several real label strings (e.g. "18-B18", "20-A2") present as TEXT entity values in the output, not just an artifact of the count matching.