Open svengeance opened 2 days ago
Hi @svengeance,
that's a good idea! This library has switched from GDI to SkiaSharp before so a weaker coupling would be desirable.
However, there are a few reasons I don't want to implement multiple 2D graphic backends right now:
PDFtoImage
should be the only NuGet package to reference. I want to avoid a situation where you have to pick and choose packages (when you don't know or don't care).SKBitmap
right now. Depending on how this library is split, it might be a breaking change.SKBitmap
and SKCanvas
right now. Might be a hassle to decouple this since it is used to stitch multiple bitmaps together.A compromise might be to split this library into PDFtoImage
and PDFtoImage.Core
. The latter package contains interfaces for the rendering stuff. The former package has adapters for SkiaSharp and the current API as is.
I'll take a look at this. You will have to write your own ImageMagick adapter, however, when this package is split in two.
Greetings David
Fair game of course on implementing our own bindings. I wasn't expecting it to be nonbreaking and a fair amount of work on your end.
Personally I think it might benefit you in the long run as well, as swapping providers might provide some measurable performance or reliability gains in the future, in addition to the consumer benefits of being able to reuse existing image libraries.
Thank you for considering it!
Hey! This library looks amazing, so thank you first off for the hard work.
I was wondering if you'd considered componentizing the rendering pipeline such that we could install separate packages for different providers? For instance,
PDFToImage.Skia
andPDFToImage.ImageMagick
andPDFToImage.ImageSharp
.I'm selfishly asking out of curiosity for my own use-case, where I already have ImageMagick installed, and it would be cool to be able to reuse it. In this same project I was delighted to find Zxing implemented something similar: https://www.nuget.org/packages/ZXing.Net.Bindings.Magick/
Thanks for the consideration!