All Prawn Users, Please Read This! (draft 1.0 spec)

[Gregory Brown]

Attached is a skeletal draft spec for Prawn 1.0.

It lays out our proposed policies, and a rough sketch of the timeline
and plans we have for seeing Prawn to its first production-ready
release. This is essentially just a summary of what we went over in our
first 1.0 planning meeting, but should be a good starting point for
discussion.

We are now entering a comment and discussion phase which will last until
Thursday, April 29th (two weeks from today). On May 1st, we will
publish the final spec. Please share your thoughts ASAP so we can
incorporate them before locking the plan down.

== Spec Summary ==

We are converging on the idea that Prawn will best serve the community
as not just a library, but rather as a platform for document generation.
This means that we aim to provide a high level system for handling the
most common needs of document generation, but make it so this system
is extremely hackable from the low level via an officially supported
extension API.

This means that Prawn isn't going to be a kitchen sink library with
thousands of features, but instead, a foundation to start from that
can be improved on by mixing and matching third party plugins.

IF YOU ARE AN EXTENSION DEVELOPER, OR THINK YOU MIGHT BECOME ONE,
CONTACT US TO DISCUSS THE EXTENSION API.

If you are an application developer (someone just looking to generate
some PDFs), the main thing you'll want to do is read to the bottom
of this spec and look for our description of what we think the
essential document generation features are that might be common
across most projects. Please comment on things we should add,
remove, or change there.

Generally speaking, anything that makes it on that list will be
make it into 1.0, but those things that aren't may be cut out
or denied for inclusion (pending review).

--

That's pretty much it for now. PLEASE COMMENT, as we need to get
a plan together and execute if we want Prawn 1.0 to see the light
of day. We value user and contributor feedback, but this is very
much a "you snooze you lose" situation, so get your issues aired
and we'll start thinking them through.

-greg

[lesfreeman]

Looks great to me. Thanks for all the work!

[Mathieu Arnold]

Hi,

On 15 avr, 17:02, Gregory Brown <gregory_br...@letterboxes.org> wrote:
> That's pretty much it for now. PLEASE COMMENT, as we need to get
> a plan together and execute if we want Prawn 1.0 to see the light
> of day. We value user and contributor feedback, but this is very
> much a "you snooze you lose" situation, so get your issues aired
> and we'll start thinking them through.

As an application developper, (comming from pdf-writer,) my needs
would be simple, I need to build two things :
* long reports with many tables (which are right now generated via
TeX and pdflatex, but I'd like to change that)
* invoices

The first one is pretty straightforward as there is supposed to be
support for multipage tables, what I'd say I would need is a way to
have a table footer (totals at the end) and have a way to make sure
that the totals are not orphaned on the next page, that is, have a
way to say that if it's going to be on the next page, then move the
last one or two lines to the next page with it.

The second one is also quite simple, I need a way to have page
background, headers and footers (with the possibility to have a
different one for the first/last page) and the same kind of
multipages table.

Now, these functionnalities can be plug-ins, either ones I'll use, or
ones I'll do, I'm not afraid to get my hands dirty if there is a nice
API for me to base myself on.

Right now, I'm doing that with pdf-writer, with hacks everywhere, but
I need to rewrite all that so that I can support more than the Latin9
I currently use.

I was also wondering, as I'm going to be getting to having to migrate
from pdf-writer to prawn soon, when there will be a list of features
that are known to stay, known to be axed out, and which status is
unknown, so that I can start doing things without too much of a hasle
when the definitive API goes public.

--
Mathieu Arnold


--
Subscription settings: http://groups.google.com/group/prawn-ruby/subscribe?hl=en

[Tom]

Any chance of pdf form filling capability?

On Apr 15, 8:02 am, Gregory Brown <gregory_br...@letterboxes.org>
wrote:

>  Prawn_1.0-draft1.pdf
> 59KViewDownload

[Randy Parker]

On Mon, Apr 19, 2010 at 3:46 PM, Tom <twal...@gmail.com> wrote:

Any chance of pdf form filling capability?

Tom, if you mean "using Prawn to render output on an existing PDF (say, a form)", then the answer is "templates".  Search this forum for that word, or read the documentation.

- Randy 

[Tom]

Randy,
No I meant actually being able to fill in and then flatten PDF Forms
(as can be done with pdftk), not just stamping text in fixed positions
over an existing pdf. Greg has responded and said its not on the
radar at the moment, and unfortunately I dont know enough about how
fields are specified in PDF forms, or have the free time to research
it currently, to give any input on what would be needed from the
developer API to support it as an extension.

Tom

On Apr 19, 2:03 pm, Randy Parker <randy.j.par...@gmail.com> wrote:

> On Mon, Apr 19, 2010 at 3:46 PM, Tom <twalp...@gmail.com> wrote:
> > Any chance of pdf form filling capability?
>
> Tom, if you mean "using Prawn to render output on an existing PDF (say, a
> form)", then the answer is "templates".  Search this forum for that word, or
> read the documentation.
>
> - Randy
>

