feat: Document.ToBytesAsync() — in-memory PDF output (3.0.5)#10
Conversation
Adds an in-memory output to the producer side: Pdf.Create(...).AddText(...).ToBytesAsync() returns the PDF bytes without touching disk. PdfWriter was already stream-first (PdfWriter(Stream,...), _buffer.CopyToAsync(_output), and it never disposes _output), so this is pure surface. SaveAsync(string) is reimplemented on top of ToBytesAsync, so the existing SaveAsync tests cover the new method transitively — 100% coverage preserved, no behavior change. Motivation: consumers that need the bytes (e.g. uploading to object storage, building multipart content in tests) currently round-trip through disk; ToBytesAsync removes that. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
@coderabbitai autofix |
There was a problem hiding this comment.
Pull request overview
Adds an in-memory PDF output API (Document.ToBytesAsync) so callers can retrieve rendered PDF bytes without writing to disk, and bumps the package version to 3.0.5.
Changes:
- Introduces
Document.ToBytesAsync()to render a document into abyte[]using an in-memory stream. - Reimplements
SaveAsyncto write the output bytes to disk viaFile.WriteAllBytesAsync. - Updates package version from 3.0.4 → 3.0.5.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| CreatePdf.NET/Document.cs | Adds ToBytesAsync() and rewires SaveAsync implementation. |
| CreatePdf.NET/CreatePdf.NET.csproj | Bumps NuGet package version to 3.0.5. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| public async Task<string> SaveAsync(string? filename = null) | ||
| { | ||
| var path = FileOperations.GetOutputPath(filename); | ||
| await File.WriteAllBytesAsync(path, await ToBytesAsync()); | ||
| return path; | ||
| } |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 50441e7622
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| public async Task<string> SaveAsync(string? filename = null) | ||
| { | ||
| var path = FileOperations.GetOutputPath(filename); | ||
| await File.WriteAllBytesAsync(path, await ToBytesAsync()); |
There was a problem hiding this comment.
Keep SaveAsync streaming to the file
For large bitmap-heavy documents, routing SaveAsync through ToBytesAsync substantially raises peak memory: PdfWriter already buffers the whole PDF internally, then ToBytesAsync copies it into a MemoryStream and ToArray() before the file write starts. A document with long AddPixelText content can therefore require multiple full-size copies of the PDF where the previous File.Create(path) path only copied the writer buffer directly to disk. Keeping SaveAsync on the file-stream writer path (or factoring a shared render-to-stream helper) avoids making normal file saves fail with OOM in cases that previously completed.
Useful? React with 👍 / 👎.
Adds an in-memory output to the producer side so callers can get a built PDF's bytes without going through disk:
PdfWriterwas already stream-first (PdfWriter(Stream, …),_buffer.CopyToAsync(_output), andDisposeAsyncnever disposes_output), so this is pure surface — no rendering changes.SaveAsync(string)is reimplemented asToBytesAsync()+File.WriteAllBytes, so:SaveAsynctests (11 call sites) coverToBytesAsynctransitively → 100% coverage preserved, no new test.SaveAsync.Version bumped to 3.0.5. Verified:
dotnet test -c Release→ 256/256 passed.🤖 Generated with Claude Code