Pysar 0.1.53

.NET 10.0 This package targets .NET 10.0. The package is compatible with this framework or higher.
There is a newer version of this package available.
See the version list below for details. 
dotnet add package Pysar --version 0.1.53
                    


                    

                
NuGet\Install-Package Pysar -Version 0.1.53
This command is intended to be used within the Package Manager Console in Visual Studio, as it uses the NuGet module's version of Install-Package. 
<PackageReference Include="Pysar" Version="0.1.53" />
For projects that support PackageReference, copy this XML node into the project file to reference the package. 
<PackageVersion Include="Pysar" Version="0.1.53" />
                    


                            Directory.Packages.props
                        

                    

                
<PackageReference Include="Pysar" />
                    


                            Project file
For projects that support Central Package Management (CPM), copy this XML node into the solution Directory.Packages.props file to version the package. 
paket add Pysar --version 0.1.53
                    


                    

                
#r "nuget: Pysar, 0.1.53"
#r directive can be used in F# Interactive and Polyglot Notebooks. Copy this into the interactive tool or source code of the script to reference the package. 
#:package Pysar@0.1.53
#:package directive can be used in C# file-based apps starting in .NET 10 preview 4. Copy this into a .cs file before any lines of code to reference the package. 
#addin nuget:?package=Pysar&version=0.1.53
                    


                            Install as a Cake Addin
                        

                    

                
#tool nuget:?package=Pysar&version=0.1.53
                    


                            Install as a Cake Tool

Pysar

Pysar is a report engine for .NET: you describe a paginated document once — in XAML markup or with a fluent C# builder — hand it your data, and get back a vector PDF, a set of bitmap pages, or a scrollable, zoomable view inside your application.

This package is the core: the report element tree, data binding, and the SkiaSharp measurement, pagination, rendering and PDF engine. Add Pysar.Xaml for declarative .rxaml markup and one Pysar.<Platform> package for an in-app report view.

var report = ReportBuilder.Create("Hello report")
    .WithPageFormat(new PageFormat { Margin = new Thickness(30) })
    .WithDetail(detail => detail.AddElement(new Text { Content = "Hello from Pysar" }))
    .Build();

await new SkiaReportRenderer().SavePdfAsync(report, "hello.pdf");

What you get

A report is a vertical stack of bands — report header, page header, detail, page footer, report footer — and the detail band is the one that repeats over your data. Inside a band you compose the usual layout primitives: Grid, StackPanel, Frame, Text, Image, plus Repeater for nested master-detail groups.

  • Two authoring styles, one object model. .rxaml markup (package Pysar.Xaml) for reports with a fixed shape, the fluent builder for reports whose structure is computed at runtime. They produce the same tree and can be mixed.
  • Data binding with {Binding}, string formats, value converters and data triggers for conditional formatting. Bindings resolve once, at build time — a report is a document, not a UI.
  • Real pagination. Detail rows are sliced across pages, detail headers can repeat on every page, page bands are re-resolved per page, and PageNumber / PageCount are available to bindings and to an OnPageChangedAsync hook.
  • Vector PDF output — text stays selectable and sharp at any zoom — plus bitmap page rendering at an arbitrary scale.

Everything is measured in points (1/72"). A4 portrait is 595.5 × 842 pt.

Exporting to PDF

SkiaReportRenderer writes the built report as a vector PDF. Build() must run first; a report can only be built once, so build right before you export:

using Pysar.Skia;

report.Build();

// straight to a file
await new SkiaReportRenderer().SavePdfAsync(report, "invoice.pdf");

// or onto any stream, e.g. an HTTP response body
await new SkiaReportRenderer().RenderToPdfAsync(report, httpContext.Response.Body);

// or as an in-memory byte array, e.g. to attach to an email
byte[] pdfBytes = await new SkiaReportRenderer().RenderToPdfBytesAsync(report);

Requirements

  • .NET 10 SDK
  • SkiaSharp native assets for the target platform (the platform packages bring the right ones)
  • A platform implementation of IReportPlatformHandler for file and font access — DefaultReportPlatformHandler reads assets from the application directory, and the platform packages install one for their own asset source

A consumer names at most three packages: Pysar always, Pysar.Xaml for reports written in .rxaml markup, and one platform package for the target UI framework.

Package Responsibility
Pysar.Xaml Declarative report markup: the runtime loader and the code-behind source generator
Pysar.Maui .NET MAUI integration: app-package assets, font registration, PDF export and sharing
Pysar.Avalonia Avalonia integration: avares:// assets, font registration and the report view
Pysar.Blazor Blazor integration: the report viewer component, printing through the browser
Pysar.Wpf WPF integration (Windows only): pack/manifest assets, font registration and the report view

Pysar.Viewer — the framework-neutral viewer logic — is not referenced directly; it arrives transitively with a platform package.

One rule worth knowing up front

Report.Build() mutates the report tree: it resolves bindings, expands repeaters and applies triggers. A Report instance can therefore be built once. Create or load a new instance for each document — building the same one twice throws.

Documentation

License

MIT — see LICENSE.

Product Compatible and additional computed target framework versions.
.NET net10.0 is compatible.  net10.0-android was computed.  net10.0-browser was computed.  net10.0-ios was computed.  net10.0-maccatalyst was computed.  net10.0-macos was computed.  net10.0-tvos was computed.  net10.0-windows was computed. 
Compatible target framework(s)
Included target framework(s) (in package)
Learn more about Target Frameworks and .NET Standard.

NuGet packages (4)

Showing the top 4 NuGet packages that depend on Pysar:

Package Downloads
Pysar.Viewer

Framework-neutral logic for a paginated report viewer: page geometry, zoom, tile planning and the tile cache.
Pysar.Xaml

Runtime XAML loader for Pysar: parses and constructs report objects from declarative markup.
Pysar.Maui

.NET MAUI integration for Pysar: application-package asset access, font registration, PDF export and sharing.
Pysar.Uno

Uno Platform integration for Pysar: application asset access, font registration, a scrollable, zoomable report view, PDF printing and sharing.

GitHub repositories

This package is not used by any popular GitHub repositories.

Version Downloads Last Updated
0.1.63 89 10/1/2026
0.1.56 231 9/20/2026
0.1.53 141 9/20/2026
0.1.46 149 9/18/2026
0.1.44 150 9/16/2026
0.1.41 149 9/15/2026
0.1.38 141 9/14/2026
0.1.34 140 9/13/2026
0.1.31 146 9/11/2026
0.1.24 150 9/6/2026
0.1.10 140 8/30/2026
0.1.0 146 8/30/2026

## Highlights

### `ReportAsset` — a single way to ship report assets
Fonts, images and other report resources can now be declared once as a
`ReportAsset` MSBuild item. The build translates it into each host framework's
own item type (`MauiAsset`, `AvaloniaResource`, `EmbeddedResource`, …), and a new
`EmbeddedAssetFileSystem` reads assets straight from the manifest resources of
assemblies marked with `[PysarAssetSource]`. This means a shared report library
can carry its own fonts and images, and every host can see them.

A new `FallbackFileSystem` chains the platform's own asset source ahead of the
embedded one. All five UI platforms (MAUI, WPF, Avalonia, Uno, Blazor) and both
disk-backed `DefaultReportPlatformHandler` constructors install this chain, so
console apps, workers, server-side rendering and the design-time preview resolve
embedded assets too.

> An `IFileSystem` you pass explicitly is **not** widened — it stays the caller's
> whole answer.

### Trimming support
`Pysar.dll` now embeds an `ILLink.Descriptors.xml`, and `Pysar.Xaml` ships a
`build/Pysar.Xaml.targets` that auto-generates an embedded trimmer descriptor for
any project containing `.rxaml` reports (opt out with `PysarDisableTrimmerRoots`).
See `docs/trimming.md` for WebAssembly trimming behaviour.

### Avalonia: shared renderer and export
New `PysarAvalonia` entry point with a shared renderer/export service and proper
reset logic behind `AppBuilderExtensions`, plus headless Avalonia tests.

### Platform layer refactor
Platform-specific handlers are replaced by `DefaultReportPlatformHandler` backed
by per-platform `IFileSystem` implementations. Desktop/macOS printing and the
macOS pinch monitor moved into `Pysar.Viewer.Platform`, and desktop print logic is
centralised in `DesktopPdfPrint`. Obsolete platform shims were removed.

## Performance

- **`ImageRenderCache`** — a session-scoped cache for image bytes, bitmaps and
 SVGs, wired into both the prefetch and draw paths, with failure tracking and
 deterministic disposal.
- **Faster layout** — `GridLayoutMeasurer`, `StackLayoutMeasurer`, `TextMeasurer`
 and `LayoutEngine` were reworked; `BindingEngine` and `PropertyPathResolver`
 were optimised.
- Removed the `#if DEBUG` `[Pysar.Perf]` zoom instrumentation that logged to the
 console in every consumer's Debug build.

## Fixes

- **Stale pinch-zoom tiles** — rapid pinch commits could leave superseded zoom
 generations in the tile cache, keeping cells from older scales on screen. Only
 the active generation and one bridge generation are kept now.
- **Touch axis lock** — `ReportView` locks a swipe to its dominant axis, so
 scrolling no longer drifts sideways.
- **WPF printing** — the printer now imports the viewer platform namespace it
 needs for the print flow.

## Authoring and tooling

- XAML source generation: richer binding validation with namespace/name
 collection and real diagnostics.
- New API surface: `StyleExtensions.WithStyle`, `AddElements` overloads on
 `ReportContainer`, `PysarBuilder.AddFonts`, and a default `Band` height.
- Quick start and the MAUI/Uno/Avalonia READMEs now document `ReportAsset`
 instead of hand-declared asset items.

## Breaking changes

- **`MeasureAsync` / `ProbeAsync` are now synchronous `Measure` / `Probe`**
 throughout the layout and rendering pipeline. Custom element measurers and any
 code calling the measure API must drop `await` and the `Task` return type.
- **Platform handler types removed** — `MauiReportPlatformHandler`,
 `WpfReportPlatformHandler` and `AvaloniaReportPlatformHandler` are gone; use
 `DefaultReportPlatformHandler` (installed for you by `UsePysar` /
 `AddPysar` / `UsePysar()` on the app builder).
- `IImageCache` / `LocalImageCache` lost members superseded by `ImageRenderCache`.
- `PysarWpf` and `Pysar.Avalonia.ReportView` helper shims were removed.

## Tests

~2,000 lines of new test coverage: embedded-asset and fallback file systems,
per-platform asset chains, pinch-commit placement, image-render caching, PDF
print on desktop, trimmer roots and package layout, and binding validation.