What are you using Prawn for?
Gregory Brown
Back on the Ruport list, we used to have some open discussions that
led to good ideas and general fun. I'm hoping to carry that tradition
on here.
I'm thinking of putting together user stories about who is using Prawn
right now, and what they're using it for. If you have a public
facing application, this might be a way to promote it. If you've just
been hacking for fun, this is a chance to tell us about your
experiences. I plan to put this together to celebrate Prawn 0.5, the
first beta release of Prawn.
Although 0.5 won't be much different in the way of features, it marks
a long distance traveled from our 0.1 release. I plan to improve the
level of stability of the library from here on out, and will soon
encourage people to start to use it for day to day needs.
So... please tell us what you've been doing with Prawn. If you're
feeling ambitious, write up a blog post and link it here. Otherwise,
respond here. Please do share PDFs and code if you can!
-greg
--
Technical Blaag at: http://blog.majesticseacreature.com
Non-tech stuff at: http://metametta.blogspot.com
"Ruby Best Practices" Book now in O'Reilly Roughcuts:
http://rubybestpractices.com
Gregory Brown
<gregory...@gmail.com> wrote:
> Hi folks,
>
> Back on the Ruport list, we used to have some open discussions that
> led to good ideas and general fun. I'm hoping to carry that tradition
> on here.
> I'm thinking of putting together user stories about who is using Prawn
> right now, and what they're using it for. If you have a public
> facing application, this might be a way to promote it. If you've just
> been hacking for fun, this is a chance to tell us about your
> experiences. I plan to put this together to celebrate Prawn 0.5, the
> first beta release of Prawn.
Also, if it wasn't clear: please feel free to share the good and the
bad. I'm not looking to put together a piece of marketing fluff, but
rather, a fairly accurate picture of what the present state of Prawn
is among community members, so that others know what to expect if they
jump in right now, as well as what we need to improve on in the
future.
Naum
are filled out, but printed (so a signed hardcopy can be filed) - the
user's form responses are saved, but they may fill in any input fields
they didn't complete online and/or add handwritten feedback…
Have not tinkered with Prawn::Format yet, but thus far, it's been a
good fit (tried to use HTMLDOC and while it would work, it choked
sometimes and the memory footprint was just too burdensome)…
Like the light and simple vibe of Prawn, thus far, biggest gripe would
be inability to have the print "cursor" stop in mid-line (like "puts"
v. "print") without resorting to manual space accounting…
--Naum
>…who is using Prawn
Chris Schumann
that evaluates child development. The single page chart has five
developmental areas across the width, and in each column, there are
tasks that children do along an age scale.
A child's performance is plotted along the chart, and a line showing
the actual age at the time of the evaluation, for each evaluation the
child has done.
This will eventually be a public-facing, paid site.
Chris
On Wed, Feb 4, 2009 at 11:14 AM, Gregory Brown
<gregory...@gmail.com> wrote:
> I'm thinking of putting together user stories about who is using Prawn
> right now, and what they're using it for.
(wow, still using two spaces after a period... :)
Laurel Fan
A few examples:
http://www.wisdomcommons.org/virtues/35-determination
http://www.wisdomcommons.org/wisbits/show/2318.pdf
http://www.wisdomcommons.org/wisbits/show/2529.pdf
http://www.wisdomcommons.org/wisbits/show/1558.pdf (sometimes the font size guessing code is kind of dumb)
A few of the cool prawn features I use:
- measuring text before rendering (font size is dynamically determined for each poster)
- graphics and line drawing
- using dfonts that I found on my mac's hard drive (Zapfino is the script font and Big Caslon is the serif one)
It's about 150 lines of view and helper code (half of it is drawing the border).
--
Laurel Fan
http://laurelfan.com
Brad Ediger
> So... please tell us what you've been doing with Prawn.
proposed and accepted items. (No examples to show, sorry!) I currently
just started using Prawn 0.4.0 in some downloadable reports for the
application's users. These reports are printed out and discussed in
meetings, so having compelling data in PDF format is more effective
than online.
Prawn has on the whole been very easy to learn, and it is clearly well
architected. It reminds me of Merb in this regard. As another analogy
to Merb, Prawn's documentation is skimpy but its code is quite easy to
read. There's little magic there. I love this because I went from
never having used Prawn to extending the layout engine in less than a
day.
As with Ruport, the simple cases are stupid simple, and the difficult
cases are possible. I love being able to do Prawn::Document.generate
("hello.pdf"){ text "hello world" } without any fuss. And, as most of
my projects grow fairly complicated, I appreciate that there's a nice
OO API that can handle the really complex cases in an elegant fashion.
There are some rough edges. I haven't encountered a single thing that
I thought was done wrong yet; all of my complaints are of the "0.4
release; not implemented yet" sort.
- Layout. I hacked together a simple column layout engine that we use
for this project: http://gist.github.com/57638. In talking with Greg
about the various needs I had, it became clear that there were so many
special cases that layout is anything but simple. But I was longing
for something like Tk's pack/grid/place declarative layout.
- Similarly, prawn/layout table support feels a bit non-orthogonal,
just in the "Oh, I can't do that?" sense. I had to do a bunch of
digging (and eventually use prawn/format) to change font styles on a
column of a table. The concept of "what is text" seems a bit confused
right now between the different APIs, and led to a bit of confusion.
I've been really happy with Prawn so far, and plan on continuing to
use it more extensively as our applications grow. Thanks Greg and
Prawn team!
Brad
Gregory Brown
> I'm using it for 'poster' versions for a quotes site.
>
> A few examples:
> http://www.wisdomcommons.org/virtues/35-determination
> http://www.wisdomcommons.org/wisbits/show/2318.pdf
> http://www.wisdomcommons.org/wisbits/show/2529.pdf
> http://www.wisdomcommons.org/wisbits/show/1558.pdf (sometimes the font size
> guessing code is kind of dumb)
Wow, these are really great looking. Thanks for sharing. Is this
something you could possibly open source or are there commercial
interests preventing that?
-greg
Richard Hanrick
is, at this moment, manually run each Friday but the intention is to
link it to our management website and allow the operators to generate
single item reports as well as bulk reports. What I need is someone
who is better at Ruby and Rails and is based in Malaysia to take the
project to the next stage.
-richard
Andrew Timberlake
> So... please tell us what you've been doing with Prawn. If you're
> feeling ambitious, write up a blog post and link it here. Otherwise,
> respond here. Please do share PDFs and code if you can!
>
> -greg
One is generating printable invoices
The other is a debt collecting application for a client and there we are generating Letters of demand, statements, profile printouts and various legal letters.
All of these are making quite heavy use of prawn-format and tables.
When I get a break from making project deadlines, I intend to do a blog post on Prawn.
--
Andrew Timberlake
http://ramblingsonrails.com
http://www.linkedin.com/in/andrewtimberlake
"I have never let my schooling interfere with my education" - Mark Twain
FloWi
I'm using prawn to generate a simple invoice for the book my dad and I
made. (There was a heavy storm in 2007 over Germany and it destroyed
most of the woods in our area. If you want to see some pictures -->
www.rwitteler.de)
Nothing fancy. But I did some playing around with prawn and I really
like it ;-)
otaviofcs
We built a plugin billing generator according to brazilian banks
specifications. It's a bill with a barcode, that In Brazil is called
"boleto bancário". It was built with prawn + barby (bar code
generator)
https://github.com/riopro/kill_bill/tree
Jamis Buck
substitution cipher puzzle generator for him that outputs to PDF via
Prawn. (That is, the puzzle generator is simple. The work to format it
for PDF was more fiddly.)
You can see the sample output here:
http://www.jamisbuck.org/files/codes.pdf
And the code is here:
It requires prawn 0.5 (which has not been released yet), but you can
grab the latest prawn from github. Or, you can make it compatible with
0.4.1 by changing all "doc.width_of" references to "doc.font.width_of".
- Jamis
Gregory Brown
>
> My 7-year-old son loves substitution ciphers, so I wrote a simple
> substitution cipher puzzle generator for him that outputs to PDF via
> Prawn. (That is, the puzzle generator is simple. The work to format it
> for PDF was more fiddly.)
So that's why you've been contributing to Prawn so much. I knew there
was a reason!
Thanks for sharing. I'm wondering, should we be doing something with
font calculations to scale the size to fit within a region? A couple
of the examples shared here have seemed to need that, and other tools
I plan to implement such as brine (The presentation tool), will need
it as well.
-greg
Wes Maldonado
conferences that use our service http://www.pathable.com. We'll also
be moving our conference badge printing to prawn (from pdf writer) now
that we've given it a test run and had great results.
There is a screenshot of a generated schedule at the bottom of this
blog post: http://blog.pathable.com/2009/02/new-tools-released-for-iphone.html
Wes
----
home :: http://www.brokenbuild.com
work :: http://www.pathable.com
twitter :: http://www.twitter.com/wesm
SteveQ
learning tool for Irish schools - http://alphalingo.ie (taking beta
testers at the moment)
We built another app for building online CV/Resumes, http://cvcafe.com
- free service. The PDFs built are currently using pdf-writer. Now
that prawn has a html to pdf formatting facility, we're in a position
to migrate them to prawn and finally give our international users
proper unicode support. (Thanks Jamis)
On Feb 4, 8:09 pm, Wes Maldonado <wesl...@gmail.com> wrote:
> We're using prawn to generate personalized attendee schedules for
Jamis Buck
>
> We're using prawn to generate teacher's reports for an online language
> learning tool for Irish schools - http://alphalingo.ie (taking beta
> testers at the moment)
>
> We built another app for building online CV/Resumes, http://cvcafe.com
> - free service. The PDFs built are currently using pdf-writer. Now
> that prawn has a html to pdf formatting facility, we're in a position
> to migrate them to prawn and finally give our international users
> proper unicode support. (Thanks Jamis)
not an HTML to PDF translator. It's a formatting library for prawn
that happens to support a (very small) subset of HTML. It is not (and
probably will never be) a general HTML converter for PDF.
- Jamis
FloWi
I modified your example a bit, so that it can handle special
characters (http://en.wikipedia.org/wiki/Germanic_umlaut) we use in
germany. Please take a look at
http://gist.github.com/59895
I noticed, that the letters aren't exactly centered under their lines
and not in the right place in the "cipher-alphabet". Would you take a
look at the rendered output? http://www.rwitteler.de/codes.pdf
I haven't found a reason in your code for this.
I use prawn 0.4.1 and rub 1.8.7. (and changed the code a bit, like you
mentioned above)
FYI: I don't want you to repair this cipher tool for me. I just want
you to check, if this is a bug in prawn.
- Florian
Gregory Brown
>
> Hi Jamis!
>
> I modified your example a bit, so that it can handle special
> characters (http://en.wikipedia.org/wiki/Germanic_umlaut) we use in
> germany. Please take a look at
> http://gist.github.com/59895
>
> I noticed, that the letters aren't exactly centered under their lines
> and not in the right place in the "cipher-alphabet". Would you take a
> look at the rendered output? http://www.rwitteler.de/codes.pdf
> I haven't found a reason in your code for this.
>
> I use prawn 0.4.1 and rub 1.8.7. (and changed the code a bit, like you
> mentioned above)
> FYI: I don't want you to repair this cipher tool for me. I just want
> you to check, if this is a bug in prawn.
Not that it makes any difference here (at least I hope), but please
note that Prawn is not (and will not ever be) supported on Ruby 1.8.7.
We target Ruby 1.8.6 only. When Ruby 1.8.8 comes out if the 1.8.7
changes are backed out, we'll support it, otherwise, we will only be
supporting 1.8.6 and 1.9.1+
Jason Lee
> So... please tell us what you've been doing with Prawn.
to prawn from PDF::Writer. Overall the transition was relatively easy
and I'm especially pleased with the better kerning (nicer looking text
spacing) that I seem to have automatically gained. There was a few
issues which I followup in other posts.
Example pdf: http://big.first.name/example-big.first.name-nametags.pdf
Jason.
Jason Lee
> I noticed, that the letters aren't exactly centered under their lines
> and not in the right place in the "cipher-alphabet".
accented characters, here is an example,
require 'rubygems'
require 'prawn'
Prawn::Document.generate "width_of.pdf" do
["a", "á", "o", "õ"].each do |string|
text "the string is -> " + string + " <-- and it's width is: " +
font.width_of(string).to_s
end
end
One way to fix your version of Jamis' puzzle program is to :align
=> :center the characters in a bounding_box.
Be careful of overflowing bounding boxes as they seem to interact...?
require 'rubygems'
require 'prawn'
Prawn::Document.generate "martinbtt.pdf" do
string = "@martinbtt"
font_size 20
bounding_box([100, 340], :width => font.width_of(string), :height =>
40 ) do
text string
end
bounding_box([100, 250], :width => font.width_of(string), :height =>
40 ) do
text string
end
end
Jason.
Gregory Brown
>
> On Feb 7, 2:49 pm, FloWi <florian.witte...@googlemail.com> wrote:
>> I noticed, that the letters aren't exactly centered under their lines
>> and not in the right place in the "cipher-alphabet".
>
> This is because the width_of does not return the correct width of the
> accented characters, here is an example,
If you are using the built in AFM fonts, you must encode your text in
WinAnsi before calling width_of.
Did you?
Jamis Buck
built-in fonts require that the text given to width_of be in
windows-1252 charset, and TTF fonts require utf-8. So, try this:
Prawn::Document.generate "width_of.pdf" do
["a", "á", "o", "õ"].each do |string|
font.normalize_encoding(string)
text "the string is -> " + utf8_string + " <-- and it's width is:
" + font.width_of(string).to_s
end
end
If you don't do the normalize encoding step, the widths will be wrong
because the accented characters will be misinterpreted.
- Jamis
Chris Schumann
changes string? That seems really wrong. Shouldn't it return a new
string, or be named "normalize_encoding!", or am I missing something?
Chris
Gregory Brown
<chris.s...@gmail.com> wrote:
>
> Just so I'm clear... font.normalize_encoding(string)
> changes string?
Yes.
>That seems really wrong. Shouldn't it return a new
> string,
Maybe
>or be named "normalize_encoding!"
not without a correseponding non-destructive normalize_encoding.
>, or am I missing something?
Yes. something! doesn't mean 'destructive' in Ruby. It means
Foo#something! is more dangerous than Foo#something
So... if there isn't a matching Foo#something, it never makes sense to
have Foo#something!. Folks who have propagated this in their APIs
have misunderstood what the idiomatic use of ! in Ruby means. Matz
had said if we always used ! to mean destructive, the language would
be littered with !, which is very ugly.
That having been said... I don't see anything wrong with a
normalize_encoding / normalize_encoding! pair, the former which is
non-destructive.
It would require a little re-work, but it's largely a historical
accident that normalize_encoding modifies the string, since it wasn't
previously meant to be part of the public API.
Would this things better?
Chris Schumann
<gregory...@gmail.com> wrote:
> ... something! doesn't mean 'destructive' in Ruby. It means
> Foo#something! is more dangerous than Foo#something
>
> So... if there isn't a matching Foo#something, it never makes sense to
> have Foo#something!. Folks who have propagated this in their APIs
> have misunderstood what the idiomatic use of ! in Ruby means. Matz
> had said if we always used ! to mean destructive, the language would
> be littered with !, which is very ugly.
>
> That having been said... I don't see anything wrong with a
> normalize_encoding / normalize_encoding! pair, the former which is
> non-destructive.
> It would require a little re-work, but it's largely a historical
> accident that normalize_encoding modifies the string, since it wasn't
> previously meant to be part of the public API.
>
> Would this things better?
Idiomatic is preferred, in my mind, so that it acts as someone facile
in Ruby would be least surprised. In my mind, sending font a message
should perhaps change font, but not the parameters of the message, but
that could be just me, and I'm no Ruby wizard. (OTOH,
string.normalize_encoding could change string all day... even
Font.normalize_encoding(s) seems better, but that is probably my Rails
experience showing.)
If this is how standard objects and the well-used libraries work, then
I'll adapt. If it's unique, or unexpected to other programmers
(especially Rubyists,) besides me, it should be changed, public API or
not.
Chris
Frantisek Havluj
are the variants modifying the receiver: map / map!, gsub / gsub! etc.
So for me, as a rubyist, string.normalize_encoding should return new string and
string.normalize_encoding! should modify the string.
If the font instance (i.e. if it depends on specific font) does the normalization, then
font.normalize_encoding(string) is absolutely perfect and it might modify the string,
why not. It is not unexpected for me, unless there is the normalize_encoding /
normalize_encoding! pair, as Greg pointed out.
Font.normalize_encoding would be better if it was font-independent, but from the
previous discussion I guess it is not.
frantisek
Chris Schumann
I hope for others.
Chris
Gregory Brown
>
> Thank you, Frantisek. This discussion is very educational for me, and
> I hope for others.
What Frantisek has said is consistent with what my views on idiomatic
Ruby are, and perhaps says it even more clearly. However, despite the
justification of normalize_encoding() modifying the string, I think it
would be useful to have a choice. So please file a ticket for
normalize_encoding / normalize_encoding! and I'll get to it if a patch
isn't provided before I have a chance to look at it.
-greg
Gregory Brown
> If this is how standard objects and the well-used libraries work, then
> I'll adapt. If it's unique, or unexpected to other programmers
> (especially Rubyists,) besides me, it should be changed, public API or
> not.
http://dablog.rubypal.com/2007/8/15/bang-methods-or-danger-will-rubyist
Chris Schumann
That's a fine post, and David is a good writer and teacher (I attended
Rails Boot Camp with him). But while it does reinforce your perfectly
valid point, it's not a great analogy here because the method doesn't
change the receiver in our case; it changes the parameter, which is
something I hadn't seen in Ruby before (or so I recall).
Chris
Chris Schumann
> ... please file a ticket for
> normalize_encoding / normalize_encoding! and I'll get to it if a patch
> isn't provided before I have a chance to look at it.
Done!
Chris
Gregory Brown
One thing that comes to mind is options processing. A common way to
check valid options for hash-based keywords is to delete the valid
keys and ensure that the hash is empty in the end. Many libraries
will dup the hash before doing this, but some will not.
Generally speaking, I think it's more 'pure' for methods not to modify
the objects passed in to them, but Ruby is not a functional
programming language, and needn't be treated like one. When
normalize_encoding was part of the internal API for Prawn only, it was
completely reasonable for it to act as it did. Now that it is part of
the publicly supported font interface, it is sub-optimal, but I don't
think it's nearly as terrible as you make it sound.
It would be a bad idea to assume that this is so uncommon in Ruby that
you can trust any given library to not modify the objects you pass
into them. It is much better to read the documentation, and test
adequately than count on no side effects.
In any case, the method wouldn't be called normalize_encoding! if
there were only one.
-greg
---
Jamis Buck
that return a value rather than changing their arguments. However,
there is nothing "wrong" with methods that change their arguments,
especially if they are documented as doing so (which
normalize_encoding is). And the "bang" argument is really old in the
Ruby community; either you agree with Matz's characterization of how
it ought to be used, or you don't. Either way, you're going to find
yourself using libraries by someone in the opposite camp, and you'll
be surprised; the key is to not depend on the bang to tell you how a
method is going to act. Trust the source first, the documentation
second, and the bang semantics last, if at all.
- Jamis
RNHurt
perfect for generating Report Cards, Progress Reports, parent
communication letters, etc. Since our application runs on a tiny self
contained server its important that we use our resources carefully and
I'm hoping that Prawn's small size and native code will allow it to
generate anything we need without bogging down our system.
The thing that I am struggling with currently is the display of
tables. It appears as if the vertical spacing of the rows doesn't
follow the font size. For instance, I set my font to :size => 7 and
the table rows are still the default width apart. This sounds like a
bug and I'll create a ticket for it if needed. The other thing that
difficult are complex layouts with lots of bounding_box elements. For
example, a report card has quite a lot of tables, some of them nested,
and I haven't found a good way of representing this structure yet.
Any hints/tips?
Later...
Richard
[1] http://github.com/rnhurt/gradesheet/tree/master
Gregory Brown
>
> We are building a grade book for teachers[1] and I think Prawn will be
> perfect for generating Report Cards, Progress Reports, parent
> communication letters, etc. Since our application runs on a tiny self
> contained server its important that we use our resources carefully and
> I'm hoping that Prawn's small size and native code will allow it to
> generate anything we need without bogging down our system.
Thanks for sharing.
> The thing that I am struggling with currently is the display of
> tables. It appears as if the vertical spacing of the rows doesn't
> follow the font size. For instance, I set my font to :size => 7 and
> the table rows are still the default width apart. This sounds like a
> bug and I'll create a ticket for it if needed.
We'll fix this soon, we found it out right after the prawn/layout release
The other thing that
> difficult are complex layouts with lots of bounding_box elements. For
> example, a report card has quite a lot of tables, some of them nested,
> and I haven't found a good way of representing this structure yet.
> Any hints/tips?
Well, what we reaaly need is a way to embed arbitrary elements in
tables. With so many people needing this and considering the fact
that I laid out a rough sketch for how to implement it, I'm really
surprised it hasn't happened yet. I will get to it eventually, but
this is one feature that'd open up a lot of options. I feel like
there are lots of improvements we can add to prawn/layout to make this
work easier, but I haven't solidified how best to do that yet.
My best advice is not to overdo it with bounding boxes. Although
they're nice for eliminating some calculations, some people have the
tendency to group every single element on their page in one bounding
box or another. That seems to get in the way, rather than help. Have
a look at canvas, padded_box, cell, and span for potential time
savers.
-greg
-greg
--
Stuart.Fraser
PDF for saving and printing. It has been very straight forward on the
whole. I made some helper methods with some metaprogramming so I could
call a simlified version of h1, h2, h3. Prawn has moved on since I
started so I will see if there is anything else that can handle this.
Header.define_heading('h1', pdf, '000066', '000000', 20, 24)
Header.define_heading('h2', pdf, '000066', '000000', 17, 4)
h = Header.new
h.h2("Your Diagnostic Profile".upcase)
class Header
def self.define_heading(name, pdf, head_color, next_color, size,
spacing)
define_method("#{name}") do |copy|
pdf.fill_color head_color
pdf.text copy, :style => :bold, :size => size, :spacing =>
spacing
pdf.fill_color next_color
end
end
end
My only real wish right now is for my client, who keeps asking for
embedded clickable URIs. Right now he has to write "copy and paste
this link" into his copy. Links are progressing last I saw but they
were still lower level features. I really need a higher level parsing
type option so I can just let him write his own text, perhaps textile
or markdown fashion.
How's the progress coming?
Jamis Buck
Stuart.Fraser
top it only mentions internal links, combined with two external urls
that are not marked up so I stopped looking.
Might be handy to mark those urls up to show off the full capability
of the a tag.
- Stu
Jamis Buck
general) do not yet support external URL's. That'd make a good "getting
started" patch, though, if you're looking for a way to contribute to
prawn and prawn-format.
- Jamis
Andrews
> feeling ambitious, write up a blog post and link it here. Otherwise,
> respond here. Please do share PDFs and code if you can!
>
> -greg
Right now I'm starting to use Prawn to generate network security
reports. It's a rails framework where security scans can be scheduled
and then the report is generated based on the gathered information.
I'll be posting some examples --- and yes --- the platform is going to
be Open Source when finished, that's the plan.
Right now, I played a little with the Prawn API, but there is one
thing: I have some method that is in charge of drawing the header and
footer graphics and stuff, it is in colors. However, when adding text,
a new page might be started automatically and then no footer and
header is put there.
Is there a way to execute some method automatically when text reaches
a new page --- or a way to loop through all the pages from beginning
to add the graphics, footer and header just before rendering the whole
file???
Thanks,
And keep the Good job here.
Andrews.
Gregory Brown
This is basically how things will work in Prawn 0.5. I'm waiting for
someone to apply this patch and send me a pull request.
http://pastie.org/380818
I'll do it myself if I remember, but I don't think there is even a
ticket for this one yet.