feature requests/ideas/feedback

22 views
Skip to first unread message

thorny_sun

unread,
Jun 29, 2008, 4:54:56 AM6/29/08
to Prawn
1) rotate text? I'm thinking specifically to make some tables nicer
where i need a lot of thin columns, but i still want column headers--
it's nice to be able to rotate the column headers to 70degrees or
90degrees or whatever. also it's nice sometimes to be able to write
something in the left or right margin rotated 90 degrees. bonus
points for getting table grid lines to follow specified rotation of
header.

2) table cells that have access to more prawn functions. I know this
may start getting complicated, but it'd be nice to be able to do all
possible pdf operations within a table cell, not just placing a
string. i.e. placing an image or doing some vector drawing would be
nice. for example-- i have a list of items and i'd like to draw an
empty checkbox next to each item in the list. there is no way to do
that currently with table method -- correct?

3) embedding images-- i think you've already got this on your jurassic-
timeline, but just reiterating here, since i believe it is the only
thing i'm missing from pdf::writer at the moment

whaddya think?

so glad you've taken on this project-- it is much needed and
appreciated!! hopefully i'll be able to help you as you continue your
progress. at the very least i think i will publish a retooling of the
railspdf plugin that instead uses prawn (if someone hasn't already)

Gregory Brown

unread,
Jun 29, 2008, 12:10:52 PM6/29/08
to prawn...@googlegroups.com
On Sun, Jun 29, 2008 at 3:54 AM, thorny_sun <michae...@gmail.com> wrote:
>
> 1) rotate text? I'm thinking specifically to make some tables nicer
> where i need a lot of thin columns, but i still want column headers--
> it's nice to be able to rotate the column headers to 70degrees or
> 90degrees or whatever. also it's nice sometimes to be able to write
> something in the left or right margin rotated 90 degrees. bonus
> points for getting table grid lines to follow specified rotation of
> header.

In order to do the table stuff, we'd need to give you the kind of
control you're looking for in #2.

Text rotation should not be very hard to support in the text() method,
but it might be quite complicated to get working meaningfully in
tables. Patches and suggested approaches welcome. This isn't a super
high priority for my work, but I think maybe other people will want
this, so it's likely it'll get worked on some time this summer.

> 2) table cells that have access to more prawn functions. I know this
> may start getting complicated, but it'd be nice to be able to do all
> possible pdf operations within a table cell, not just placing a
> string. i.e. placing an image or doing some vector drawing would be
> nice. for example-- i have a list of items and i'd like to draw an
> empty checkbox next to each item in the list. there is no way to do
> that currently with table method -- correct?

Currently not possible but also... not entirely impossible. The
design of cells lends itself very well to this, in truth, they're just
bounding boxes that are specialized for outputting text. Conceivably
a cell could be a lambda that gets passed a PDF object. However, the
trouble with this would be automatically calculating the width and
height of the cell.

I'm tempted to say this sort of 'advanced' table is a little too
heavyweight for Prawn and we'd expect you to roll your own using
bounding boxes, but I could be convinced otherwise.

One lightweight thing I could think of is something like a Document::Section.
it'd have things like

Section#action : a lambda that is passed the document to draw on
Section#document : the PDF document to render to
Section#width|height|width=|height= : manually set widths and heights.
Section#point|point= : top left point of the section

The section would of course also need to quack like a cell in terms
of padding and borders.

Actually... this sounds promising, maybe I'll try implementing it.
The limitation is you'd need to know the size of the boxes ahead of
time.

section = Section.new(:width => 200, :height => 150)
section.draw do |pdf|
pdf.line pdf.bounds.bottom_left, pdf.bounds.top_right
end

pdf.table [["a",section],["b",section}}

> 3) embedding images-- i think you've already got this on your jurassic-
> timeline, but just reiterating here, since i believe it is the only
> thing i'm missing from pdf::writer at the moment

This will happen within the next 2 weeks. Do you have any specific
suggestions on how you'd like to see this work?

> whaddya think?

Good suggestions. Thanks for sharing.

