If you use PDF::Writer, read this post!

[Gregory Brown]

I'm getting very few requests for features to add to Prawn that exist
in PDF::Writer but not in Prawn.
Because it directly effects each and every user, I need to know what
this means. =A0Please remember that I intend to *END ALL SUPPORT FOR
PDF::WRITER* after Prawn becomes PDF:ocument, so long as there is a
sufficient mandate from the community.

=3D Are you happy with Prawn as it is and have already migrated your new
projects to it?

If so, you have your right to remain silent. =A0But it'd be re-assuring
to hear from you to know that you're satisfied.

=3D Are there features you need that have not yet been implemented in
Prawn?

Please let me know know ASAP, within the next few weeks or so if
possible. =A0 Other uses should feel welcome to +1 these requests, so I
know how much of a demand there is. =A0If you do this, there is a good
chance you'll see these in Prawn / PDF:ocument 1.0

=3D Do you plan to keep on using PDF::Writer even though it's slated for
deprecation?

Don't. =A0We won't even be handling bug fixes after this summer.

Or if there are enough people with this plan, please start talking to
me now. =A0 I'll get in touch with Austin and see what he thinks about
bringing in a new maintainer. =A0But you should have a really good
reason for this.

With luck, we'll have a broad adoption of Prawn and there will be
group hugs all around. =A0But I'm trying to make this transition as
smooth as possible by planning ahead, so please help me by stating
your intentions.

-greg

PS: The urgency and intensity of this post is meant to be a bit
humorous, but also to emphasize the point that a change is in the
wind.

 

[Stefan Lang]

I'm getting very few requests for features to add to Prawn that exist
in PDF::Writer but not in Prawn.
Because it directly effects each and every user, I need to know what
this means. Please remember that I intend to *END ALL SUPPORT FOR
PDF::WRITER* after Prawn becomes PDF:ocument, so long as there is a
sufficient mandate from the community.

Why rename it? Prawn is a nice name, while PDF:ocument seems to
imply that there are other closely related PDF::* modules.

= Are you happy with Prawn as it is and have already migrated your new
projects to it?

If so, you have your right to remain silent. But it'd be re-assuring
to hear from you to know that you're satisfied.

I've written a prototype with Prawn and it was a pleasurable
experience. Nice API!

= Are there features you need that have not yet been implemented in
Prawn?