[Brad Ediger]

On Mon, Apr 19, 2010 at 4:54 PM, Tom <twal...@gmail.com> wrote:
> Randy,
>  No I meant actually being able to fill in and then flatten PDF Forms
> (as can be done with pdftk), not just stamping text in fixed positions
> over an existing pdf.  Greg has responded and said its not on the
> radar at the moment, and unfortunately I dont know enough about how
> fields are specified in PDF forms, or have the free time to research
> it currently, to give any input on what would be needed from the
> developer API to support it as an extension.

We've talked about it, but user demand hasn't been great, and none of
us have really had the itch to work on making it a fully supported
part of Prawn. I have hacked around a tiny bit with FDF generation
code [0]; this is built on top of Prawn but not really integrated with
it. You'd still use pdftk or a similar product to merge the fields,
but this helps generate them.

-be

[0] http://github.com/bradediger/prawn-fdf

[jaambros]

Hi,
As an application developer an important reason I began using prawn
was because of its full support for UTF-8. In my application I have
users that generate text in many languages (Japanese, Chinese, etc),
and their text is then used to generate PDFs.
However, the default fonts do not have all characters.
It would be nice to have some mechanism by which characters not in the
current font get displayed in some other font that has such character.
My current strategy is to print everything with the most comprehensive
font I've found (Arial Unicode MS.ttf) after redefining the default
fonts using font_families.update

Best, Jose

[Gregory Brown]

On 4/20/10 5:23 PM, jaambros wrote:
> Hi,
> As an application developer an important reason I began using prawn

> was because of its full support for UTF-8. However, the default fonts

> do not have all characters.

The reason why the default fonts do not have all characters is because
they are not TTF files at all, they're Adobe's built in fonts. These
can render any glyphs from the WinAnsi charset, but nothing else.

The default choices are for performance and compatibility, since they
are not required to be embedded in the PDF, unlike TTF files. While we
do subsetting now, there is still a time and space cost of using TTF.

> It would be nice to have some mechanism by which characters not in the
> current font get displayed in some other font that has such character.

Fallback font support was something on our radar a while back, but I'm
not 100% certain that we'll get it implemented in time for 1.0. It is
something that could conceivably be done by an extension.

That said, I will attempt this before 1.0, and have created a ticket and
marked it "important"

http://github.com/sandal/prawn/issues/issue/103

Important features we'll do the best we can to support by 1.0, but will
not be release blockers.

> My current strategy is to print everything with the most comprehensive
> font I've found (Arial Unicode MS.ttf) after redefining the default
> fonts using font_families.update

Why redefine the defaults at all? Doesn't font("MyFamily") do what you
want once you've done the mappings?

-greg

[jaambros]

On Apr 20, 3:00 pm, Gregory Brown <gregory_br...@letterboxes.org>
wrote:

