u/MadBoyEvo

I saw a lot of projects have started adopting "Open Source Maintenance Fee" which is described here: https://opensourcemaintenancefee.org which was started by a guy who created WiX.

I'm linking all 4 articles I found from him just for the sake of discussion:

• https://robmensching.com/blog/posts/2025/02/26/introducing-the-open-source-maintenance-fee/
• https://robmensching.com/blog/posts/2025/05/12/open-source-maintenance-fee-two-months-in/
• https://robmensching.com/blog/posts/2026/02/04/osmf-v11/
• https://robmensching.com/blog/posts/2026/07/13/eduforcement/

The general idea on the website is this:

>Open Source Software is free, but maintaining an Open Source Project is far from free. We ask a lot of the maintainers of a project, including:

• Triage issues
• Answer questions
• Keep build scripts working
• Update software dependencies
• Track security reports
• Produce new releases
• Tackle spam in the discussion forums and issue trackers
• Maintain domain name registration
• Renew signing certificates
• And many, many other chores
• Clearly, maintainers are vital to the ongoing success of an Open Source Project. The Open Source Maintenance Fee is a simple and sensible way to pay for the time and effort they spend sustaining a project.

>If you, your organization, or your project meets the minimum annual revenue threshold (typically US$10,000) and depends on projects that require an Open Source Maintenance Fee, paying that fee is how you help sustain the projects you rely on.

I guess he touched a problem that was also many times brought by people maintaining the core of the .NET community such as SixLabors ImageSharp, QuestPDF that basically give users everything and get a "Thank you" back by few, and rest silently just uses it in the background. Both SixLabors and QuestPDF has now implemented MIT for Open Source, and if you make profit you have to pay a fee over certain threshold. I don't want to get into details because it's not about that really, but ImageSharp is quite popular and it's enforcement of licenses is affecting some of the PowerSHell modules.

My point is - open source community is a bit tired.

Lately I saw Polly adopting OSMF:

• https://thepollyproject.org/2026/07/14/polly-osmf-announcement.html

>Polly now participates in the Open Source Maintenance Fee (OSMF). Starting November 16, 2026, companies that earn at least US $20,000 from a product or project that uses Polly will be asked to pay a US $20/month maintenance fee to help fund Polly's ongoing upkeep. The source code stays free and open, and individuals, hobbyists, and organizations below the threshold owe nothing. Read the announcement: Introducing the Open Source Maintenance Fee for Polly · Learn about the OSMF · Become a sponsor

I was thinking how this change applies to us as PowerShell community? How do you feel about it? How do you support the big or small projects that help you out? It doesn't seem it's asking that much as 20$/month for a company is peanuts. I guess it's a bit of a logistics problem to get company into sponsoring someone on GitHub, but it is doable.

Would you use a module if it was OSMF? If not, why not?

PS. For full transparency. I have about 80+ PowerShell modules written over the years and just about 7 or so sponsors (that I am really grateful for). I'm not saying I will adopt the OSMF model, I'm just genuinely asking what you guys think.

Hi,

I saw this new community mentioned on X and thought I'd try my luck here and see if there are people interested in parts of my project to gather feedback and potentially find people that have similar interests.

About four years ago I started building a .NET library for working with Word documents (OfficeIMO.Word). I originally maintained the DocX project before it was taken over by Xceed, so I already had some experience in that area.

I originally wrote this mostly for PowerShell users and for my project PSWriteOffice. Trying to combine ClosedXML, ShapeCrawler, OfficeIMO.Word, Sep, Sylvan and a bunch of other libraries into one PowerShell module quickly becomes dependency drama.

So the original goal was much simpler: have one set of compatible libraries covering the formats I needed. It got slightly out of hand since then, mainly thanks to Codex.

OfficeIMO is now a group of .NET libraries for creating, reading, editing, converting and rendering document formats.

It is split into focused NuGet packages, so you install the formats and converters you actually need rather than one enormous package. There are now around 100 projects/packages as part of OfficeIMO.