Being able to put more complex objects than just text into table
cells would be cool, as well as more options for table borders.
(I've used 0.3.0 so maybe this request is already obsolete.)

Please let me know know ASAP, within the next few weeks or so if
possible. Other uses should feel welcome to +1 these requests, so I
know how much of a demand there is. If you do this, there is a good
chance you'll see these in Prawn / PDF:ocument 1.0

-greg

Stefan

 

[Gregory Brown]

Why rename it? Prawn is a nice name, while PDF:ocument seems to
imply that there are other closely related PDF::* modules.

There are

We've got PDF::Inspector and PDF::Reader. Both which are tentatively
planned to become part of the 'pdf' project.

http://rubyforge.org/projects/pdf

gem install pdf would get you all of them.
Note that I'll likely turn Prawn into PDF:ocument by something
simple like this in the pdf gem:

module PDF; end
Prawn = PDF;
require "prawn"

Or something silly like that, at first. (Just off the top of my head,
I'm not sure the above actually works)

It may be possible to just keep Prawn as Prawn, but we'll see how it goes.

I've written a prototype with Prawn and it was a pleasurable
experience. Nice API!
Awesome.


Being able to put more complex objects than just text into table
cells would be cool, as well as more options for table borders.
(I've used 0.3.0 so maybe this request is already obsolete.)

The former request is in high demand. I've been hoping for someone
else to nail it because I've suggested on the Prawn list how I'd like
to see it implemented and I feel it's a straightforward patch. So
far, no one has bit. I will implement this if no one does before
1.0, most likely.

The latter, we've got some things that are new, others not advertised.
Before I do more with the table stuff, I need to re-organize it a
bit, but it's coming. I usually ask for folks to file tickets for
stuff like this, but those two issues are burned into my brain well
enough and rest on me getting some stuff done before I can tackle them
anyway, so don't worry about it.

Of course, patches are welcome for both.

-greg

 

[Trans]

There are

We've got PDF::Inspector and PDF::Reader. =A0Both which are tentatively
planned to become part of the 'pdf' project.

http://rubyforge.org/projects/pdf

gem install pdf would get you all of them.
Note that I'll likely turn Prawn into PDF:ocument by something
simple like this in the pdf gem:

module PDF; end
Prawn =3D PDF;
require "prawn"

Or something silly like that, at first. (Just off the top of my head,
I'm not sure the above actually works)

It may be possible to just keep Prawn as Prawn, but we'll see how it goes=

 

[Gregory Brown]

module Prawn
module PDF
class Document

The extra namespace ensures it can still be used without conflict
should another lib use the PDF namespace too. And one can do:

include Prawn

to still use just

PDF:ocument

A 'shortcut' require can also be provided to automatically do the
including.

Nah, it'd be mighty annoying to nest all my classes that way. I'm fine
with claiming the PDF namespace since I'm the current maintainer of
the Ruby PDF project (PDF::Writer), and one of the principle
developers on Prawn maintains PDF::Reader.

It will be up to other developers to avoid namespace collisions with
us, or alternatively, join forces and become part of the 'pdf' project
for Ruby.

-greg

 

[Redd Vinylene]

[Note: parts of this message were removed to make it a legal post.]

Does anybody use this stuff as an alternative to LaTeX?

 

[Martin DeMello]

Does anybody use this stuff as an alternative to LaTeX?

I have a project that generates lout from ruby and then pdf from lout
- I've been meaning to port it over to prawn and drop the external
dependency. In general, I'd say that if you are machine-generating a
PDF, a ruby library would be a lot more convenient to use than
generating latex or lout or whatever.

martin

 

[Redd Vinylene]

[Note: parts of this message were removed to make it a legal post.]

Too true, too true. LaTeX gives me a headache.

 

[M. Edward (Ed) Borasky]

Too true, too true. LaTeX gives me a headache.

While we're on the subject of PDFs, LaTeX, etc.

1. I use an open-source document writing tool called LyX
(http://www.lyx.org) to do nearly all of my documentation. It can
convert to and from almost any format that has an open-source library,
but its "core" is LaTeX and "pdflatex". Its internal format looks a lot
like LaTeX.

The primary scripting language in LyX is Python. Sorry, guys, the snakes
just got there first. There is also an excellent package for doing
"literate programming" with LyX in the R programming language at

http://cran.fhcrc.org/contrib/extra/lyx/

I would like to be able to do literate programming with LyX as easily in
Ruby as I can in R or Python.

2. New features for Prawn aka PDF:ocument? The PDF format includes the
ability to incorporate multimedia files "seamlessly" into a document.
One extremely impressive example of this is a format called "U3D". This
allows you to incorporate a 3D object in a PDF with very little space
cost, and you can rotate the object, change the lighting on it, etc.
There's a stunning example of the capabilities of this at

http://www.tug.org/texshowcase/Laurana.pdf

And the code to make it is at

http://www.tug.org/texshowcase/Laurana_tex.zip

I'm sure the tools in PDF:ocument can easily get a U3D into a PDF, or
if not, could be extended to do so easily. But what I'd really like is a
set of Ruby libraries / classes for making the U3Ds from data! Right
now, it looks like the main open source package for making U3Ds is
Meshlab, which is at

http://meshlab.sourceforge.net/

See also

http://vcg.sourceforge.net/

 

[Gregory Brown]

Does anybody use this stuff as an alternative to LaTeX?

That's certainly not the goal, but actually Jamis Buck's
prawn-format[0] extension might get people close to some of the
complex needs you'd use LaTeX for. But of course, YMMV.

-greg

[0] http://github.com/jamis/prawn-format

 

[Gregory Brown]

I have a project that generates lout from ruby and then pdf from lout
- I've been meaning to port it over to prawn and drop the external
dependency. In general, I'd say that if you are machine-generating a
PDF, a ruby library would be a lot more convenient to use than
generating latex or lout or whatever.

Yes, the benefit of a pure-Ruby to PDF library is that there aren't
intermediate dependencies. Of course, thinks like LaTeX or lout, or
Postscript (via the very cool RGhost library) might have their
benefits in certain situations, and might kick our butts performance
wise.

But when you use Prawn (or PDF::Writer), you've got vanilla Ruby that
generates a complete PDF. The purists among us are sure to find that
appealing.

-greg

 

[Gregory Brown]

2. New features for Prawn aka PDF:ocument? The PDF format includes the
ability to incorporate multimedia files "seamlessly" into a document.
One extremely impressive example of this is a format called "U3D". This
allows you to incorporate a 3D object in a PDF with very little space
cost, and you can rotate the object, change the lighting on it, etc.
There's a stunning example of the capabilities of this at

http://www.tug.org/texshowcase/Laurana.pdf

This wouldn't load in OS X Preview. Interesting to see this stuff
used, I saw brief mentions of this in the PDF specs, but I was sort of
expecting it was unused and unsupported across many viewers. The
former I've apparently been proven wrong on, the latter, I think might
be right. What viewers support this?

And the code to make it is at

http://www.tug.org/texshowcase/Laurana_tex.zip

I'm sure the tools in PDF:ocument can easily get a U3D into a PDF, or
if not, could be extended to do so easily. But what I'd really like is a
set of Ruby libraries / classes for making the U3Ds from data! Right
now, it looks like the main open source package for making U3Ds is
Meshlab, which is at

http://meshlab.sourceforge.net/

See also

http://vcg.sourceforge.net/

You'd need to write an extension, but it might not be too hard. I
haven't researched it at all, honestly. You might look at the PDF
spec[0]. It'd be neat to see an extension that did this, and I'd
expose the necessary bits to make sure it was possible to do
externally, but I'm sure this wouldn't be part of core Prawn, and I
hesitate to say whether it'd be part of the 'official' project. It
seems like a better home for it might be SciRuby or something like
that. We'd of course help promote the use of the tool and help with
the Prawn specific details, but beyond that, this seems a bit
specialized for what we're trying to keep a small and simple library.
Please do look into this though, and feel free to discuss it on the
Prawn list in hopes of finding other interested parties.

-greg


[0] http://www.adobe.com/devnet/pdf/pdf_reference.html

 

[Dave Thomas]

This wouldn't load in OS X Preview. Interesting to see this stuff
used, I saw brief mentions of this in the PDF specs, but I was sort of
expecting it was unused and unsupported across many viewers. The
former I've apparently been proven wrong on, the latter, I think might
be right. What viewers support this?

Acrobat is the only one I know, which sucks. I've been wanting to
embed multimedia in our books for a while, but the fact that most
readers won't display the stuff correctly has held us back.


Dave

 

[M. Edward (Ed) Borasky]

This wouldn't load in OS X Preview. Interesting to see this stuff
used, I saw brief mentions of this in the PDF specs, but I was sort of
expecting it was unused and unsupported across many viewers. The
former I've apparently been proven wrong on, the latter, I think might
be right. What viewers support this?

As far as I can tell, only Acrobat Reader on Linux. There may be others
on Windows and Macs, but I have only played with it on Linux.

And the code to make it is at

http://www.tug.org/texshowcase/Laurana_tex.zip

I'm sure the tools in PDF:ocument can easily get a U3D into a PDF, or
if not, could be extended to do so easily. But what I'd really like is a
set of Ruby libraries / classes for making the U3Ds from data! Right
now, it looks like the main open source package for making U3Ds is
Meshlab, which is at

http://meshlab.sourceforge.net/

See also

http://vcg.sourceforge.net/

You'd need to write an extension, but it might not be too hard. I
haven't researched it at all, honestly. You might look at the PDF
spec[0]. It'd be neat to see an extension that did this, and I'd
expose the necessary bits to make sure it was possible to do
externally, but I'm sure this wouldn't be part of core Prawn, and I
hesitate to say whether it'd be part of the 'official' project. It
seems like a better home for it might be SciRuby or something like
that. We'd of course help promote the use of the tool and help with
the Prawn specific details, but beyond that, this seems a bit
specialized for what we're trying to keep a small and simple library.
Please do look into this though, and feel free to discuss it on the
Prawn list in hopes of finding other interested parties.

Actually, I do think "data -> U3D" needs a separate project. I haven't
been following the "scientific computing in Ruby" projects much in the
past two years, so I don't know what's "new". But I would think Prawn
should definitely be able to take a U3D into a PDF. The fact that my
search for "open source U3D creators" essentially dead-ends at Meshlab
leads me to believe that it (or its core, VCG) is the only game in town.

But it might be relatively easy to get a Ruby interface to VCG using SWIG.

-greg


[0] http://www.adobe.com/devnet/pdf/pdf_reference.html

 

[Gregory Brown]

But I would think Prawn should definitely be able to take a U3D into a > PDF.

If you're talking about the technical possibility, yes, since it's
specified by Adobe, it can be done, I imagine. And a third-party gem
to do this (prawn-u3d), would be welcome.

But if you're talking about how we should include this feature because
it's an important feature for a PDF generator, well.. I disagree
there. I have no plans to fully support the PDF specification (it's
massive), and the fact that there are no open-source (or even
commercial) applications that seem to support this feature other than
Adobe's own acrobat reader makes me very uninterested in supporting it
directly in Prawn.

-greg

 

[John-Mason P. Shackelford]

Greg,

The last time I looked at Prawn (quiet a while ago) I don't remember
seeing the equivalent of add_text_wrap which became the basis for a
layout API I wrote which allowed one to define a series of text boxes
specifying x,y,width, height, and rotation angle and border and then
flow text into the first box and have it cascade through the rest. I'd
like to contribute something like this to Prawn, but it would be nice
if the fundamentals were there to support it. Did I miss the obvious
or does Prawn now support a function that allows one to flow text into
a box of specified width with the text which doesn't fit returned?

John-Mason

 

[Gregory Brown]

Greg,

The last time I looked at Prawn (quiet a while ago) I don't remember
seeing the equivalent of add_text_wrap which became the basis for a
layout API I wrote which allowed one to define a series of text boxes
specifying x,y,width, height, and rotation angle and border and then
flow text into the first box and have it cascade through the rest. I'd
like to contribute something like this to Prawn, but it would be nice
if the fundamentals were there to support it. Did I miss the obvious
or does Prawn now support a function that allows one to flow text into
a box of specified width with the text which doesn't fit returned?

I describe how to do this here:

http://prawn.lighthouseapp.com/projects/9398/tickets/113-single-line-of-text

But maybe instead, Prawn:ocument#text_box should return the
remaining parts of the string that were not rendered?
Aside from returning the remainder and handling rotation,
Prawn#text_box sounds exactly like what you've described here.

http://is.gd/h6x9

What do you think?

-greg

 

[John-Mason P. Shackelford]

Greg,

If Prawn#text_box returned the remaining text and supported
justification (at least left and center) and rotation, I'd have what
I need.

John-Mason Shackelford

Software Development Coach
Pearson

2510 North Dodge St.
Iowa City, IA 52245
ph. 319-354-9200x6214
(e-mail address removed)
http://pearsonschool.com

 

[Gregory Brown]

Greg,

If Prawn#text_box returned the remaining text and supported
justification (at least left and center) and rotation, I'd have what
I need.

Good to know. Please file a ticket in lighthouse:
http://prawn.lighthouseapp.com/projects/9398-prawn