I miss-typed, I do as you suggest, and works fine.
Thanks for all the good work you're all doing.
Best, Jose

[Tonypm]

Prawn 1.0 draft.

This looks like good plan. For me there are some specific things
that I find incredibly important.

Generally, the kinds of docs I am creating are business docs such as
invoices, receipts, reports etc. so important functionality is:

1. Easy header/footer with page numbering (not currently in your
proposal, but something I think would be really useful in prawn
layout, and I see this has already been mention in other responses)

2. Good consistent flow of information across pages, with control
over where the next page picks up. ie sometimes I will start
something somewhere part way down the page and want it to continue at
the top of the page and sometimes it might need to be constrained to a
sub area of the page.

3. Some format flexibility inside table cells. Not going overboard
on this one, but as a minimum being able to put bold/italic/underline
into some cells is vital. For example if I want to show totals at the
end of a list of data, I might want a few rows with bold titles
running down one of the columns. I note the intention of having span,
which is great.

4. Having some variable control over the presence or absence of lines
and line style in tables. ie. it is sometimes very helpful to have
no lines around some cells in a table.
A possible way of implementing this might be to allow a very limited
use of a table within a table cell

4. Pdf writer had the ability to position tables, and that did not
seem to make it into prawn, eg align a table to the right margin, or
center it etc. To implement this in prawn I put the table in a
bounding box, which then has implications for page flow.

I like your plan to define an extension API since this should
hopefully make it possible for users to implement features that are
not met by the standard prawn feature set. Are you planning to
publish a draft for the API?
Also, I wonder if some way for users to share new features might be
possibly incorporated into the project.

I have been using Prawn for a while, and the thing I have perhaps
found difficult is the appearance and removal of features between
releases. This is an observation not a criticism (and yes I do
appreciate this is early development), but to be able to use a library
like prawn relies on a degree of stability and backward compatibility,
with some advance notice of significant changes.

Like others, I too have started hitting issues with pdf writer and the
need for utf 8 support.

Thanks for everyone's efforts to date, I really value having a pdf
generating library like prawn - I just wish I was clever enough to
help out with the development!

Tonypm

[Gregory Brown]

On 4/22/10 7:20 AM, Tonypm wrote:

> Generally, the kinds of docs I am creating are business docs such as
> invoices, receipts, reports etc. so important functionality is:

IMO, custom reports go beyond the scope of Prawn. Really, we should be
leaning on Andrew France to integrate Prawn into Ruport for these sorts
of needs.

> 1. Easy header/footer with page numbering (not currently in your
> proposal, but something I think would be really useful in prawn
> layout, and I see this has already been mention in other responses)

Repeaters give you this. See the examples, it's now trivial to add
page numbers. We also have number_pages but that might go away.

IMO since repeaters provide everything you need, and header / footer
support seems amorphous, higher level support should be implemented by
extensions. That is, unless we can all agree on what this should look like.

> 2. Good consistent flow of information across pages, with control
> over where the next page picks up. ie sometimes I will start
> something somewhere part way down the page and want it to continue at
> the top of the page and sometimes it might need to be constrained to a
> sub area of the page.

You already have this support, exactly as you worded it. For the
former, use span(), for the latter, use bounding_box(). However, be
aware that both of these methods will disappear, and something much more
unified will replace it. Still in my head though.

Keep an eye out for an announcement about a new positioning system, and
please participate in testing. If you have complex needs, it'd be good
to have some extra eyes on what I build here.

> 3. Some format flexibility inside table cells. Not going overboard
> on this one, but as a minimum being able to put bold/italic/underline
> into some cells is vital. For example if I want to show totals at the
> end of a list of data, I might want a few rows with bold titles
> running down one of the columns. I note the intention of having span,
> which is great.

Yes, I think you're right, and while Brad has the final say here, I
think inline styling within table cells is a high-priority feature
(maybe even a blocker)

