Summary: The PSA v4 virtual printer architecture (windows.printSupportVirtualPrinterWorkflow) has no documented way to signal the Windows print pipeline to preserve stroked vector paths as elements in the OXPS output. Applications that print via GDI (CorelDRAW, Adobe Acrobat DC, Microsoft Edge) are processed through MXDC, which decomposes every stroked path into a filled outline polygon ("sliver") before the PSA receives the OXPS. This makes PSA v4 unusable as a sole driver for cut-plotter applications, which require single-line centerline geometry, not filled slivers.
Root cause: Legacy V3 GDI drivers could set GDIINFO.ulTechnology = DT_PLOTTER, which caused GDI to call DrvStrokePath with a PATHOBJ (single line geometry) rather than decomposing strokes into filled geometry via DrvFillPath / BRUSHOBJ. PSA v4 has no equivalent capability — it receives post-MXDC OXPS with no hook into the rendering decision.
What applications are affected: Win32 GDI applications including CorelDRAW, Adobe Acrobat DC, Microsoft Edge print, and file explorer PDF print. Other applications such as Adobe Illustrator, AutoCAD are NOT affected and generate OXPS files with stroked paths preserved as XPS Path elements without decomposition.
Requested feature: A documented PSA v4 manifest declaration or PrintDeviceCapabilities capability that signals MXDC to preserve stroked vector paths as
without fill decomposition — equivalent to what DT_PLOTTER achieved in the V3 GDI driver model. Perhaps a new PerferredInputFormat value such as application/oxps/vector added to package appxmanifest
Impact: ARM64 support requires PSA v4. Our V3 plotter driver is built using the WDK toolchain from the Windows XP/7 era which predates ARM64 as a Windows driver platform — no ARM64 target exists in that toolchain. Migrating the V3 driver build to Visual Studio 2022/modern WDK introduces driver loading failures due to certificate compatibility issues with our signing infrastructure. PSA v4, which builds as a standard MSIX application via Visual Studio 2022 with no driver signing requirements, is therefore the only viable ARM64 path — making this stroke preservation gap a blocker for cut-plotter support on ARM64 devices. Cutting-plotters are therefore blocked from fully supporting both AMD64 and ARM64 Windows devices until this gap is addressed. This makes writing a PSA printer driver that supports all applications impossible.
Other Information:
Since v3 drivers have been deprecated, I have spent last 4 months working to upgrade our v3 printer driver to a PSA v4 virtual driver. The device for the driver is similar to the old hp7585 but performs cutting rather than drawing. It only responds to vector commands, absolutely no raster graphics input. There are several popular applications that support the v3 driver (Illustrator, CorelDRAW, SignLab, AutoCAD, Monu-Cad and many other applications I have no control over.) The driver needs lots of custom properties to control the generation of the HPGL input to the device.
The new driver is working well with exception of some applications such as CorelDRAW File-Print, and Edge (open SVG, ctrl-P), right click on pdf file in file explorer-print. Instead of generating single line output per vector which is required, it generates an outline of the line with a width and a fill in the OXPS file that is passed to the driver.
To fix CorelDRAW I was forced to write plugin to export the drawing as an hpgl file, Read the hpgl file. Add the custom printer property processing and recreate the hpgl file with additional product specific commands. You cannot expect applications to support the prerendering of files without a documented way to request the application and the operating system generated vectors vs raster graphic outputs.
I will be releasing this hamstrung version of the PSA driver within a month and it will be available for download at that time or I can provide a preliminary not completely tested version upon request.
Cross post on feedback hub with code: AA10rqr4