GeneratePdf should not close the stream about questpdf HOT 4 CLOSED

This change is implemented and planned to be released in version 2021.04.

@tthiery Thank you for your great suggestion!

from questpdf.

Thank you for your suggestion. Please let me investigate how this aspect was implemented in other libraries so I can confirm what is the best approach.

Regardless of what is correct here. If you are already planning to seek the memory stream back to 0, do you see any advantage of stream over byte array in this particular case? In both cases, entire document data will be placed in memory... Why not to convert such a memory stream into a byte array immediately and use such array somewhere else?

from questpdf.

That suggestion is literally what I did after i posted this. My reports are not too big, so that should work also for a while.

Regards other libraries: a library like this should not assume that it owns the stream. Imagine a multipart email or a network stream where more than one thing is sent.

Keep up the work. Different question: should I be nitpicky about things and give you more such issues?

from questpdf.

I agree with your point of view. The responsibility of managing resources, e.g. closing the stream, lies on the method's caller. The library should not make any additional assumptions. The same approach is present in SkiaSharp - this library does not close the stream, so QuestPDF shouldn't either. The fix is quite simple, I will try to prepare it today and push it into main.

Regards other libraries: a library like this should not assume that it owns the stream. Imagine a multipart email or a network stream where more than one thing is sent.

I am always willing to discuss and improve any design decisions. Working on the library in my spare time is challenging and making everything perfect from the very start is just simply impossible. If you find anything that can make the library better, please don't hesitate and create new issues :)

from questpdf.