> 4. Having some variable control over the presence or absence of lines
> and line style in tables. ie. it is sometimes very helpful to have
> no lines around some cells in a table.
> A possible way of implementing this might be to allow a very limited
> use of a table within a table cell

I am pretty sure that you already can control the borders on every cell
(at least in 0.9, but probably in 0.8, too). Have a look at the
examples and source.

> 4. Pdf writer had the ability to position tables, and that did not
> seem to make it into prawn, eg align a table to the right margin, or
> center it etc. To implement this in prawn I put the table in a
> bounding box, which then has implications for page flow.

I think you just missed the API documentation here for table() in any
Prawn version <= 0.8, at least:

:position:

One of :left, :center or n, where n is an x-offset from the left edge
of the current bounding box.

It's true that we don't have right align here, perhaps we should add it.
I am not sure what the 0.9 API allows for here, much of it is still a
work in progress.

> I like your plan to define an extension API since this should
> hopefully make it possible for users to implement features that are
> not met by the standard prawn feature set. Are you planning to
> publish a draft for the API?
> Also, I wonder if some way for users to share new features might be
> possibly incorporated into the project.

We'll develop it organically by working with those who are building
extensions, and perhaps building some extensions ourselves. It will be
discussed on list, so feel free to throw in suggestions and questions as
needed.

> I have been using Prawn for a while, and the thing I have perhaps
> found difficult is the appearance and removal of features between
> releases. This is an observation not a criticism (and yes I do
> appreciate this is early development), but to be able to use a library
> like prawn relies on a degree of stability and backward compatibility,
> with some advance notice of significant changes.

This was mentioned in the draft spec, but I will summarize here for the
benefit of the group

• Extension API backwards compatible across the 1.x family

• User API can change, but deprecation warnings will be given for a full
point release [eg: 1.x -> 1.(x+1)] before a change or removal is made.

• Major point releases will be done monthly, as we have in the past.

• We will support the latest point release and the one preceeding it,
giving users a little bit more time to migrate than we have afforded in
the past.

So basically, you'll have a line of support for one major version less
than the current one, and deprecation warnings on everything that will
change for one full release cycle. Extensions should never break unless
we find a critical flaw in the Extension API.

Does this sound conservative enough for you? We really can't push much
farther than this without stagnation.

> Thanks for everyone's efforts to date, I really value having a pdf
> generating library like prawn - I just wish I was clever enough to
> help out with the development!

I am sure you are. While we have had complaints in the past of being a
bit gruff to our users (that is hopefully changing for the better), we
also have the reputation of being extremely supportive of our
contributors, even if they're new to PDF or to hacking on open source.

Prawn is really not that hard to work on, because it has lots and lots
of tests, decent code in most places, and lots of examples. You may
need to ask some questions to find your way around, but if you have an
itch, please try to scratch it. We'll be happy to help point you in the
right direction.

-greg

[Brad Ediger]

On Thu, Apr 22, 2010 at 8:45 AM, Gregory Brown
<gregor...@letterboxes.org> wrote:
>> 3.  Some format flexibility inside table cells.  Not going overboard
>> on this one, but as a minimum being able to put bold/italic/underline
>> into some cells is vital.  For example if I want to show totals at the
>> end of a list of data, I might want a few rows with bold titles
>> running down one of the columns.  I note the intention of having span,
>> which is great.
>
> Yes, I think you're right, and while Brad has the final say here, I
> think inline styling within table cells is a high-priority feature
> (maybe even a blocker)

I haven't actually done any work with *inline* formatting inside table
cells yet. It may work out of the box once we resolve issue 96 and
pass text options through to the cell constructors:

http://github.com/sandal/prawn/issues#issue/96

But as for whole-cell formatting, this is in edge Prawn:

table(data) do |t|
t.column(0).font_style = :bold
end

