Inherits QPaintEngine.
|
| | DxfPaintEngine (const QString &filepath) |
| | DxfPaintEngine::DxfPaintEngine.
|
| bool | begin (QPaintDevice *pdev) override |
| bool | end () override |
| void | updateState (const QPaintEngineState &state) override |
| | DxfPaintEngine::updateState Track the properties this engine cares about. Everything drawn is mapped through the transform in effect at draw time - this is what lets an item's paint() be replayed unmodified at whatever scene position/rotation it actually has, exactly as QPainter does for on-screen painting.
|
| void | drawLines (const QLineF *lines, int lineCount) override |
| void | drawRects (const QRectF *rects, int rectCount) override |
| void | drawEllipse (const QRectF &rect) override |
| void | drawPath (const QPainterPath &path) override |
| | DxfPaintEngine::drawPath Handles drawArc()/drawPie() (QPainterPath::Arc elements - emitted as chord segments, since Createdxf's ARC-equivalent (drawArcEllipse()) only takes an axis-aligned ellipse + angle pair, which doesn't compose with an arbitrary path transform) and fillPath()/generic paths (flattened to polylines).
|
| void | drawPolygon (const QPointF *points, int pointCount, PolygonDrawMode mode) override |
| void | drawTextItem (const QPointF &p, const QTextItem &textItem) override |
| void | drawPixmap (const QRectF &r, const QPixmap &pm, const QRectF &sr) override |
| | DxfPaintEngine::drawPixmap No DXF dialect this old (AC1006, AutoCAD R10 from 1988) has any raster image representation at all – IMAGE/IMAGEDEF wasn't introduced until R2000, over a decade later, and even there the pixels are never embedded, only referenced by external file path. Actually supporting images means upgrading the DXF version target and managing a second file alongside the DXF; until then, this draws a placeholder rectangle outline (the item's own destination rect, mapped through m_world_transform exactly like drawRects() does) instead of silently dropping the item – so its position, size, rotation, and skew all survive the export even though the picture itself can't yet. A fixed, plain pen, not m_pen: an image item has no meaningful pen of its own for this engine to have picked up from a prior updateState().
|
| Type | type () const override |
The DxfPaintEngine class A QPaintEngine that translates the small set of QPainter calls made by QGraphicsItem::paint() implementations (drawLines, drawRects, drawEllipse, drawPolygon/drawPolyline, drawTextItem) into DXF entities written through Createdxf, instead of pixels.
This exists so that an item's existing, already-correct paint() code can be reused unmodified to produce a DXF export: construct a QPainter on a DxfPaintDevice targeting the item, call painter.begin()/end() around item->paint(&painter, ...), and every primitive the item draws becomes a DXF entity at the item's scene position instead of a pixel on screen.
Scope (deliberately not the full QPainter surface - only what QElectroTech's own paint() implementations are observed to call):
- drawLines -> LINE
- drawRects -> LWPOLYLINE (closed 4-point outline; DXF has no filled-rect primitive in the AC1006 dialect this exporter targets, so brush fill is not emitted - see fillPath below)
- drawEllipse -> Createdxf::drawArcEllipse (full sweep) or CIRCLE
- drawPath -> arcs (from QPainterPath::Arc elements, used by drawArc/drawPie) become a sequence of LINE chords; anything else in the path is flattened to polyline segments via QPainterPath::toSubpathPolygons
- drawPolygon -> LWPOLYLINE
- drawTextItem -> TEXT (drawText() calls route through this)
- fillPath -> same outline-only handling as drawRects; no HATCH support in v1 (see design note in the PR)
- drawPixmap -> no raster image entity exists in this DXF dialect at all (see drawPixmap()'s own comment) – draws a placeholder rectangle outline instead, preserving the item's position/size/rotation/skew even though the picture itself can't be included yet
Anything else outside this list (gradients, etc.) is intentionally unimplemented and logs a warning rather than silently producing an incomplete drawing - callers should know immediately if an item they're exporting uses something this engine doesn't cover yet, rather than getting a DXF file quietly missing content.
| void DxfPaintEngine::drawPixmap |
( |
const QRectF & | r, |
|
|
const QPixmap & | pm, |
|
|
const QRectF & | sr ) |
|
override |
DxfPaintEngine::drawPixmap No DXF dialect this old (AC1006, AutoCAD R10 from 1988) has any raster image representation at all – IMAGE/IMAGEDEF wasn't introduced until R2000, over a decade later, and even there the pixels are never embedded, only referenced by external file path. Actually supporting images means upgrading the DXF version target and managing a second file alongside the DXF; until then, this draws a placeholder rectangle outline (the item's own destination rect, mapped through m_world_transform exactly like drawRects() does) instead of silently dropping the item – so its position, size, rotation, and skew all survive the export even though the picture itself can't yet. A fixed, plain pen, not m_pen: an image item has no meaningful pen of its own for this engine to have picked up from a prior updateState().
1.15.0