Does anyone oppose the PDF project idea?
Gregory Brown
some support from the community.
However, both the Ruby 1.9 Field Medic and the documentation projects
have been criticized here and there as lacking a unified focus and
being a bit unwieldy.
So far, no one has opposed the creation of a first class PDF library
for Ruby. It seems that many people believe this is an important
thing for Ruby, and as someone who has dealt with a lot of pain
wrapping PDF::Writer in Ruport, I can't help but agree.
In an attempt to work towards some sort of consensus, here are the
pros (from my standpoint) of the project:
1) Ruport's core library only has two dependencies, FasterCSV and
PDF::Writer. Ruport 1.6 will ship with shims that will allow our CSV
support to work with Ruby 1.9's stdlib version of FCSV, leaving only
PDF::Writer and Ruport itself to be ported. We are working on 1.9
support for PDF::Writer currently, but it is a slow process. I could
develop a new library on 1.9 from the ground up, ensuring it will be
compatible, and making porting Ruport a lot easier.
2) I need the time to fully read the massive (1300+ pg) PDF spec,
which I haven't done yet. Working on a PDF::Writer replacement will
actually help me maintain the existing codebase in the interim, as
well.
3) James Edward Gray II has investigated issues in PDF::Writer and
seems to think with a redesign, it'll be quite easy to get much better
performance out of library, especially table drawing support.
4) I have *tons* of sample projects I could use for test cases, which
will help speed progress on this. I'd be basically working on a
library which I'd be using every day, which may be more beneficial
than documentation and tutorials about libraries I'm just getting to
know.
5) Designing from the ground up, we may be able to integrate with
PDF::Reader, giving you a complete PDF tool.
6) Even if you don't do PDF work day to day, it's a very common need.
It will be good for Ruby if one of our most-trodden libraries was
extremely good, instead of just 'doing the job'. I'm not discounting
Austin's work, he did us a great service, and his solution was likely
the right one at the time, but with everyone moaning about good
library support in Ruby, this is a good chance to put a dedicated
effort into having a good example to shut people up with!
7) Prawn may be the coolest name I've ever come up with for a
project. Even if it's only destined to be temporary. :)
That's my hard sell on the project. Let me know if you have any
doubts.
I still think the other two projects have a lot of merit, but I must
admit this is my favorite one, and it seems to be the favorite among
those who've spoken up so far, too.
-greg
Gregory Brown
On Mar 26, 11:18 am, Gregory Brown <gregory.t.br...@gmail.com> wrote:
> It seems like all three of the 'official' project ideas[0] have had
> some support from the community.
Matt Todd
simply for the fact that I do not use PDF generation software in my
projects (though, in some cases, it may be useful).
I'd be OK with you working on it (especially considering I haven't
donated yet), but, in my opinion, better community documentation is
more beneficial overall.
But then again, if there was a better PDF library available,
especially one that can take HTML and generate a printable page, it
may be ultimately better.
Matt
Gregory Brown
>
> While I'm not directly against the idea, I am not entirely for it,
> simply for the fact that I do not use PDF generation software in my
> projects (though, in some cases, it may be useful).
>
> I'd be OK with you working on it (especially considering I haven't
> donated yet), but, in my opinion, better community documentation is
> more beneficial overall.
The tricky thing, I think, will be agreeing on 'which' documentation
is most beneficial.
I think we'll end up with a situation where I can hit a large range of
topics, offering "something for everyone",
but at the expense of depth as well as the efficiency hit of context switching.
Don't get me wrong, I enjoy writing. Kicking out an article or two a
week will probably earn me more friends in the community,
and also help me practice my tech writing skills.
Still, this lacks the appeal of a single concrete goal that is present
in the PDF project.
Thanks for sharing your thoughts, I anticipated that the project may
not be some people's first picks, if they are not doing PDF work.
It's good to know both where you stand on the topic, as well as the
fact that you'd be okay with me working on the project,
even if it's not your favorite of the three.
-greg
Thomas Wieczorek
from project to project adding documentation and fixing things to let
them run on 1.9 seems to me like more work with a lot of effort. Even
though I am not using PDF creation a lot(converting documents), I'd
like to see a professional library for that.
To the documentation effort: What projects did you think of? I am
interested in helping, but I don't know really where to start. This
seems like a good idea to dwelve deeper in other code and learn a good
bit.
Gregory Brown
JEG2 was the one who suggested this, and the libraries he suggested were:
RACC, NArray, Mongoose and/or Kirbybase
With 13+ weeks of funding, we'd need to come up with a whole lot more
possible topics if we went with that idea. The cool thing about a
documentation effort is I could make a printed-book-at-cost version
($5-$7) of it if I reserved a few weeks to typeset it.
Still, it sounds like you're supporting the general sentiment here
that the PDF project may have the least surprises and friction
surrounding it...
-greg