>> 4.  Having some variable control over the presence or absence of lines
>> and line style in tables.  ie.  it is sometimes very helpful to have
>> no lines around some cells in a table.
>> A possible way of implementing this might be to allow a very limited
>> use of a table within a table cell
>
> I am pretty sure that you already can control the borders on every cell
> (at least in 0.9, but probably in 0.8, too).  Have a look at the
> examples and source.

Yep, we have this in edge as well.

table(data) do |t|
t.rows(3..5).style :borders => [:left, :right], :border_width => 3
end

(The style method here just lets you set multiple properties at once
-- contrast with my earlier example where you can set properties
directly.)

What's unfortunate, though, is that we don't have anything akin to
CSS's border-collapse: collapse. Each cell is pretty independent and
draws its own borders, so most borders are being drawn twice -- once
for each bordering cell. I can't conceive an API that's both effective
and efficient to get around this (it gets really weird when you
consider that the border widths can be arbitrarily different per
cell), so I'm leaving it low-level for now.

Which means that, for example, if you wanted to remove horizontal
borders in the table but leave the top and bottom borders, you'd have
to be somewhat careful about it. It helps that the aforementioned
style() method takes a block. You'd do something like this:

table(data) do |t|
t.cells.style do |cell|
cell.borders -= [:top] unless cell.row == 0
cell.borders -= [:bottom] unless cell.row == data.length - 1
end
end

Also, we do have subtable support in Prawn. There's a general example here:

http://github.com/sandal/prawn/blob/master/examples/table/subtable.rb

and a more complicated example based on a real-world billing system:

http://github.com/sandal/prawn/blob/master/examples/table/bill.rb

But if you don't need any style control over the subtable, I believe
you can just shove an array inside an array and Prawn will build a
subtable for you:

inner_data = [ %w[One Two], %w[Three Four] ]
data = ["Subtable: ", inner_data]
pdf.table(data)

>> 4.  Pdf writer had the ability to position tables, and that did not
>> seem to make it into prawn, eg align a table to the right margin, or
>> center it etc.  To implement this in prawn I put the table in a
>> bounding box, which then has implications for page flow.
>

> It's true that we don't have right align here, perhaps we should add it.
>  I am not sure what the 0.9 API allows for here, much of it is still a
> work in progress.

I dropped table positioning support completely in the 0.9 API because
the way it was implemented in 0.8 (bounding boxes) broke page flow. I
think it's a valuable feature, but we should probably discuss the API
(and wait on Greg's new implementation of a layout system) before
committing to anything here.

-be

[Mathieu Arnold]

+--On 22 avril 2010 09:45:59 -0400 Gregory Brown

<gregor...@letterboxes.org> wrote:
|> 1. Easy header/footer with page numbering (not currently in your
|> proposal, but something I think would be really useful in prawn
|> layout, and I see this has already been mention in other responses)
|
| Repeaters give you this. See the examples, it's now trivial to add
| page numbers. We also have number_pages but that might go away.
|
| IMO since repeaters provide everything you need, and header / footer
| support seems amorphous, higher level support should be implemented by
| extensions. That is, unless we can all agree on what this should look
| like.

Repeaters don't always do what you need, for instance, I need to have a
nice logo added to the background of every page, but the logo is a nice
lightweighted set of bezier curves, I can't use a repeater to add it,
because it'll be added after all the content of the page, and so, it would
be on top of the content :-)

--
Mathieu Arnold

[Gregory Brown]

On 4/22/10 1:18 PM, Mathieu Arnold wrote:
> +--On 22 avril 2010 09:45:59 -0400 Gregory Brown

> | IMO since repeaters provide everything you need, and header / footer
> | support seems amorphous, higher level support should be implemented by
> | extensions. That is, unless we can all agree on what this should look
> | like.
>
> Repeaters don't always do what you need, for instance, I need to have a
> nice logo added to the background of every page, but the logo is a nice
> lightweighted set of bezier curves, I can't use a repeater to add it,
> because it'll be added after all the content of the page, and so, it would
> be on top of the content :-)

