Pysar 0.1.41

.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.41
                    


                    

                
NuGet\Install-Package Pysar -Version 0.1.41
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.41" />
For projects that support PackageReference, copy this XML node into the project file to reference the package. 
<PackageVersion Include="Pysar" Version="0.1.41" />
                    


                            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.41
                    


                    

                
#r "nuget: Pysar, 0.1.41"
#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.41
#: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.41
                    


                            Install as a Cake Addin
                        

                    

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


                            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 94 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 142 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 141 8/30/2026
0.1.0 146 8/30/2026

## Highlights

### Uno integration: a real entry point

Registering Pysar in an Uno application is now a single call on `Application`, and it works the same
way from every head (WebAssembly, Desktop, Android, iOS, WinAppSDK) — `OnLaunched` is the one place
they all run through.

```csharp
protected override void OnLaunched(LaunchActivatedEventArgs args)
{
   this.UsePysar(typeof(App).Assembly, pysar => pysar
       .AddFont("Fonts/Ubuntu-Regular.ttf", "Ubuntu")
       .AddFont("Fonts/Ubuntu-Bold.ttf", "Ubuntu", FontStyle.Bold));
}
```

- `ApplicationExtensions.UsePysar(...)` and `UsePysarAsync(...)` — the latter preloads
 `ms-appx:///` assets for applications that ship them as `Content` rather than `EmbeddedResource`.
- `assetAssembly` is required: on the WebAssembly head the entry assembly is the head project, not
 the application project the assets are packaged into.
- Registration moved into `UnoRegistration`; `PysarUno` now exposes `PlatformHandler` /
 `ExportService` and resets the export service on re-registration.

### Ctrl+wheel and trackpad pinch zoom the report, not the page (browser head)

`ReportView` has always zoomed on Ctrl+wheel and marked the event handled, but on a browser head
that changed nothing visible: "handled" is a managed routing flag, while page zoom is a DOM default
action that only `preventDefault` on a non-passive listener stops. The reader got a scaled page and
a report that never moved — and the trackpad pinch went with it, since Chrome and Safari deliver it
as a wheel event with `ctrlKey` set.

`UsePysar` now installs a small embedded script, imported from a data URL, so a consuming
application adds one call and no files. Opt out with `suppressBrowserZoom: false` to keep the
browser's own zoom as an accessibility affordance.

Suppression covers the whole Uno canvas: Uno draws the entire application into a single canvas, so
the DOM cannot tell the report from the toolbar beside it. Anything on the page outside that canvas
keeps the browser's zoom.

### Measure probe caching

New `MeasureContext` and `LayoutEngine.ProbeSizeAsync` cache probe measurements, and
`GridLayoutMeasurer` / `StackLayoutMeasurer` now measure through probes instead of re-measuring the
same subtree repeatedly — a large drop in repeat measures on nested layouts.

### A readable diagnostic for the SkiaSharp native/managed split on WebAssembly

An Uno browser head pulls `SkiaSharp.NativeAssets.WebAssembly` through
`Uno.WinUI.Runtime.Skia.WebAssembly.Browser`, which asks for the 3.119 line, while Pysar renders
through 4.151. NuGet resolves one managed SkiaSharp and one native archive, and the two no longer
agree.

Every other platform reports that split as a startup exception with a message of its own.
WebAssembly links the native side statically at build time, so it surfaces instead as a wall of
`wasm-ld: undefined symbol: sk_*` lines naming entry points the application never wrote, with
nothing pointing at the version that caused them.

The check now ships as `buildTransitive`, so it reaches consumers who referenced `Pysar.Uno` or
`Pysar.Blazor` rather than `Pysar` itself — those are the ones who end up on a browser head.
Declaring a dependency on the native package would fix it silently, but it is a 67 MB download
charged to every WPF, console and Uno desktop consumer that will never link a wasm binary.

## Breaking changes

- `PysarUno.Use(...)` and `PysarUno.UseAsync(...)` are removed. Use `Application.UsePysar(...)` /
 `UsePysarAsync(...)` instead.

## Other

- Docs updated: root `README.md`, `src/Pysar.Uno/README.md`, `docs/quick-start.md`.
- New `AGENTS.md`; added `opencode.json`.
- Tests: `UnoRegistrationTests`, `MeasureProbeCachingTests`, and a new `PackageLayoutTests`
 assertion for the `buildTransitive` payload.

**Full Changelog**: https://github.com/MriyaLab/Pysar/compare/v0.1.38...v0.1.42