search

Didstopia / PDFSharp

A .NET Standard 2.0 library for reading, writing and editing PDF files.
MIT License
52 stars 18 forks source link

Fork Intentions #16

Closed ronnyek closed 6 years ago

ronnyek commented 6 years ago

So I've developed code against PDFSharp for a few years and ultimately what it does, it does well. I don't mean to sound ungrateful, but seems like empira is in maintenance mode.

I've wanted to make fixes to this code base but with the number of outstanding pull requests, I'm not confident they will ever accept them. I'm curious if you've ever thought about just making this a REAL fork, one we can clean up and fix... and be better stewards of the code (actually accept pull requests and progress the library forward)

Dids commented 6 years ago

The initial reason for this fork was to have a .NET Standard 2.0 library available, mainly for just reading PDFs.

That said, I'm all up for further developing this as an actual fork (or would it then be more than just a fork?). I'd also love to bring in more people to review & merge PRs, so it wouldn't just be up to me.

Just for reference, I've been developing/using this hand in hand with another library called PDFReader, which I'm primarily using with Xamarin.
Additionally, I've been working on a fork of EpubReader, to eventually bring all of these together in a single, cross-platform (and OSS) document reader/handler library. The resulting library is still in private development, but the plan is to release it to the public once it's more functional/mature.

Sorry for the wall of text, just figured I'd go all out on why this fork exists etc. :)

ronnyek commented 6 years ago

No, this answers my question. I've attempted to contribute code back to empira, and had very little luck doing so. At the end of the day, I'd be lying if I said I wasn't completely frustrated with the lack of open source options for .net core world.

Ultimately I think there's a lot of room for improvement in empira codebase as its a legacy and lots of old code in there, but I think it does what it does well, and do think its a good basis... I just can't afford continue to wait months/years to get the next beta, when it still doesn't fix a lot of outstanding stuff

I'm more than happy to contribute... I was inclined to port / pull request migradoc in for feature parity in the other versions, but ultimately I think that stuff should be refactored into something a bit more consumable

tudorserbanconnatix commented 6 years ago

Here's what I've been working on: https://github.com/tudorserbanconnatix/MigraDoc It's a very basic change to MigraDoc that involved retargeting all projects to .NET Standard and referencing this fork of PDFSharp instead of the original, plus a couple of fixes.

Dids commented 6 years ago

@ronnyek Any further reason to keep this issue open?

ronnyek commented 6 years ago

nope... I had effectively used my own fork after your suggestion it remained separate. I've considered building a completely new framework for basically generating "templates" to make it significantly easier to design docs, and begin to support a designer of sorts... we've still got places we'd like to have equivalent of reports ideally based on templates.

Back to topic though, by all means this is not necessary to stay open