• It has its own website: https://officeimo.com/
• And browser-based demos: https://officeimo.com/convert/

The current repository covers Word, Excel, PowerPoint, PDF, HTML, Markdown, RTF, OpenDocument, OneNote, Visio, CSV, AsciiDoc, LaTeX, EPUB and several older Office formats.

It also has support for email and related formats/stores including EML, MSG, OFT, TNEF, mbox, PST, OST, OLM, EMLX and Outlook OAB.

Some formats have full authoring and editing APIs, while others are mainly readers or converters.

I try to be clear about that rather than putting the same "supported" label on everything. There are still plenty of missing features and things that may be off, especially in more complicated conversions.

The conversion list is quite long, but the main parts are:

• Word (DOCX, DOC, etc.) can be converted to and from HTML, Markdown, RTF and ODT. It can also be saved as PDF or images.
• Excel (XLSX, XLS, XLSB, etc.) can be converted to and from HTML, CSV and ODS. Workbooks, worksheets and ranges can be saved as PDF, PNG, JPEG, TIFF, WebP or SVG.
• PowerPoint can be converted to and from HTML and ODP. Presentations can be saved as PDF, and slides can be exported as images.
• Markdown can be converted to and from HTML, RTF, AsciiDoc and LaTeX, and saved as PDF.
• HTML can be converted to Markdown, RTF, Word, Excel or PowerPoint, and rendered as PDF, PNG, JPEG, TIFF, WebP or SVG.
• OpenDocument, RTF, OneNote, Visio, EPUB and MHTML also have PDF, HTML or image conversion options depending on the format.
• PDF pages can be rendered directly to PNG, JPEG, TIFF, WebP or SVG.
• PDF can also be converted into Word, Excel, PowerPoint, HTML, RTF, ODT, ODS or ODP. These conversions produce editable content where possible and include a report when something could not be carried over.

OfficeIMO also has its own PDF API for creating, reading and modifying PDFs.

It supports text and image extraction, merging, splitting, page reordering, rotation, forms, annotations, attachments, encryption, signatures, redaction, optimization and image rendering.

Since I wrote this mostly with PowerShell users in mind, dependencies are intentionally limited:

• Word, Excel and PowerPoint use the Open XML SDK for the underlying package format. Legacy binary formats such as .doc, .xls and .ppt are implemented directly without another document library.
• HTML uses AngleSharp and AngleSharp.Css for parsing HTML and CSS.
• Visio uses System.IO.Packaging and nothing else.
• The optional security package uses Bouncy Castle for CMS, X.509 and timestamp-related functionality.

OfficeIMO does not use Microsoft Office or COM automation. It does not start LibreOffice in the background, and HTML conversion does not launch Chromium or another browser process. There is optional Playwright integration if you want to convert a random website to PDF and further play with PDF, but that is explicit opt-in.

The PDF parser, writer and renderer are implemented in OfficeIMO rather than wrapping a third-party PDF engine.

The same applies to the RTF, OpenDocument, Markdown, OneNote, AsciiDoc, LaTeX, CSV, EPUB and legacy Office implementations.

There is also OfficeIMO.Reader, which is basically my C# alternative to MarkItDown. It sits on top of the OfficeIMO libraries, reads all the supported formats through one API, and gives you either structured objects or Markdown output.

• GitHub: https://github.com/EvotecIT/OfficeIMO
• PSWriteOffice: https://github.com/EvotecIT/PSWriteOffice (thin PowerShell wrapper)

If you work with documents in .NET, I'd be interested to hear what you currently use, which formats or conversions give you the most trouble, and what would be useful for me to improve, add or fix long term. Maybe even what other formats should it support, including the legacy ones that are still being in use.

While I started with a much simpler goal for my PowerShell community, my end goal now is basically Aspose Total, but free, open source and MIT licensed with low dependencies.

Hi,

Some time ago I wrote a PowerShell module called FileInspectorX. I had a need to detect file type and estimate how dangerous it is based on well it's extension, content without use of antivirus or virustotal.

