Pluggable parsers #354

wants to merge 5 commits into

4 participants

prawnpdf member
cs commented Jun 2, 2012

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!

Christoph Sc... added some commits May 30, 2012
Christoph Schiessl add #pt2pt to Prawn::Measurements 4e10098
Christoph Schiessl initial support for pluggable parsers
parser management is done in `Prawn::Text::Formatted`.
i tried to keep everything as simple as possible!
prawnpdf member
cs commented Jun 2, 2012

One more thing...

For now, all parsers are required to respond to only one method (that's the interface parsers have to implement):

def to_array(string, *args)
   # parse string and produce a prawn compatible array...
   return [] # stub

The other methods in Prawn::Text::Formatted::Parser still have to be dealt with accordingly.

Christoph Sc... added some commits Jun 2, 2012
Christoph Schiessl correct interface of to_array method in prawn default parser e1b5125
Christoph Schiessl different approach: choose the parser when the document is created.
=> new option called `:parser` in `Prawn::Document`
   defaults to the parser shipping with Prawn (`Prawn::Text::Formatted::Parser`).
prawnpdf member
cs commented Jun 21, 2012

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.

prawnpdf member
yob commented Dec 8, 2012


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!

@cs cs Merge branch 'master' into pluggable-parsers
prawnpdf member
cs commented May 1, 2013

@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).

prawnpdf member

@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.

prawnpdf member

@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.

prawnpdf member

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment