PrawnPDF 2026 - Minimal Maintenance Reboot? #1386
Replies: 5 comments 8 replies
-
|
Getting prawn "up to shape" would be a win-win for the users of prawn; naturally it takes Having said that, I personally decided some time ago to transition all my use cases for The main reason I am using hexapdf is that hexapdf seemed more active; the documentation For users of prawn in general, though, it would still be a net win-win as it is more competition - and Being a maintainer for many years is not a whole lot of fun - I have noticed this myself, Considering that your time is probably very limited, I would actually just aim for a By the way, if even one solid release may be too much time investment, Anyway, TL;DR - give it a try for a while. I am sure many more folks will Edit: Actually, documentation may be even more important than code improvements; It would also be great if we'd have something in ruby to work with epub files and |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for sharing your thoughts! While I tried to support the transition to the core team to maintain things, after the 2.0.1 release literally a decade ago I had stepped away and didn't provide much in the way of guidance on how to move forward. The team got a few more releases out and Alex in particular has kept the lights on in recent years, but to my knowledge it's not like we've got a handbook somewhere covering maintainer responsibilities, and that's more-or-less what I'd like to build. And then we'd figure out how to get a couple releases out and put that handbook through its paces, and see if we can get a volunteer or two from existing committers (or a sufficiently motivated/trustworthy Ruby dev who is either already working on F/OSS elsewhere or is in a good place to learn) to do a "supervised" release where we can have them try to make sure it's possible for a gem to ship without Alex or I literally being the one to do it. It's just a thought as a starting point, but it seems like the kind of work nobody else is going to do if Alex or I don't. And he's already done plenty, so I'd not want to put him on the hook for work he's not up for. . . . From there, I believe HexaPDF is a good replacement for those who can use it under its licensing terms. @gettalong has contributed so much to PrawnPDF over the years, and that's definitely the technically superior project that benefits from not having to invent it all the first time around (technically true of PrawnPDF as well as I "reinvented" PDF::Writer but there was a much larger functionality gap there, whereas HexaPDF is more of an architectural improvement to my knowledge) But PrawnPDF is the only pure Ruby option that's not copyleft for those using it (even though it must be copyleft compatible itself), and does not require a commercial license. And so until an alternative comes along with equivalent terms, there's still a gap. . . . I also (eventually, some time, maybe never) in the future would love to build a high level system built on top of PrawnPDF that's actually focused on document authoring and layout rather than PDF specifically. That in theory could have a swapped out backend (either PrawnPDF or HexaPDF), but in practice I'd hesitate to build on top of HexaPDF alone because of its licensing, or PrawnPDF alone because of its current state of maintenance. But that's only a theoretical future goal. What I'm really trying to do is see if I can find a simple way to clean up a mess I left a decade ago by not setting the project up to be properly operationally independent (and instead just trusted a couple of very helpful people to keep things moving despite having to crawl through thornbushes just to keep things moving) |
Beta Was this translation helpful? Give feedback.
-
|
This may be a bit of a stretch considering the work involved, but: One benefit to a pure ruby implementation is the ability to more easily port it to MRuby. I'm actively working on a cross-platform gui implementation in MRuby, and while not the goal of the project itself, one of my personal goals is to make competitive, MIT licensed, cross-platform implementations of the major players, (Photoshop/Acrobat/Excel/etc). I'm currently cutting the library's teeth on a MIT licensed Photoshop clone for a few weeks with a lot of progress, however:
If anyone were interested in a big push toward the above effort, I could see a lot of value not only in porting to MRuby, but also extending capabilities of PrawnPDF (reading/editing). As far as I know, an MIT licensed PDF editor would be pretty awesome. Even being to export the photoshop clone's project to PDF would be super. I think that if this sort of effort is something that anyone has an appetite for, I'm already deeply engaged, and am happy to collaborate; it will definitely require some synchronized conversations though. For reference I'm attaching the current progress on the image editor: |
Beta Was this translation helpful? Give feedback.
-
|
It seems like something that'd be quite interesting even as a proof of concept. You're absolutely right, an embeddable PrawnPDF is likely more powerful than most other alternative PDF libraries in many languages. And when it comes to this project in particular it's not just pure Ruby, it has no third party runtime dependencies, which I imagine helps. (There's nothing in theory stopping all of the subprojects from being bundled together in one gem/repo) |
Beta Was this translation helpful? Give feedback.
-
|
I proved out a small integration with the app I'm working on. I really only focused on producing an image and using PrawnPDF to embed it, but I ran into some changes. For this example, I combined the projects together and just wanted to get them compiling. I removed the In MRuby, all gem functionality is added to the top level, when dependencies are compiled into the same app, they should all be available. However, MRuby seems to focus on minimum dependencies, so typical stdlib stuff is usually provided by mrbgems. Here's a few deps I ran into needing.
buffer = StringIO.new
def buffer.<<(input)
self.print(hello)
self
end
I also removed the use of My binary also includes full-core, a Pathname implementation, and supports I'm probably missing some things, but the gist is to try to remove some of the nicer extras in favor of a more minimal binary if possible. I'm happy to help discuss moving this to an mgem or set of mgems, if anyone is interested in that kind of effort. |
Beta Was this translation helpful? Give feedback.
-
|
Embedding prawn + mruby would open up interesting possibilities. I'd love to try a branch 👀 (Long fan of prawn, I still use it to render my invoices and estimates, using a simple kramdown to pdf generator). |
Beta Was this translation helpful? Give feedback.
-
Thanks! That would be awesome. I'm happy to help with what I've found so far. Generally mrbgems have their own project structure, but I believe the raylib-bindings project supports both CRuby and MRuby, so it might be a good example for a branch. If we need to call out to C for any reason (I'm not sure we would need to), I highly recommend the mruby handbook for speaking to the mruby C API. My changes are most certainly incomplete (just wanted to support generating pdfs with images), but I pushed my changes to https://github.com/skinnyjames/mruby-prawn-test with a basic idea of what it would take. Let me know if you want to sync on any of this! |
Beta Was this translation helpful? Give feedback.
-
|
Love seeing convos about new things to explore like this. That inspires me to want to find a way back to this project, and I will see what I can do. |
Beta Was this translation helpful? Give feedback.
-
|
👋 I have gotten into the weeds on prawn and squid for some in-house software and definitely fall in the "gap" you're describing. I definitely need PDFs, for historical reasons, and don't want to spend money on licensing other software (total revenue is ... still $0!). Are there specific open issues that you think should be addressed in a round of maintenance? I'm interested in checking them out to see if I can contribute at all. |
Beta Was this translation helpful? Give feedback.
-
|
rmosolgo wrote:
This may be a good idea in general. Depending on how much time Greg wants to invest (assuming his motivation is good), there could be a focus on a few issues to pick; and then the time frame. Naturally that's for Greg to decide, but let's just give some random numbers. Say one month of work, then call it quits, and 10 issues to be tackled during that time (totally random numbers really, just to illustrate the point; I think having a structured approach is better than an open ended here, even though in my own projects I am kind of open ended - in my larger projects I have so many todo-entries that just keep on growing, which is ok for having more creative ideas, but not great for a workflow). This could be added to some kind of meta-issue tracker on github (headius did so for jruby in the past, e. g. with regard to compatibility issues for new jruby releases); or if wanted, there could be a ranking within that meta-issue tracker, e. g. "work on as many issues as possible but stop after the deadline", starting with the more important issues first. Perhaps Greg has an idea what may be worthwhile the most in this regard; I am not that familiar with regard to prawn, having only used some of its API in the past. Or, this could be a short discussion, perhaps in that meta-issue, e. g. to see which pain points may be the most important to address; anything to get prawn into a direction to easier maintenance, more interest by people and so forth. For me personally I don't have any specific issue per se (although I think I may have reported one or two; one related to fonts I think. Oddly enough I think I also raised one or two issues in regards to fonts on hexapdf - no clue why I have issues with fonts). I personally am biased in that I think better documentation would be the most useful thing in general - if you look at projects such as rack, opal or ruby webassembly, the documentation is really not good at all. With ruby struggling more these days, and google search being bad, I think we all kind of need to counter that "decay", by making the ruby documentation in general MUCH much better. I am a bit of a drama queen here, because I see that the situation with regard to documentation does not really improve that much, give or take, so any new young person is just much more likely to pick python rather than ruby. Ruby being better or more fun, is not a good substitute if python has a much better documentation. |
Beta Was this translation helpful? Give feedback.
-
|
In case this is germane, the maintenance work for this seems like it would fit the mold for Mike Purham's recent announcement about gem grants. https://gem.coop/fellowship/ Sharing in case this helps any of the folks on this project attract maintainers. I'd also like to give thanks for the work folks have put into the gem. I've used Prawn over the years and have enjoyed it. I also baked it into the Phlex PDF gem at https://github.com/phlex-ruby/phlex-pdf. 🙏 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi all,
This is not the start of a proper conversation around PrawnPDF maintenance, but instead just a pulse check.
(Any real coordinated effort will require checking in w. Alex and seeing what his thoughts are)
. . .
Theoretically... If I could find a way to come back to the project for a period of a few months, help get a release or two out, document the release management processes, and work with @pointlessone to sort out some sort of plan for making it possible for others to cut releases in the future without a ton of direct involvement from he or I.... is there interest in that?
I'm not volunteering to come back to the project as a permanent maintainer. But what I am exploring is... can we clear enough of the brush out of the way and light the campfires so that others can keep the project moving forward?
My view is that this is still largely "done" software, and that major reinvention should happen elsewhere.
But done doesn't need to mean dead.
Thoughts?
(A simple reaction will do as in this exact moment I'm truly just trying to see what interest is out there. But any additional comments or thoughts are welcome as well!)
Beta Was this translation helpful? Give feedback.
All reactions