Today I've upgraded it with Magika (offline LLM) from Google so it's even better in detecting what we're dealing with.

Usually Install-Module FileInspectorX works and then:

$I = Get-FileInsight -Path "YourFile"

It has multiple views so people can really get what they need. Here's how the default output looks like:

AnalysisComplete               : True
AnalysisIssues                 :
Detection                      : FileInspectorX.ContentTypeDetectionResult
DetectedExtension              : json
DetectedMimeType               : application/json
DetectionConfidence            : Medium
DetectionReason                : text:json
DetectionReasonDetails         : json:object-key-colon
DetectionValidationStatus      : passed
DetectionScore                 : 73
DetectionIsDangerous           : False
Kind                           : Text
Flags                          : None
GuessedExtension               :
ContainerSubtype               :
ScriptLanguage                 :
PeMachine                      :
PeSubsystem                    :
PeKind                         :
ContainerEntryCount            :
ContainerTopExtensions         :
VersionInfo                    :
Signature                      :
EstimatedLineCount             : 369
TextSubtype                    : log
SecurityFindings               : {text:log, log:levels=0/0/6}
SecurityFindingEvidence        :
ScriptCmdlets                  :
TopTokens                      :
Security                       : FileInspectorX.FileSecurity
Authenticode                   :
DotNetStrongNameSigned         :
References                     :
ShellProperties                : {b725f130-47ef-101a-a5f1-02608c9eebac:2, b725f130-47ef-101a-a5f1-02608c9eebac:4, b725f130-47ef-101a
                                 -a5f1-02608c9eebac:10, b725f130-47ef-101a-a5f1-02608c9eebac:12…}
NameIssues                     : None
Installer                      :
Assessment                     : FileInspectorX.AssessmentResult
AssessmentProfiles             : FileInspectorX.MultiAssessmentResult
Secrets                        :
OfficeExternalLinksCount       :
EncryptedEntryCount            :
InnerFindings                  :
ArchivePreviewEntries          :
InnerExecutablesSampled        :
InnerSignedExecutables         :
InnerValidSignedExecutables    :
InnerPublisherCounts           :
InnerPublisherValidCounts      :
InnerPublisherSelfSignedCounts :
InnerExecutableExtCounts       :
Certificate                    :
CertificateBundleCount         :
CertificateBundleSubjects      :
EncodedKind                    :
EncodedInnerDetection          :

PS C:\Users\przemyslaw.klys.EVOTEC> $I.Detection

Extension             : json
MimeType              : application/json
Confidence            : Medium
Reason                : text:json
ReasonDetails         : json:object-key-colon
ValidationStatus      : passed
Sha256Hex             :
MagicHeaderHex        :
BytesInspected        : 4096
GuessedExtension      :
Score                 : 73
IsDangerous           : False
Alternatives          : {FileInspectorX.ContentTypeDetectionCandidate}
Candidates            : {FileInspectorX.ContentTypeDetectionCandidate, FileInspectorX.ContentTypeDetectionCandidate}
LearnedClassification : FileInspectorX.LearnedClassificationEvidence

PS C:\Users\przemyslaw.klys.EVOTEC> $I.Detection.LearnedClassification.Prediction

Provider         : Magika
ModelId          : google-magika/standard_v3_3@5e2f437fb7b7452368c8c1fa9354858f5487a5c4
RawLabel         : json
OutputLabel      : json
Extension        : json
ExtensionAliases : {json}
MimeType         : application/json
Probability      : 0,99811840057373
Threshold        : 0,5
ThresholdMet     : True
PredictionMode   : HighConfidence
OverwriteReason  :
IsText           : True

With view parameter you can choose 'Analysis', 'Detection','Permissions', 'Raw', 'ShellProperties', 'Summary' 'Assesment', 'Installer', 'Policy', 'References', 'Signature'

In other words - find out everything there is to find about the file. Maybe you will find it useful. Depending on file type some of the fields will be missing which is expected.

Sources: https://github.com/EvotecIT/FileInspectorX

