-
Notifications
You must be signed in to change notification settings - Fork 687
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pluggable parsers #354
Pluggable parsers #354
Conversation
parser management is done in `Prawn::Text::Formatted`. i tried to keep everything as simple as possible!
One more thing... For now, all parsers are required to respond to only one method (that's the interface parsers have to implement):
The other methods in |
=> new option called `:parser` in `Prawn::Document` defaults to the parser shipping with Prawn (`Prawn::Text::Formatted::Parser`).
Hi! I realize that you won't merge this pull request in its present form (mainly for the lack of documentation). However, some kind of feedback would be nice nonetheless? Am I on the right track? Would you prefer some kind of different approach? I would really appreciate getting answers to those questions before investing more work. |
Hi, Sorry we never provided feedback on this, our time for prawn has been slim recently. I can't speak for the other prawn maintainers, but my feeling is adding this to the official gem in the near future will slow us down in releasing 1.0. un that's released, our focus is on stablising the API and fixing bugs. I suggest we leave this issue open as a wishlist though. thanks! |
Conflicts: lib/prawn/table/cell/text.rb lib/prawn/text/formatted/parser.rb
@yob, thank you for your feedback... I just wanted to let you know, that I'm still interested in this. Actually, I'm using my pluggable parsers implementation in production at the moment. There's an example application available here, illustrating the possibility of using WYSIWYG editing for prawn PDF documents (enabled by the pluggable parsers extension). |
@cs: Sorry again that we didn't get to this sooner. The team didn't even have time to address all the pull requests we got for bugs, so features were very much de-prioritized. I will take a closer look at this as I work through the pull request backlog. Thanks for your patience. |
@cs: Just a heads up, I've done some light review of this patch and I'm definitely sold on the idea. I want to think more about the interface before merging though, and so this may sit around for a little while until I get a chance to merge some of the other patches that have been piling up in the queue. But I'll be sure to get in touch once I have time to take a closer look at this one! |
I merged master into this branch and pushed a copy of it up to the pluggable-parsers feature branch on the prawn repo. I'll open a PR for that branch so we can work on finishing bringing this in. |
@cs: We're going to work on this over at #586. Please do share your thoughts over there as @packetmonkey attempts a slightly revised approach to this problem. |
As discussed in pull request #353, I tried to add support for pluggable parsers to prawn.
The critical question is, where to put the new parser management code. I decided to use the existing module
Prawn::Text::Formatted
, because parser management really belongs to the other code related to formatting. All in all, I tried to make as few changed to prawn as possible.Also, you might want to take a look at: prawn-html5 - I created a new Gem called prawn-html5 which depends on the changes of this pull request and supplies the modified parser I suggested before (in pull request #353).
Finally, I've created a small small Rails application to demonstrate the use of
prawn-html5
with HTML5 compatible WYSIWYG editing. See prawn-html5-example.This isn't finished yet. There are still a things left to do. Please tell me what you think so far!