Summary
When converting a DWF (V06.20, published from AutoCAD 2023) to PNG/PDF/SVG, the solid area fills on two elevation sheets render as pure black, instead of the light grey they should be. The black masses cover the facade linework, making the sheets unusable. 8 of the 10 sheets in the same file convert perfectly.
The fill colour appears to be lost while parsing the W2D stream — not during rasterization. See the SVG evidence below.
Environment
aspose-cad26.6.0 (Python via .NET)- Python 3.12.4
- macOS 14 (Darwin 23.6.0), Apple Silicon (arm64)
- Licensed (Professional, temporary licence) — not evaluation mode
File
InitialDesignReport.dwf— attached- Header:
(DWF V06.20) - Produced by:
AutoCAD 2023 - English 2023 (24.2s (LMS Tech)) - 10
com.autodesk.dwf.ePlot_*sections (sheets), A2 (594×420 mm) and A0 (1189×841 mm) - Affected sheets/layouts:
ELEVATION-01andELEVATION-02 - Unaffected:
SECTION,GROUND,FIRST,MEZZ,ROOF,ROOF (2),3D,SET VA
Expected vs actual
The DWF contains AutoCAD’s own thumbnail for each sheet (ImageResource role="thumbnail" in each descriptor.xml). Extracting the thumbnail for ELEVATION-01 shows the intended appearance: light grey walls with clearly visible window openings and glazing. The sheet’s own legend confirms it — the finish is listed as “STONE PAINT (OFF WHITE)”.
Aspose.CAD instead renders those areas as solid black, hiding the windows.
Measured dark-pixel fraction (luminance < 60, both normalised to 240×170):
| Sheet | AutoCAD thumbnail | Aspose.CAD output | Delta |
|---|---|---|---|
| ELEVATION-01 | 2.1 % | 14.2 % | +12.1 % |
| ELEVATION-02 | 2.0 % | 13.9 % | +11.9 % |
| GROUND (for contrast) | 2.7 % | 0.1 % | −2.5 % |
Key evidence — the colour is lost at parse time, not at rasterization
Exporting the same sheet to SVG and counting fill attributes:
6124 fill="#000000"
2734 fill="none"
No grey value is present anywhere in the vector output. Since SVG preserves vector colour, this indicates the fill colour is never read from the W2D stream — it defaults to black. This also explains why PNG, PDF and SVG all produce the same wrong result, and why no rasterization option can correct it.
Reproduction
import aspose.cad as cad
from aspose.cad.imageoptions import PngOptions, CadRasterizationOptions
ro = CadRasterizationOptions()
ro.layouts = ["ELEVATION-01"]
ro.page_width = 594 / 25.4 * 300 # A2 @ 300 DPI
ro.page_height = 420 / 25.4 * 300
opts = PngOptions()
opts.vector_rasterization_options = ro
with cad.Image.load("InitialDesignReport.dwf") as img:
img.save("ELEVATION-01.png", opts)
Already ruled out
None of the following changed the result:
| Attempt | Result |
|---|---|
ro.content_as_bitmap = True |
still black |
ro.draw_type |
already USE_OBJECT_COLOR (default 0) |
ro.quality.hatch = RasterizationQualityValue.HIGH |
still black |
PdfOptions instead of PngOptions |
still black |
SvgOptions |
still black (see evidence above) |
DwfLoadOptions.data_background_color |
API rejects aspose.pydrawing.Color — TypeError: can't build Color value from 'aspose.pydrawing.Color' (possibly a separate binding issue worth checking) |
Questions
- Is this a known defect in W2D/DWF solid-fill colour parsing?
- Can it be fixed, and if so which release should we target?
- Is there any interim workaround that recovers the true fill colour?
We are evaluating Aspose.CAD for a production on-premise pipeline and this is the one blocker. Our temporary licence expires 2026-08-27, so guidance on timing would be very helpful.