It has also C# library/nuget for those dealing with C#, and want to use it as part of their application.

OfficeIMO 😂

OfficeIMO is a project I started around four years ago. It targets net472, net8, net10, and netstandard 2.0.

It initially started with OfficeIMO.Word, as my continuation after the DocX project stopped being free for business use. I needed something I could use myself, especially from PowerShell, so I started building it.

It then got slightly out of control.

OfficeIMO is written in C#, but my end goal was never only to create another set of .NET libraries. I mostly wanted to help close some of the gaps between PowerShell and Python.

Python users have a huge ecosystem of libraries for documents, data conversion and automation. They often take those capabilities for granted. In PowerShell, we are still missing a lot of that - and this ends now 🤣And you .NET users are getting it as well - whether you want it or not 😭

The project is here:

• https://github.com/EvotecIT/OfficeIMO
• https://github.com/EvotecIT/PSWriteOffice - the PowerShell version and thin wrapper around OfficeIMO

I also made a website for it:

• https://officeimo.com/ => has more details then this post and contains a lot of other useful information
• https://officeimo.com/convert/ => a demo working in browser locally (no server side - as the page is currently deployed thru github-pages) so it has it's limits, I may need to improve it further
• https://officeimo.com/benchmarks/ => showcase of Excel/CSV against other libraries

OfficeIMO now includes projects covering things such as:

• Word - DOCX and legacy DOC
• Excel - XLSX and legacy XLS and other formats
• PowerPoint - PPTX and legacy PPT
• Visio
• PDF
• Markdown
• HTML
• OpenDocument - ODT, ODS and ODP
• CSV
• AsciiDoc
• LaTeX
• RTF
• EPUB
• ZIP
• OfficeIMO.Reader
• Google Docs and Google Sheets integrations
• Email formats (OST,PST, EML, MSG etc)
• OneNote work
• and quite a few converters connecting those formats together

And by "support" I do not mean detecting the extension, extracting a bit of text and calling it done.

The main OfficeIMO projects aim to support creating, reading and modifying proper documents end to end.

For Word that means things such as sections, headers and footers, first/odd/even pages, tables, styles, lists, images, fields, TOCs, bookmarks, notes, comments, revisions, mail merge, protection, templates and much more.

Word supports DOCX, but I also added a first-party implementation for the supported legacy DOC format. It can read, write and convert DOC documents without starting Word or LibreOffice in the background.

Excel is similar. It is not just a fast row writer. It includes formatting, tables, formulas, charts, pivot tables, conditional formatting, data validation, templates, headers and footers, protection and other features you would expect from a more complete Excel library.

It also has first-party XLS support. The supported legacy format can be read, written and converted into XLSX workflows.

PowerPoint supports creating and editing actual PPTX presentations, while Visio is implemented from the ground up for VSDX without using a third-party Visio engine.

PDF is also not just DrawString() followed by Save().

OfficeIMO.Pdf is my own parser, writer and renderer. It covers PDF creation, text and table extraction, forms, annotations, bookmarks, attachments, encryption, signatures, page operations, redaction, PDF/A, PDF/UA, Factur-X, ZUGFeRD and managed PNG/SVG rendering.

It still has work to do, because PDF is a monster, but it is not a toy PDF implementation.

The same approach applies to Markdown, RTF, OpenDocument, AsciiDoc, LaTeX, CSV, EPUB and ZIP. Those are first-party implementations rather than wrappers around Markdig, QuestPDF, ImageSharp, SkiaSharp or a collection of unrelated document engines.

Ever since I saw Microsoft MarkItDown in Python, I said to myself:

>I want that in C#, for PowerShell.

That is why I added OfficeIMO.Reader.

You give it a document and it tries to provide one common reading experience, including Markdown output, structured blocks, chunking and diagnostics. It can then be used for search, indexing, AI/RAG workflows or simply reading many formats through one API.

OfficeIMO.Reader already has adapters for formats such as PDF, CSV, HTML, EPUB, OpenDocument, RTF, Visio, AsciiDoc, LaTeX, JSON, XML, YAML and ZIP, on top of the Office formats.

