Prawn: the README numbers its manual build steps 1, 3, 4 and points you to Ferrum for HTML

The library rules out the most common reason to want a PDF tool

The Should You Use Prawn section exists to turn people away, which is unusual and worth reading before the feature list. Prawn is a pure Ruby PDF generation library that provides a lot of functionality while trying to remain simple and reasonably performant. If you are looking for a highly flexible PDF document generation system, it might be the tool for you. It is not a reporting tool or a publishing toolchain, though the text adds that it could be fairly easily used to build those things. Then the exclusion: one thing Prawn is not, and will never be, is an HTML to PDF generator. For that need it points at Ferrum. The reason is given as scope rather than priority, because Prawn does have basic support for inline styling, but that support is limited to a very small subset of functionality and is not suitable for rendering rich HTML documents. So if your pipeline starts with a template engine, you are looking at the wrong library and the project says so before you spend an afternoon on it.

The feature list ends at the PDF object tree, which is the actual differentiator

The capability list is long, and one entry tells you what kind of library this is. Vector drawing support covers lines, polygons, curves and ellipses. Text rendering is extensive, including flowing text and limited inline formatting. There is support for both PDF builtin fonts and embedded TrueType fonts, plus PNG and JPG image embedding with flexible scaling options. Layout help comes as low level tools including a simple grid system, and repeatable content such as headers, footers and page numbers is rendered by dedicated tools. Navigation support covers PDF outlines for document navigation. Internationalization is described as comprehensive, with full support for UTF-8 based fonts, right to left text rendering, fallback font support and extension points for customizable text wrapping. And the last real entry is the one that matters for anyone extending it: low level PDF features allow users to create custom extensions by dropping down all the way to the PDF object tree layer, which is noted as mostly useful to those with knowledge of the PDF specification. Everything above that line is convenience; the object tree is the escape hatch.

Four licence files sit at the root and the metadata recognises none of them

This is the part to sort out for yourself rather than infer. The repository root contains LICENSE, COPYING, GPLv2 and GPLv3 as four separate files, alongside a prawn.gemspec, a Gemfile and a Rakefile. The licence metadata recorded for the repository is not a recognised value, so nothing in the project's own display tells a reader which of those texts governs use. To answer the question, open those files and read them. That matters more than usual here because Prawn is a library rather than an application: anyone embedding it in a product inherits the answer, and a compliance review that scans for a licence identifier will come back empty. Note also the checksums/ and certs/ directories at the root, which indicate the project carries verification material for the artefacts it produces or signs.

The release policy says bug fixes are allowed to change behaviour

The versioning section is where a Prawn user gets hurt, and the project is direct about it. They are trying not to break things unnecessarily, but they do not formally follow Semantic Versioning. The stated reason is that they release a number of experimental APIs, make no promises on their stability, and that you can assume the stable portion of the API follows Semantic Versioning. So the guarantee is partial by design: the stable surface is SemVer, and the experimental surface is not covered by anything. Then the sentence that matters most in practice: bug fixes can change behaviour, and that is not considered a breaking change for the purposes of versioning, so the request is to test your applications after updating Prawn. The instruction that follows is to read the release notes in CHANGELOG.md each time a new release is cut and to lock your gems accordingly. Given the release record, with 2.3.0 in August 2020 after 2.2.0 in March 2017 and 2.1.0 in March 2016, the changelog rather than the version number is where the detail lives.

The manual build instructions skip step 2

The documentation on building the manual is short and has a numbering error in it. You are told to clone the repository, then run the two commands below, the second of which generates manual.pdf in the project root:

gem install -g
rake manual

The list containing them is numbered 1, 3, 4, with no step 2. Since the three commands given are complete on their own, the gap costs nothing practical, but it is the kind of detail that tells you how carefully the file is maintained, and it sits in the same README that is otherwise candid about its limitations. The manual itself is described as a series of examples demonstrating the wide range of features, with a generated version of the latest released Prawn published on the project website and the sources in the manual directory of the repository. The README is explicit that the manual is a great introduction but not exhaustive, and that API docs are the reference for complete information.

Four ways to run the suite, and one of them includes the failures

The test suite is documented with four invocations that differ in what they include, which tells you more about the project than a single test command would. Running `rake` runs the entire suite excluding any unresolved issues. Running `rspec` runs the entire suite including unresolved issues. Running `rspec -t unresolved` runs only the unresolved issues. Running `rspec -t issue:NUMBER` runs the tests for a specific issue. The stated purpose of these filters is that they make it possible to add failing test cases for bugs that are currently being researched or worked on, without breaking the typical full suite run. That is an unusual and useful practice: a reproduction for a known bug can live in the repository as a failing test, which means the default rake run is the one that stays green while rspec is the one that shows you the state of every known problem. The spec/ directory at the root is where those live.

Community ownership is stated bluntly, along with what a good bug report needs

The maintenance section says something that is rarer than it should be. Prawn has always been heavily dependent on community contributions, with dozens of people contributing code over the years, and in that sense the lines have blurred to the point where there is no longer a strong distinction between core developers and contributors. There is a small set of people responsible for cutting releases, merging important pull requests and making major decisions, and the README is open about that residual structure. For contributors the bar is specific: bug reports should come with failing tests or at least a reduced example demonstrating the problem, and patches should include tests, API documentation and a manual update where relevant. Early pull requests are welcome for feedback before the work is finished. Support runs through GitHub Discussions, with the mailing list suggested for checking whether something is a bug or a wanted feature, with a request to reduce example code so the relevant part is visible and to post nothing that should not be shared publicly.

Editorial conclusion

Prawn fits a Ruby codebase that needs to draw into a PDF directly, whether that is vector graphics, embedded TrueType, right to left text, encryption or the low level PDF object tree, and it does not fit anyone who wants to render HTML, because the README rules that out in as many words and names Ferrum as the alternative. Three things to settle before you commit. Read the release policy, since Prawn does not formally follow Semantic Versioning, releases a number of experimental APIs with no stability promise, and bug fixes are allowed to change behaviour without counting as a breaking change. Pin your gems and read CHANGELOG.md on every upgrade, which is what the project asks. And read the licence files yourself, since the root holds LICENSE, COPYING, GPLv2 and GPLv3 at once and the metadata records no recognised licence. The last push is dated 2026-04-18.

Frequently asked questions

Official sources

1. Issues
2. prawnpdf/prawn on GitHub
3. Project website
4. README
5. Releases