You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add PowerPoint slide rendering via CanvasNet.Pptx - #14
Adds a new, fully-managed PowerPoint slide-rendering backend
(DemaConsulting.DocDown.PowerPoint.Rendering), backed by the DemaConsulting.CanvasNet.Pptx[0.1.0-beta.10] NuGet package (alongside DemaConsulting.CanvasNet and DemaConsulting.CanvasNet.Charts, both pinned
to [0.1.0-beta.10], the latter a transitive dependency of CanvasNet.Pptx).
This follows the same composition pattern already used by DemaConsulting.DocDown.Pdf.Rendering for PDFs (see commit 78df481): the
new PowerPointPageRenderingExtractor (id powerpoint-rendering) delegates
text/title/speaker-notes/image extraction to the existing PowerPointOpenXmlExtractor with rendering suppressed, then rasterizes every
slide to PNG itself via a SlideRenderer seam that isolates CanvasNet types
from the public package surface.
Update (this PR has since evolved further during review): the
PowerPoint COM automation backend (powerpoint-com, PowerPointComExtractor)
has been removed entirely. CanvasNet.Pptx's rendering fidelity was
independently validated as pixel-identical to genuine PowerPoint across 73
real-world slides, and the COM backend was also found to ignore the
requested page range. With no remaining reason to keep Windows-only COM
automation for PowerPoint, powerpoint-rendering is now the sole PPTX
slide-rendering backend (priority 5, below the text-only OpenXml backend's 10 so a plain extraction that does not request pages still prefers the
lighter managed backend, but the automatic choice whenever rendering is
requested, on every platform, since it is the only backend that can provide
rendered pages). AddPowerPoint() now registers
only the managed Open XML backend; callers who want rendered slides register DocDown.PowerPoint.Rendering separately via .AddPowerPointRendering().
Key behavior:
ProbeAvailability() is unconditional (Available(providesRenderedPages: true))
— fully managed, no native stack, no environment probing.
Per-slide fault isolation: a single bad slide is converted to a per-slide ExtractionNote and does not abort the whole extraction. OperationCanceledException always propagates.
A separate failure reading the slide count (document-open/parse failure) is
caught and reported as one note, leaving already-extracted managed content
intact.
Render/page-count functions are injectable via internal constructors so
tests can exercise failure-isolation paths deterministically without
depending on CanvasNet.Pptx faulting on cue.
Wired into the docdown CLI tool via .AddPowerPointRendering(), alongside
the existing .AddPdf().AddPdfRendering().AddOffice() chain; updated stale
"native stack" remarks in Program.cs.
Companion documentation (design, verification, reqstream, sysml2 model,
README, AGENTS.md, user guide) was added/updated to the same depth as the PDF
rendering migration, including new OTS docs for CanvasNet.Pptx and CanvasNet.Charts.
Type of Change
Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to not work as expected)
Documentation update
Code quality improvement
Related Issues
Closes #
Pre-Submission Checklist
Build and Test
Code builds successfully and all tests pass: pwsh ./build.ps1
(926/926 tests passed in the final PowerPoint.Rendering + Office + Tool
suites after the COM-removal round; full-repo baseline unaffected)
Code produces zero warnings
Code Quality
New code has appropriate XML documentation comments
Static analyzer warnings have been addressed
Quality Checks
All linters pass: pwsh ./lint.ps1
(markdownlint-cli2, cspell, yamllint, dotnet format, reqstream, versionmark,
reviewmark, sysml2tools all pass clean)
Testing
Added unit tests for new functionality (golden tests, self-validating
tests, per-slide/count fault-isolation tests via injected delegates, and a
public-API-surface test confirming no CanvasNet.Pptx/CanvasNet types leak
through the package's public surface, including types nested inside
generics/arrays)
Updated existing tests if behavior changed (CLI tool registration-chain
coverage, API example coverage test, determinism test now compares every
rendered slide rather than only the first)
All tests follow the AAA (Arrange, Act, Assert) pattern
Test coverage is maintained or improved
Documentation
Updated README.md
Updated docs/ documentation (design, verification, sysml2 model, user
guide)
Added code examples for new features
Updated requirements.yaml
Additional Notes
Validation commands run (all passed)
pwsh ./fix.ps1 — auto-fixers run.
pwsh ./build.ps1 — clean build, all tests passed, 0 failed.
pwsh ./lint.ps1 — clean pass across markdownlint-cli2, cspell, yamllint,
dotnet format, reqstream, versionmark, reviewmark, and sysml2tools.
Manual end-to-end sanity check: built the docdown CLI tool and extracted src/DemaConsulting.DocDown.Office/Resources/probe.pptx with --pages --dpi 150. The powerpoint-rendering backend was selected
automatically and produced two valid, correctly dimensioned PNG slide
renders under pages/, with the expected pages.renderer = CanvasNet.Pptx (managed) environment fact reported.
Independent fidelity validation: exported all 73 slides from two
real-world decks via genuine PowerPoint COM automation and pixel-diffed
them against CanvasNet.Pptx beta.10 renders at matching resolution — 73/73 pages pixel-identical, max pixel difference 0.
CanvasNet.Pptx observations
PptxDocument.Render has a 3-argument overload, Render(int slideIndex, float dpi, PptxRenderOptions? options = null),
with the third parameter optional; this package's call site omits it
(Render(slideIndexZeroBased, dpi)), relying on the default. The XML doc
comment on SlideRenderer.Render references the full 3-argument shape for
completeness; this was flagged in review as referencing a "nonexistent"
overload, but it was confirmed via reflection against the installed CanvasNet.Pptx beta.10 assembly to be a genuine overload, not an error.
An earlier, visually-based "generic/unstyled font" fidelity concern noted
during initial validation was retracted after a proper pixel-diff
comparison against genuine PowerPoint file-export output (see "Independent
fidelity validation" above): the two renders are pixel-identical, so the
original concern stemmed from comparing against a different rendering path
(a live PowerPoint GUI screenshot) rather than a genuine CanvasNet defect.
Introduce a new, fully-managed PowerPoint slide-rendering backend
(DemaConsulting.DocDown.PowerPoint.Rendering) backed by the newly
released DemaConsulting.CanvasNet.Pptx 0.1.0-beta.9 package, following
the same composition pattern already used by
DemaConsulting.DocDown.Pdf.Rendering for PDFs.
- New PowerPointPageRenderingExtractor (id "powerpoint-rendering",
priority 5) delegates text/title/speaker-notes/image extraction to
PowerPointOpenXmlExtractor with rendering suppressed, then rasterizes
every slide to PNG via a CanvasNet.Pptx-backed SlideRenderer seam.
Priority 5 sits between the COM backend (0, preferred when real
PowerPoint is installed) and the text-only OpenXml backend (10),
making this the automatic choice on Linux/CI/cloud/most dev machines.
- Per-slide and slide-count fault isolation: a single bad slide is
reported as an ExtractionNote and does not abort the whole
extraction; OperationCanceledException always propagates.
- Injectable render/page-count delegates allow tests to exercise
failure-isolation paths without depending on CanvasNet.Pptx faulting
on cue.
- New AddPowerPointRendering() builder extension, wired into the
docdown CLI tool alongside AddPdfRendering(); updated stale
native-stack remarks in Program.cs.
- New DemaConsulting.DocDown.PowerPoint.Rendering.Tests project with
golden, self-validating, fault-isolation, and public-API-surface
(no CanvasNet type leakage) tests.
- Added design, verification, reqstream, and sysml2 model docs for the
new unit and its OTS dependencies (CanvasNet.Pptx, CanvasNet.Charts),
plus README/AGENTS.md/user guide updates describing the new backend
and registration chain.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Updated DemaConsulting.CanvasNet, CanvasNet.Pdf, CanvasNet.Pptx, and
CanvasNet.Charts pins from beta.9 to beta.10. Validated rendering output
for both PDF and PowerPoint backends: full test suite (2264/2264) and
lint pass clean. PowerPoint rendering was additionally cross-checked
pixel-for-pixel against genuine PowerPoint-exported slide images for two
real-world decks (73 slides total) with zero differences.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Updated CanvasNet package pins to 0.1.0-beta.10 (CanvasNet, CanvasNet.Pdf, CanvasNet.Pptx, CanvasNet.Charts).
Validation:
Full test suite: 2264/2264 passed
Lint: clean
Cross-checked PowerPoint rendering pixel-for-pixel against genuine PowerPoint-exported slide images (via COM Slide.Export) for two real-world decks, 73 slides total — zero pixel differences.
An earlier concern about 'generic/unstyled fonts' in the rendered output was investigated and retracted: it was based on a visual comparison against a live PowerPoint GUI screenshot, which (per this ground-truth check) differs slightly from PowerPoint's own file-export rendering path due to editor-view autofit/zoom behavior, not a CanvasNet.Pptx defect.
The determinism assertion compares only page0001.png, although the fixture has two slides and the requirement/documentation claims repeated renders produce byte-identical rendered slides. A nondeterministic second slide would go undetected; compare every generated page (at least both probe pages) between the two runs.
…nderer
Addresses PR review findings on #14:
- Removes PowerPointComExtractor and all COM automation for PowerPoint
(IPowerPointAutomation, PowerPointAutomation, PowerPointComDispatch,
PowerPointComAvailability) now that CanvasNet.Pptx has proven
pixel-perfect fidelity (73/73 slides pixel-identical) and COM was found
to ignore requested page ranges. AddPowerPoint() now registers only the
managed Open XML backend; AddPowerPointRendering() is the sole PPTX
page-renderer.
- Removes the now-unused PowerPoint COM design/verification/reqstream/
sysml2 documentation quadruplets, and updates the shared docs,
.reviewmark.yaml, .cspell.yaml, requirements.yaml, README, and user guide
accordingly. Visio's COM extractor and shared Com/ infrastructure are
untouched.
- Reverts PowerPointPageRenderingExtractor.Priority to 5 (no longer needs
to rank below a COM competitor); removes the direct CanvasNet.Pptx type
leak (unused using + redundant specific catch) from the extractor.
- Widens SignatureTypes in the API-surface test to recurse into generic
arguments and array element types, closing a nested-type detection gap.
- Narrows the DocDown-OTS-CanvasNetCharts OTS requirement to claim only
dependency resolution/portability, not chart-rendering correctness,
matching the evidence the existing probe-deck test actually provides.
- Fixes the determinism test to compare every rendered slide instead of
only the first.
- Updates the PR description to reflect the beta.10 package pin (was
stale at beta.9) and the COM-removal decision.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
COM renderer priority -> resolved by removal, not reordering. CanvasNet.Pptx's fidelity is proven pixel-identical to real PowerPoint (73/73 slides, 0 diff), and PowerPointComExtractor was separately found to ignore the requested page range. PowerPointComExtractor/powerpoint-com and all its COM automation support code are removed; powerpoint-rendering (CanvasNet.Pptx) is now the sole PPTX slide renderer, cross-platform, no Windows/COM dependency at all for PowerPoint.
CanvasNet version drift -> PR description was stale at beta.9; csproj was already correct at beta.10. Rewrote the description.
Nested-type API surface test -> SignatureTypes now recurses into generic args and array element types.
Chart fixture requirement overclaim -> narrowed the OTS requirement wording to what the existing test evidence actually proves, instead of adding a new binary fixture (no precedent for that in this repo).
Nonexistent overload doc claim -> false positive, confirmed via reflection against the real beta.10 assembly; left as-is.
Determinism test gap -> now compares every rendered slide, not just the first.
Full build (2228/2228 tests), fix.ps1, and lint.ps1 all green. Replied in each thread with specifics and resolved them.
…ages note, harden PNG IHDR check, correct backend count and stale COM doc
- PowerPointPageRenderingExtractor.ExtractAsync now skips rasterization entirely
when options.RenderPages is false, so a host registering only
AddPowerPointRendering() (without the managed backend) does not pay a
rasterization cost it never requested.
- DocDownEngine.EmitCoreDerivedNotes now omits its generic "renderer was
available, but no pages were produced" note when the selected backend
already recorded its own note during extraction, so a count-failure
outcome is explained once instead of twice. Applies uniformly across all
backends; verified Pdf.Rendering''s existing tests are unaffected.
Png.cs''s ReadDimensions now validates the first PNG chunk is genuinely
IHDR (ASCII type + declared length 13) before reading width/height,
instead of trusting buffer length alone.
- docs/reqstream/docdown-office.yaml and docs/verification/docdown-office.md:
corrected "six backends" to "five" after the COM extractor removal.
- PowerPointRenderingDocDownBuilderExtensions.cs: reworded the XML doc to
drop the stale "higher-priority COM renderer" reference.
- Added regression tests: render-not-requested writes no pages, exact
single-note assertion for slide-count faults, and two new Core-level
tests proving the generic fallback note is added only in the backend''s
silence.
- Updated design/verification/reqstream docs to reflect the new guard,
suppression behavior, and corrected backend count.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Guard RenderPages - ExtractAsync now skips rasterization entirely when options.RenderPages is false, even when this is the sole registered backend for .pptx.
Suppress duplicate note - DocDownEngine.EmitCoreDerivedNotes (shared Core code) now omits its generic fallback note when the backend already recorded its own note explaining a zero-pages outcome. Benefits Pdf.Rendering''s identical pattern too, with no changes needed there (its tests still pass).
PNG IHDR validation - the test-only Png.ReadDimensions now checks the chunk type and length before trusting width/height.
Backend count - corrected "six" to "five" in the Office reqstream/verification docs.
Stale COM doc - reworded the AddPowerPointRendering XML doc to drop the COM reference.
Full .\build.ps1 run: 2237/2237 tests passed (up from 2228, +9 new regression tests). fix.ps1/lint.ps1 clean. All 5 threads replied to and resolved.
This test still builds a different engine from the CLI: its hand-written chain at line 100 does not call AddPowerPointRendering(), while Program.BuildEngine() now does. Changing the expected count to 7 therefore lets the test pass while no longer detecting a missing PowerPoint-rendering registration in the shipped tool; add the rendering extension to this duplicate chain and assert its powerpoint-rendering descriptor too.
Adds DocDownCore-Extraction-DocDownEngine-SuppressesDuplicateEmptyPagesNote
as a child of DocDownCore-Extraction-Orchestration, and
DocDownPowerPointRendering-PowerPointPageRenderingExtractor-SkipsRasterizationWhenNotRequested
as a child of DocDownPowerPointRendering-BaseSelectedWhenNotRequested, so
both are reachable from a system-level requirement in the trace matrix.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Expand is only one level deep: it yields each generic argument or element type directly instead of expanding that type recursively. A future signature such as IEnumerable<List<CanvasNetType>> would therefore still hide CanvasNetType and let the public-API test pass. Recursively enumerate each argument and element before checking its assembly.
Cover PowerPoint rendering registration in CLI backend test
The CLI's production BuildEngine() now registers AddPowerPointRendering(), but this test's manually duplicated chain still omits it and asserts seven backends. As a result, the new CLI registration is not covered and this test can pass even if the tool stops exposing powerpoint-rendering; add the registration and assert its identifier (and update the count).
Correct documentation for standalone extraction backend selection
docs/design/docdown-powerpoint-rendering.md:132
This documentation says a plain extraction only selects and opens this backend when rendering was requested, but the public extension can be registered by itself and the existing RenderNotRequested test proves it is then selected and delegates content extraction. The no-cost guarantee is specifically that RenderSlidesAsync is skipped; please document that case rather than claiming the backend is never opened.
This acceptance bullet is too broad for the registration API being tested: when AddPowerPointRendering() is the only .pptx backend, the renderer is necessarily selected even with RenderPages == false (the adjacent unit test covers that case). Qualify the managed-backend selection claim to the two-backend configuration and state that the renderer may still be selected alone but must skip rasterization.
…ne test
- DocDownEngine no longer infers or suppresses a 'no pages produced' note from
the backend's note count: it cannot distinguish a backend's own empty-pages
explanation from an unrelated note recorded earlier in the same extraction
(e.g. during delegation to a composed base extractor).
- PowerPointPageRenderingExtractor and PdfPageRenderingExtractor now report
that outcome themselves, from their own selected page/slide count, which is
immune to any unrelated note recorded elsewhere in the sink.
- Updated design/verification/reqstream docs to match, including a new
system/unit requirement per backend for the local empty-selection note.
- Fixed DocDownToolTests.cs's hand-written engine-building chain to include
.AddPowerPointRendering(), restoring coverage of that registration in the
shipped CLI tool.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Each call to Render opens and reparses the entire PPTX, while RenderSlidesAsync invokes the delegate once per selected slide after opening it once more for SlideCount. An N-slide deck therefore pays N+1 full package parses and allocations, which can dominate rendering time and memory for large presentations. Keep one opened document for the count/render loop or introduce a batch/session seam while retaining per-slide fault isolation.
Removing the COM registration here leaves PowerPointOpenXmlExtractor's powerpoint.pageRendering self-test with the message “slide rendering needs the COM backend” (src/DemaConsulting.DocDown.Office/PowerPoint/OpenXml/PowerPointOpenXmlExtractor.cs:111-112). The shipped tool still runs that case via AddOffice(), so --validate reports obsolete COM guidance alongside the managed renderer case; update the skip reason and related documentation to name the optional DocDown.PowerPoint.Rendering package.
🧠 Review effort: Lite
Give feedback about Copilot approvals in this survey to enter a drawing for a $150 gift card.
VisioComExtractor.RenderPagesAsync now reports its own explanatory
note when the automation session exports zero pages, mirroring the
local empty-selection reporting already used by the PowerPoint and
PDF rendering backends. Core cannot distinguish this renderer's own
explanation from an unrelated note recorded elsewhere in the same
extraction, so each backend must report this itself.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
These updated remarks say the managed backend “always records” a note when rendering is requested, but AddPowerPoint() now registers only PowerPointOpenXmlExtractor: that extractor reports an unavailable environment fact and Core emits the note. Please describe the managed-only behavior accurately so the public API documentation does not attribute rendering-failure reporting to the wrong component.
AddPowerPoint() now removes one backend from AddOffice(), but OfficeDocDownBuilderExtensions still tells consumers that PowerPoint and Visio each register two backends, says a spreadsheet-only host registers six, and prints 6 in its public example. The updated registration test does not correct these generated API remarks; update the Office registration documentation to the new five-backend composition.
This new project-reference block leaves stale PowerPoint COM claims in the surrounding tool project documentation (the comments above and below still describe “PowerPoint COM backends”). Since this PR removes powerpoint-com and the PowerPoint automation code, update those comments to mention only the remaining Visio COM backend and the managed PowerPoint rendering package.
This updated XML documentation says every backend in the tool is fully managed and runtime-identifier agnostic, but the same registration chain includes the Windows-only visio-com backend (Program.cs:229-233). Please scope this claim to the PDF/PowerPoint rendering backends or explicitly exempt Visio COM so the tool's published documentation remains accurate.
🧠 Review effort: Lite
Give feedback about Copilot approvals in this survey to enter a drawing for a $150 gift card.
PdfPageRenderingExtractor.ExtractAsync now guards the call to
RenderPagesAsync on options.RenderPages, mirroring the guard already
present in PowerPointPageRenderingExtractor. Previously a host that
registered only AddPdfRendering() got page images for a plain
extraction request, violating the options contract. Added a
regression test and matching reqstream/design/verification updates.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This risk-control statement overclaims the no-render path: if a host registers only AddPowerPointRendering(), this backend is selected and still opens/parses the document through the delegated Open XML extractor even when RenderPages is false. The implementation and unit test only guarantee that slide rasterization is skipped, not that the backend does no work; describe that distinction here.
Update stale architecture overview after COM removal
docs/design/introduction.md:244
This updated paragraph says PowerPoint no longer has a COM backend, but the preceding package overview in the same design document still says Com contains helpers shared by PowerPoint and Visio and describes two duplicated probes. That leaves the published architecture narrative internally contradictory after the removal; update the earlier overview in this change as well.
Removing the COM factory here leaves the delegated PowerPointOpenXmlExtractor's XML documentation and self-test skip reason stale (PowerPointOpenXmlExtractor.cs:23 and :112 still say slide rendering needs the COM backend). After this change the supported renderer is DocDown.PowerPoint.Rendering, so generated API docs and --validate output give a false explanation. Update those strings to reference the managed rendering package.
Update dependency comments after PowerPoint COM removal
The new project reference is accompanied by neighboring comments that still describe PowerPoint COM as part of the tool's dependency graph (:121-123 and :132-135). This PR removes that backend, so those comments are now false and can mislead publish/native-asset audits; update them to mention only the remaining Visio COM backend and the managed PowerPoint renderer.
This expected set now correctly contains five backends, but OfficeDocDownBuilderExtensions.cs:39-54 still says PowerPoint and Visio each register two backends and shows an example count of six. Since AddOffice no longer registers powerpoint-com, those public API docs advertise a nonexistent backend and incorrect count; update the registration-seam documentation as part of this removal.
🧠 Review effort: Lite
Give feedback about Copilot approvals in this survey to enter a drawing for a $150 gift card.
- PowerPointDocDownBuilderExtensions: the managed backend's XML doc
no longer attributes rendering-failure note reporting to itself;
Core emits that note from the environment facts the backend reports.
- OfficeDocDownBuilderExtensions: corrected the backend count and
composition description now that AddPowerPoint() registers one
backend, not two (AddOffice() registers five, not six).
- DemaConsulting.DocDown.Tool.csproj: removed stale/duplicate comments
claiming a PowerPoint COM backend, which this PR removed; the
remaining comment names only the Visio COM backend.
- Program.cs: scoped the fully-managed/runtime-identifier-agnostic
claim to exclude the Visio COM backend registered via AddOffice().
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Removing the PowerPoint COM registration leaves the Open XML backend's self-test message stale: PowerPointOpenXmlExtractor.GetSelfTestCases() still reports powerpoint.pageRendering as skipped because “slide rendering needs the COM backend.” The tool now registers AddPowerPointRendering(), so docdown --validate will show obsolete guidance even though the managed renderer's own round-trip test passes. Update that skipped-case message (and its related XML documentation) to refer to the optional DocDown.PowerPoint.Rendering backend instead of COM.
🧠 Review effort: Lite
Give feedback about Copilot approvals in this survey to enter a drawing for a $150 gift card.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull Request
Description
Adds a new, fully-managed PowerPoint slide-rendering backend
(
DemaConsulting.DocDown.PowerPoint.Rendering), backed by theDemaConsulting.CanvasNet.Pptx[0.1.0-beta.10]NuGet package (alongsideDemaConsulting.CanvasNetandDemaConsulting.CanvasNet.Charts, both pinnedto
[0.1.0-beta.10], the latter a transitive dependency ofCanvasNet.Pptx).This follows the same composition pattern already used by
DemaConsulting.DocDown.Pdf.Renderingfor PDFs (see commit78df481): thenew
PowerPointPageRenderingExtractor(idpowerpoint-rendering) delegatestext/title/speaker-notes/image extraction to the existing
PowerPointOpenXmlExtractorwith rendering suppressed, then rasterizes everyslide to PNG itself via a
SlideRendererseam that isolates CanvasNet typesfrom the public package surface.
Update (this PR has since evolved further during review): the
PowerPoint COM automation backend (
powerpoint-com,PowerPointComExtractor)has been removed entirely. CanvasNet.Pptx's rendering fidelity was
independently validated as pixel-identical to genuine PowerPoint across 73
real-world slides, and the COM backend was also found to ignore the
requested page range. With no remaining reason to keep Windows-only COM
automation for PowerPoint,
powerpoint-renderingis now the sole PPTXslide-rendering backend (priority
5, below the text-only OpenXml backend's10so a plain extraction that does not request pages still prefers thelighter managed backend, but the automatic choice whenever rendering is
requested, on every platform, since it is the only backend that can provide
rendered pages).
AddPowerPoint()now registersonly the managed Open XML backend; callers who want rendered slides register
DocDown.PowerPoint.Renderingseparately via.AddPowerPointRendering().Key behavior:
ProbeAvailability()is unconditional (Available(providesRenderedPages: true))— fully managed, no native stack, no environment probing.
ExtractionNoteand does not abort the whole extraction.OperationCanceledExceptionalways propagates.caught and reported as one note, leaving already-extracted managed content
intact.
tests can exercise failure-isolation paths deterministically without
depending on CanvasNet.Pptx faulting on cue.
docdownCLI tool via.AddPowerPointRendering(), alongsidethe existing
.AddPdf().AddPdfRendering().AddOffice()chain; updated stale"native stack" remarks in
Program.cs.Companion documentation (design, verification, reqstream, sysml2 model,
README, AGENTS.md, user guide) was added/updated to the same depth as the PDF
rendering migration, including new OTS docs for
CanvasNet.PptxandCanvasNet.Charts.Type of Change
Related Issues
Closes #
Pre-Submission Checklist
Build and Test
pwsh ./build.ps1(926/926 tests passed in the final PowerPoint.Rendering + Office + Tool
suites after the COM-removal round; full-repo baseline unaffected)
Code Quality
Quality Checks
pwsh ./lint.ps1(markdownlint-cli2, cspell, yamllint, dotnet format, reqstream, versionmark,
reviewmark, sysml2tools all pass clean)
Testing
tests, per-slide/count fault-isolation tests via injected delegates, and a
public-API-surface test confirming no CanvasNet.Pptx/CanvasNet types leak
through the package's public surface, including types nested inside
generics/arrays)
coverage, API example coverage test, determinism test now compares every
rendered slide rather than only the first)
Documentation
guide)
Additional Notes
Validation commands run (all passed)
pwsh ./fix.ps1— auto-fixers run.pwsh ./build.ps1— clean build, all tests passed, 0 failed.pwsh ./lint.ps1— clean pass across markdownlint-cli2, cspell, yamllint,dotnet format, reqstream, versionmark, reviewmark, and sysml2tools.
docdownCLI tool and extractedsrc/DemaConsulting.DocDown.Office/Resources/probe.pptxwith--pages --dpi 150. Thepowerpoint-renderingbackend was selectedautomatically and produced two valid, correctly dimensioned PNG slide
renders under
pages/, with the expectedpages.renderer = CanvasNet.Pptx (managed)environment fact reported.real-world decks via genuine PowerPoint COM automation and pixel-diffed
them against
CanvasNet.Pptxbeta.10 renders at matching resolution —73/73 pages pixel-identical, max pixel difference 0.
CanvasNet.Pptx observations
PptxDocument.Renderhas a 3-argument overload,Render(int slideIndex, float dpi, PptxRenderOptions? options = null),with the third parameter optional; this package's call site omits it
(
Render(slideIndexZeroBased, dpi)), relying on the default. The XML doccomment on
SlideRenderer.Renderreferences the full 3-argument shape forcompleteness; this was flagged in review as referencing a "nonexistent"
overload, but it was confirmed via reflection against the installed
CanvasNet.Pptxbeta.10 assembly to be a genuine overload, not an error.during initial validation was retracted after a proper pixel-diff
comparison against genuine PowerPoint file-export output (see "Independent
fidelity validation" above): the two renders are pixel-identical, so the
original concern stemmed from comparing against a different rendering path
(a live PowerPoint GUI screenshot) rather than a genuine CanvasNet defect.