This is only the icing on the cake, though. Reader is built on top of the actual document libraries rather than being the only thing OfficeIMO does.

OfficeIMO.Email handles the normal standalone email formats, and the newer work is moving further into mailbox/container formats such as PST and OST. The goal is the same: proper managed parsing and a useful object model, not shelling out to Outlook. Email started with EML, MSG and TNEF, but now also covers PST, OST, OLM, MBOX, EMLX, Maildir, OAB, ICS, VCF and broader Outlook data. That includes managed PST creation, conversion and verified mutation rather than only extracting a list of messages.

OneNote is another active area. First-party managed implementation for offline .one, .onetoc2 and .onepkg files, including reading, creating, modifying, saving and conversion.

One of the important design choices is keeping dependencies low.

The main external document-related dependencies are basically:

• Open XML SDK for the underlying Word, Excel and PowerPoint package structures
• AngleSharp and AngleSharp.Css for proper HTML and CSS parsing
• YamlDotNet for the YAML Reader adapter

Older targets such as .NET Framework 4.7.2 naturally need some Microsoft/BCL compatibility packages for APIs that are built into newer .NET versions.

But there is no ImageSharp, SkiaSharp (with exception), QuestPDF, Markdig, ClosedXML or another PDF/Markdown/document engine hidden behind OfficeIMO. There is one exception to this which is optional package of HarfBuzz (I am not sure I am ready to maintain the alternative myself) and BouncyCastle (I don't even want to try that).

Most of the parsing, object models, writing, rendering, conversions and format-specific logic is mine.

I also spent a slightly unreasonable amount of time on performance.

For Excel I created reproducible benchmarks against libraries including ClosedXML, MiniExcel, LargeXlsx, SpreadCheetah, Sylvan.Data.Excel, ExcelDataReader and others.

OfficeIMO.Excel tries to combine the more complete feature set people expect from something such as ClosedXML with streaming and direct-writing paths that can compete with libraries focused mainly on speed.

Depending on the workload, it is competitive with or faster than MiniExcel, LargeXlsx and Sylvan-style implementations, while still providing the higher-level Excel features.

CSV got the same treatment.

I benchmarked OfficeIMO.CSV against Sep, Sylvan and other fast CSV implementations, then spent a lot of time reducing allocations and improving parsing, streaming and writing performance.

It was not originally done for the sake of benchmarking. I wanted PowerShell users to be able to process real amounts of data without paying a huge performance penalty.

You just get to benefit from that too 😁

Converters are another large part of OfficeIMO:

• Word to PDF
• Excel to PDF
• PowerPoint to PDF
• HTML to PDF
• Markdown to PDF
• RTF to PDF
• Word to Markdown and Markdown to Word
• Word to HTML and HTML to Word
• Word to RTF and RTF to Word
• Word to ODT and back
• Excel to ODS and back
• PowerPoint to ODP and back
• Excel, Word, PowerPoint, Visio, HTML and PDF to PNG/SVG
• Markdown, HTML, RTF, AsciiDoc and LaTeX conversions

Not every conversion can be perfectly lossless. Converting a fixed-layout PDF back into an editable Word document will always involve decisions and compromises. Where possible, OfficeIMO returns warnings, diagnostics and loss reports rather than silently pretending everything converted perfectly.

If you got this far lemme remind you links, just in case you can't scroll up.

• https://github.com/EvotecIT/OfficeIMO
• https://github.com/EvotecIT/PSWriteOffice - the thin PowerShell layer
• https://officeimo.com/ (website with docs/api/use cases and even in-browser converter without server side)

There is still a lot of work to do, but I thought it was finally time to show it properly.

The README has the detailed feature lists, because putting every supported capability here would turn this post into documentation.

Answering things that may come to your mind after reading this:

Is it complete?

No.

Are all projects equally mature?

Definitely not.

Is there more work to be done?

A lot. But OfficeIMO is trying to be correct and useful for real work. Still needs more performance work, tests, examples and documentation, but the foundations are there. Still needs real world usage. While I do have established base already with 400 stars over the years, so we're not completely new, but the newer projects need real world testing to establish what edge cases there are.

So go ahead use it, roast it, or whatever you like to do to it. Regardless of you guys using it *no offense* 😂 I'm delivering it to PowerShell guys, but you are just here for the ride. It's MIT licensed, and I expect to improve it even further as the time goes by.

Having said that if you can help with improvements, development, sponsorship or just help answering questions if they come. That's all very much appreciated.

I am just myself in this, there's no company backing, no one paying me to create or manage it. No one to hold my hand and say good words of encouragement. Therefore I would appreciate if you take this into consideration before you decide to dive deep and smash me with something heavy. I manage over 100 projects on GitHub, mainly for PowerShell, HomeAssistant and now a bit of C#, and I do it all for free.

Today I would like to reintroduce you to Transferetto v2. Rewritten in C#, with more robust logic and taking care of a lot of pain points around FTP, FTPS SFTP, SCP and SSH. It even has FXP feature and covers common use cases with small amount of cmdlets.

Open source: https://github.com/EvotecIT/Transferetto

I've rewritten old PowerShell only version into C# version so should be faster and more consistent. Added a lot of cmdlets so now it has over 90 useful options.

I tried to automate some of the common use cases but if you fdeel some things are missing let me know.

Enjoy

I've released new version of PowerBGInfo which now adds fancy charts and better visuals and makes it nicer to work with. It also adds ALC so less/none of the conflicts in PS 7.

Couple of images:

- https://github.com/EvotecIT/PowerBGInfo/blob/v2-speedygonzales/Examples/Output/PowerBGInfo.OperationalCharts.jpg?raw=true

- https://github.com/EvotecIT/PowerBGInfo/blob/v2-speedygonzales/Examples/Output/PowerBGInfo.ChartForgeX.Transparent.jpg?raw=true

- https://github.com/EvotecIT/PowerBGInfo/blob/v2-speedygonzales/Examples/Output/PowerBGInfo.Pattern.Lab.jpg?raw=true

The source: https://github.com/EvotecIT/PowerBGInfo

It's kind of complete rewrite and it doesn't require ImagePlayground, DesktopManager modules anymore (it uses their C# libraries under the hood, but doesn't drag them). Here's a sample code (not super pretty on Reddit, but it does work ;)

$white = 'White'
$muted = '#E6D2DCE8'
$panel = '#AC0A101C'
$cyan = '#2DD4BF'
$blue = '#60A5FA'
$green = '#34D399'
$orange = '#FB923C'
$red = '#F87171'
$purple = '#A78BFA'

New-BGInfo -MonitorIndex 0 -Target File {
    New-BGInfoValue -BuiltinValue HostName -Color LemonChiffon -ValueColor $white -FontSize 24 -ValueFontSize 18 -FontFamilyName 'Calibri'
    New-BGInfoValue -BuiltinValue FullUserName -Name 'User' -Color $muted -ValueColor $white
    New-BGInfoValue -BuiltinValue OSName -Name 'OS' -Color $muted -ValueColor $white
    New-BGInfoValue -Name 'Chart mode' -Value 'live metrics + local status' -Color $muted -ValueColor $white

    New-BGInfoChart -Id 'ops-cpu-history' -Title 'CPU history' -Metric CpuPercent -Kind Area -ValueSuffix '%' -Width 360 -Height 145 -LineColor $cyan -FillColor $cyan -TextColor $white -BackgroundColor $panel -ShowGrid -GridColor $muted -GridLineCount 3 -MaxPoints 60
    New-BGInfoChart -Id 'ops-memory-history' -Title 'Memory history' -Metric MemoryPercent -Kind Line -ValueSuffix '%' -Width 360 -Height 145 -LineColor $blue -TextColor $white -BackgroundColor $panel -ShowGrid -GridColor $muted -GridLineCount 3 -MaxPoints 60
    New-BGInfoChart -Id 'ops-system-drive' -Title "$systemDrive used/free" -Kind Donut -Values $diskUsedPercent,$diskFreePercent -Labels 'Used','Free' -ValueSuffix '%' -Width 360 -Height 205 -Palette $red,$green -TextColor $white -BackgroundColor $panel -ShowLegend -ShowPointLegend -LegendPosition Right -ShowDataLabels -Maximum 100 -DonutCenterValue "$diskUsedPercent%" -DonutCenterLabel 'Used' -ShowLatestValue:$false -NoHistory
    New-BGInfoChart -Id 'ops-patch-target' -Title 'Fleet patch compliance' -Kind Bullet -Values 89 -Target 95 -RangeEnds 70,85 -Width 360 -Height 150 -LineColor $orange -TextColor $white -BackgroundColor $panel -Maximum 100 -ShowLatestValue:$false -NoHistory
    New-BGInfoChart -Id 'ops-services' -Title 'Core services' -Kind Pictorial -Values $runningServices,$stoppedServices -Labels 'Running','Other' -Width 360 -Height 145 -Palette $green,$orange -TextColor $white -BackgroundColor $panel -PictorialSymbol Person -PictorialColumns $serviceCount -ShowDataLabels -Maximum $serviceCount -ShowLatestValue:$false -NoHistory
} -FilePath $sampleImage `
    -ConfigurationDirectory $outputDirectory `
    -OutputFileName 'PowerBGInfo.OperationalCharts.jpg' `
    -WallpaperFit Fill `
    -BackgroundColor Black `
    -Color $muted `
    -ValueColor $white `
    -ValueWrapWidth 360 `
    -TextPosition TopLeft `
    -SpaceX 42 `
    -SpaceY 42 `
    -ChartLayout Stack `
    -ChartStackAnchor BottomRight `
    -ChartStackDirection Vertical `
    -ChartStackSpacing 12 `
    -ChartStackOffsetX 32 `
    -ChartStackOffsetY 32

I'm still working on new features and more visuals, and maybe cross-platform but I am not sure this has real use case besides Windows world.

Anyways.. enjoy! Happy to hear feedback, feature requests or bug reports. 

Hi,

A few days ago I open-sourced ChartForgeX, which is a “charting” library written entirely in C# with zero dependencies.

No SkiaSharp. No ImageSharp. Nothing else required for chart generation.

It can generate SVG, PNG and a few other formats, and it also supports HTML interactivity.

Sources, MIT licensed: https://github.com/EvotecIT/ChartForgeX

Full preview/catalog: https://preview.evotec.xyz/?url=https%3A%2F%2Fgithub.com%2FEvotecIT%2FChartForgeX%2Fblob%2Fmain%2FWebsite%2Fstatic%2Fexamples%2Fgenerated%2Fcatalog.html (no tracking or anything, just a previewer for github link)

I keep putting “charts” in quotes because it is not really just a charting library anymore. It can create charts, dashboards, report visuals, badges, summaries, maps, and even topology diagrams.

I built it mainly for two of my other projects that I use a lot around PowerShell:

ImagePlayground https://github.com/EvotecIT/ImagePlayground

This is basically a PowerShell-friendly wrapper around ImageSharp functionality, now connected with ChartForgeX and also with CodeGlyphX, my zero-dependency QR/barcode library: https://github.com/EvotecIT/CodeGlyphX

PowerBGInfo https://github.com/EvotecIT/PowerBGInfo

This is my PowerShell replacement for BGInfo. It lets you control what gets displayed on corporate wallpapers, and now it can include charts as well.

The main reason I created ChartForgeX was that I was tired of wiring together multiple image/chart/rendering engines for different projects and then dealing with dependency conflicts or slightly different behavior everywhere, and if you ever worked with PowerShell dependency hell is real.

At this point there are 40+ chart/visual types, and it is still early.

Happy to hear feedback, ideas, criticism, or use cases. Also happy if someone wants to join and help push it further.

Przemek