You can use an on_page_create block to do that.

But I wonder, should repeaters run before the page content content is
rendered rather than after? Can anyone think of a good reason they need
to run at the end? I think this may just be a historical accident.

-greg

[Mathieu Arnold]

+--On 22 avril 2010 13:52:15 -0400 Gregory Brown

<gregor...@letterboxes.org> wrote:
| On 4/22/10 1:18 PM, Mathieu Arnold wrote:
|> +--On 22 avril 2010 09:45:59 -0400 Gregory Brown
|
|> | IMO since repeaters provide everything you need, and header / footer
|> | support seems amorphous, higher level support should be implemented by
|> | extensions. That is, unless we can all agree on what this should look
|> | like.
|>
|> Repeaters don't always do what you need, for instance, I need to have a
|> nice logo added to the background of every page, but the logo is a nice
|> lightweighted set of bezier curves, I can't use a repeater to add it,
|> because it'll be added after all the content of the page, and so, it
|> would be on top of the content :-)
|
| You can use an on_page_create block to do that.

Damn, that's exactly what I needed :-)

| But I wonder, should repeaters run before the page content content is
| rendered rather than after? Can anyone think of a good reason they need
| to run at the end? I think this may just be a historical accident.

Maybe, it could be possible to have an option to run them either before or
after, because I can see both making sense.

Regards,

--
Mathieu Arnold

[Chris Schumann]

On Thu, Apr 22, 2010 at 12:52 PM, Gregory Brown
<gregor...@letterboxes.org> wrote:
> But I wonder, should repeaters run before the page content content is
> rendered rather than after?  Can anyone think of a good reason they need
> to run at the end?  I think this may just be a historical accident.

