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
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.
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... :)
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
> 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
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
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
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
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+
If you are using the built in AFM fonts, you must encode your text in
WinAnsi before calling width_of.
Did you?
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?
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
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
> 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
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
Done!
Chris
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
---
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
--
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.