> so glad you've taken on this project-- it is much needed and
> appreciated!! hopefully i'll be able to help you as you continue your
> progress. at the very least i think i will publish a retooling of the
> railspdf plugin that instead uses prawn (if someone hasn't already)

That would be great. You may want to talk to Mike Milner about
Ruport/Rails, to avoid duplication between railspdf and it. IIRC they
have similar purposes, since the Ruport/Rails plugin just basically
allows you to write templates inside a Ruport PDF formatter, which
will be PRawn based soon.

thorny_sun

unread,
Jun 30, 2008, 11:50:54 AM6/30/08
to Prawn
I'm thinking in terms of my web-app purposes, I turned to pdf's
because printing html wasn't able to achieve exactly what I wanted
namely:
landscape orientation
rotated text
better font control
(also i think i had problems with png's printing properly in html)

these are the main features that aren't available in printing an html
doc, and are the main features i'd be looking for in an html
alternative. I have to imagine this is true for most everyone trying
to create pdfs for the web. No one necessarily wants to cuz you have
to deal with the extra layer of acrobat, but the extra features are
required enough to make one willing to deal with the extra layer. for
example, when you print google maps it just prints the html doc, but
when you go to print a google calendar they take you to a pdf, cuz
then they can do landscape and maybe some other fancy things. of
course this increases the burden of expectation on anyone making a pdf
library to provide functionality at least equivalent to what html can
do.

looking at your implementation-- it looks like everything is based on
this concept of a bounding box, correct? and a bounding box can have
children bounding boxes, which can in turn have children bounding
boxes, etc. etc.? so based on that, it seems like you already have
the tools needed for a lot of things-- including tables within tables
within tables assuming you can determine the widths and heights or
they are pre-specified? (says the man who has no clue how any of this
stuff is working)

> Text rotation should not be very hard to support in the text() method,
> but it might be quite complicated to get working meaningfully in
> tables.  Patches and suggested approaches welcome.

90 degree rotation shouldn't create too many additional complexities?
perhaps if that's an easier way to tackle the problem you could start
with just that special case first? I suppose you'd have to move the x
pointer instead of the y pointer, but otherwise wouldn't be too
different-- no? (again says the man who has no clue how any of this
stuff is working)

> > 3) embedding images-- i think you've already got this on your jurassic-
> > timeline, but just reiterating here, since i believe it is the only
> > thing i'm missing from pdf::writer at the moment
>
> This will happen within the next 2 weeks.  Do you have any specific
> suggestions on how you'd like to see this work?
>

i'd like png support specifically.

also-- does your text method currently have an alpha or color option?
i.e. what if i want to write a big DRAFT across my pages in faint
gray. (of course ideally it would be 70degree angle :)

James Healy

unread,
Jun 30, 2008, 11:38:01 AM6/30/08
to prawn...@googlegroups.com
thorny_sun wrote:
> > Text rotation should not be very hard to support in the text() method,
> > but it might be quite complicated to get working meaningfully in
> > tables.  Patches and suggested approaches welcome.
>
> 90 degree rotation shouldn't create too many additional complexities?
> perhaps if that's an easier way to tackle the problem you could start
> with just that special case first? I suppose you'd have to move the x
> pointer instead of the y pointer, but otherwise wouldn't be too
> different-- no? (again says the man who has no clue how any of this
> stuff is working)

WARNING: Implementation details and PDF spec jargon to follow...

I *think* it should be possible to just apply a rotate transform to the
text object (BT... ET). See section 4.2.2 of the spec. I haven't
actually tried this out myself, so I could be wrong.

I'm not sure of the best way to expose this via Prawn's API either.
Maybe something like:

text "hi there", :rotate => 90

<snip>

> also-- does your text method currently have an alpha or color option?
> i.e. what if i want to write a big DRAFT across my pages in faint
> gray. (of course ideally it would be 70degree angle :)

The text is drawn in whatever the current colour is set to. See
examples/simple_text.rb. AFAIK, alpha is not supported yet.

-- James Healy <jimmy-at-deefa-dot-com> Tue, 01 Jul 2008 01:28:50 +1000

Gregory Brown

unread,
Jun 30, 2008, 12:30:12 PM6/30/08
to prawn...@googlegroups.com
On Mon, Jun 30, 2008 at 11:50 AM, thorny_sun <michae...@gmail.com> wrote:

> looking at your implementation-- it looks like everything is based on
> this concept of a bounding box, correct? and a bounding box can have
> children bounding boxes, which can in turn have children bounding
> boxes, etc. etc.? so based on that, it seems like you already have
> the tools needed for a lot of things-- including tables within tables
> within tables assuming you can determine the widths and heights or
> they are pre-specified? (says the man who has no clue how any of this
> stuff is working)

The raw tools are there for making things like this possible. The
idea i suggested for document sections would likely be able to support
tables within tables but I have no idea how hard it'd be to make them
look good.

Mostly, I'm not interested in 'advanced' PDF features as much as I am
providing powerful low level tools that people can use to build these
things. Prawn needs to be fast and lightweight, those two goals are
paramount lest we become the 800-pound Gorilla that is PDF::Writer.

>> Text rotation should not be very hard to support in the text() method,
>> but it might be quite complicated to get working meaningfully in
>> tables. Patches and suggested approaches welcome.
>
> 90 degree rotation shouldn't create too many additional complexities?
> perhaps if that's an easier way to tackle the problem you could start
> with just that special case first? I suppose you'd have to move the x
> pointer instead of the y pointer, but otherwise wouldn't be too
> different-- no? (again says the man who has no clue how any of this
> stuff is working)

There is no x-pointer when you are flowing text. 90 degree rotated
column names are something I can probably support in table as an
option, but honestly, I have no idea how this effects our width and
height calculations. I'm sure there is a simple trig function that
can offset those values based on rotation, but I haven't thought about
it yet.

>> > 3) embedding images-- i think you've already got this on your jurassic-
>> > timeline, but just reiterating here, since i believe it is the only
>> > thing i'm missing from pdf::writer at the moment
>>
>> This will happen within the next 2 weeks. Do you have any specific
>> suggestions on how you'd like to see this work?
>>
>
> i'd like png support specifically.

We'll see what we can do. I plan to target JPG and PNG for starters

> also-- does your text method currently have an alpha or color option?
> i.e. what if i want to write a big DRAFT across my pages in faint
> gray. (of course ideally it would be 70degree angle :)

No alpha support yet, but I remember this was something people asked
for even before I started on Prawn, so I can possibly move it up the
priority list for things to be done as soon as Prawn is integrated
into Ruport.

James already let you know about setting the text color, I'll think
about adding an option to text() for it.

-greg

Reply all
Reply to author
Forward
0 new messages