I can imagine a need to run one before the regular content, and
another one after. (Say a background you want covered, and page
numbers you don't.)

Chris

[Gregory Brown]

On 4/22/10 2:15 PM, Chris Schumann wrote:
> On Thu, Apr 22, 2010 at 12:52 PM, Gregory Brown
> <gregor...@letterboxes.org> wrote:
>> But I wonder, should repeaters run before the page content content is
>> rendered rather than after? Can anyone think of a good reason they need
>> to run at the end? I think this may just be a historical accident.
> I can imagine a need to run one before the regular content, and
> another one after. (Say a background you want covered, and page
> numbers you don't.)

Then maybe what we need is:

repeater(..., :z_order => :front)
repeater(..., :z_order => :back)

Does that do the trick?

[Tonypm]

Greg,

thank you for your considered reply.

> Repeaters give you this.  See the examples, it's now trivial to add
> page numbers.  We also have number_pages but that might go away.

Somehow I had not spotted repeaters, perhaps because I was looking for
header. But now you remind me I do recall seeing them mentioned. I
will convert my docs and see how they go. Thanks

> Keep an eye out for an announcement about a new positioning system, and
> please participate in testing.  If you have complex needs, it'd be good
> to have some extra eyes on what I build here.

I will try to keep abreast of this and work on edge as much as
possible.

> I think you just missed the API documentation here for table() in any
> Prawn version <= 0.8, at least:

Yes I was working on an earlier version, I see that position allows
for offset from left margin which is great, I can work with that using
fixed size tables. If right align is not too hard to add I think it
would be worth it.

> We'll develop it organically by working with those who are building
> extensions, and perhaps building some extensions ourselves.  It will be
> discussed on list, so feel free to throw in suggestions and questions as
> needed.

Great

> Does this sound conservative enough for you?  We really can't push much
> farther than this without stagnation.

I think it is shaping up really well

> > Thanks for everyone's efforts to date,  I really value having a pdf
> > generating library like prawn - I just wish I was clever enough to
> > help out with the development!
>
> I am sure you are.  While we have had complaints in the past of being a
> bit gruff to our users (that is hopefully changing for the better), we
> also have the reputation of being extremely supportive of our
> contributors, even if they're new to PDF or to hacking on open source.
>
> Prawn is really not that hard to work on, because it has lots and lots
> of tests, decent code in most places, and lots of examples.  You may
> need to ask some questions to find your way around, but if you have an
> itch, please try to scratch it.  We'll be happy to help point you in the
> right direction.

Your response here is really encouraging. My posts seem to often come
across a bit odd so I appreciate your encouragement and positive
comments. There is a wide range of stuff to keep up with, running
servers and developing apps - it is always a juggling act knowing
where to place study activity. The last couple of years I have been
working at learning git and getting up to speed with TDD and BDD -
reading the Rspec book. I can now at least start to find my way
around and understand what I see. I have looked at some of the very
low level prawn stuff so I have a bit of an idea of what is under the
hood, now I plan to try to get in at the higher level so I hope I may
be able to contribute something useful. I still find a tremendous
wow factor with the whole FOSS world, but finding time is always the
problem.

Tonypm

[Chris Schumann]

On Thu, Apr 22, 2010 at 1:19 PM, Gregory Brown

<gregor...@letterboxes.org> wrote:
> On 4/22/10 2:15 PM, Chris Schumann wrote:
>> On Thu, Apr 22, 2010 at 12:52 PM, Gregory Brown
>> <gregor...@letterboxes.org> wrote:
>>> But I wonder, should repeaters run before the page content content is
>>> rendered rather than after?  Can anyone think of a good reason they need
>>> to run at the end?  I think this may just be a historical accident.
>> I can imagine a need to run one before the regular content, and
>> another one after. (Say a background you want covered, and page
>> numbers you don't.)

> Then maybe what we need is:
>
> repeater(..., :z_order => :front)
> repeater(..., :z_order => :back)
>
> Does that do the trick?

That looks great.
Chris

[Daniel Nelson]

> We are now entering a comment and discussion phase which will last until
> Thursday, April 29th (two weeks from today).  On May 1st, we will
> publish the final spec.  Please share your thoughts ASAP so we can
> incorporate them before locking the plan down.

Perhaps minor, compared with what we've been discussing, but I'd like
to see API consistency among the graphics methods. It never made sense
to me that to draw a rectangle was just rectangle, but to draw a
circle required circle_at. Also, circle_at takes a :radius option, but
rectangle has width and height parameters.

Since things like text_box take :at, :width, and :height options, it
makes sense to me to turn all of the parameters for most of the
drawing methods into options.

For example:

circle(:center => [x, y], :radius => 100)
ellipse(:center => [x, y], :x_radius => 100, :y_radius => 50)
rectangle(:at => [x, y], :width => 200, :height => 100)
curve(:point1 => [x0, y0], :point2 => [x1, y1], :bound1 => [x2, y2],
:bound2 => [x3, y3])

-Daniel

[Gregory Brown]

On 4/26/10 2:55 PM, Daniel Nelson wrote:
>> We are now entering a comment and discussion phase which will last until
>> Thursday, April 29th (two weeks from today). On May 1st, we will
>> publish the final spec. Please share your thoughts ASAP so we can
>> incorporate them before locking the plan down.

> Since things like text_box take :at, :width, and :height options, it
> makes sense to me to turn all of the parameters for most of the
> drawing methods into options.
>
> For example:
>
> circle(:center => [x, y], :radius => 100)
> ellipse(:center => [x, y], :x_radius => 100, :y_radius => 50)
> rectangle(:at => [x, y], :width => 200, :height => 100)
> curve(:point1 => [x0, y0], :point2 => [x1, y1], :bound1 => [x2, y2],
> :bound2 => [x3, y3])

Something like this might make sense, yeah. Let's hold off for just a
little bit before patching, because I may want to restructure Graphics
more deeply.

Feel free to assign a 1.0 blocker ticket for making the API consistent,
though.

-greg