evaluation of ruport
tr
I've a simple application I would like to enable exports/reports from
"normal" data the user is looking at when using the application (there
he can filter, sort, show/hide columns). My main question is if there
will be an option in the future to properly export special chars
(language depended ones like German ü,ö,ä and ß) to PDF?
As far as I read the PDF::Writer doesn't support UTF8, but may support
UTF16 sometime in the future. So are there any experiences yet in
exporting to PDF using some other encodings like ISO ones with
rendering the special chars successfully (I just need a solution for
the de_DE locale).
Thanks,
thorsten
Gregory Brown
>
> Hi All,
>
> I've a simple application I would like to enable exports/reports from
> "normal" data the user is looking at when using the application (there
> he can filter, sort, show/hide columns). My main question is if there
> will be an option in the future to properly export special chars
> (language depended ones like German ü,ö,ä and ß) to PDF?
We're using PDF::Writer for our implementation, so we are essentially
limited by it. We're not particularly fond of the library, but it's
the most comprehensive one available in pure Ruby and the only one
that seems to do everything we need.
We'd have better i18n support if we found a PDF library that supports
UTF8 or UTF16 and our users ported our existing functionality to it.
Unfortunately, I haven't seen many options that aren't quite painful
for this. It bothers me, because I would like to see Ruport be as
friendly as possible to the international community.
> As far as I read the PDF::Writer doesn't support UTF8, but may support
> UTF16 sometime in the future.
I would not count on ever seeing forward advancement on PDF::Writer.
(No offense to Austin). We've been waiting on SVG support since
October 2005, as a point of reference. It just turns out that he's
become too busy to push forward the library.
> So are there any experiences yet in
> exporting to PDF using some other encodings like ISO ones with
> rendering the special chars successfully (I just need a solution for
> the de_DE locale).
For some reason, I think I recall someone generating PDFs with these
special chars in them with Ruport. I may be mistaken. Timo, didn't
you have some data like this?
We have at least a few other German users on this list, so they'd know
better than me. Perhaps they could share their experiences.
Timo Springmann
On Tuesday June 5 2007 15:40, Gregory Brown wrote:
> For some reason, I think I recall someone generating PDFs with these
> special chars in them with Ruport. I may be mistaken. Timo, didn't
> you have some data like this?
As far as I can tell, there're no problems with umlauts when generation PDFs
using ruport's pdf writer. I just checked it again, as I wasn't sure I really
tested it with some umlaut. Result: Generating PDFs with data out of my
postgres database containing umlauts are no problem over here.
Regards,
Timo
tr
Hi Timo,
thanks to you as well. I assume your data is stored as ISO-8859-1 in
your pgsql db? As I tested Ruport a couple of months ago and
experienced problems with my UTF8 data from pgsql in the reports. So
the easiest solution for me would be to convert my UTF8 data to ISO
before generating the PDF or is my assumption wrong and maybe I just
made a mistake in my first tests?
Kind regards,
thorsten
Timo Springmann
> thanks to you as well. I assume your data is stored as ISO-8859-1 in
> your pgsql db?
That's right. I've had some other (rails-/html-) problems with my database
running with utf8. I've converted everything to latin and since then it's
working...
Regards,
Timo
James Healy
> thanks to you as well. I assume your data is stored as ISO-8859-1 in
> your pgsql db? As I tested Ruport a couple of months ago and
> experienced problems with my UTF8 data from pgsql in the reports. So
> the easiest solution for me would be to convert my UTF8 data to ISO
> before generating the PDF or is my assumption wrong and maybe I just
> made a mistake in my first tests?
For the benefit of those unfamiliar with encoding issues, there is a blog
post on converting utf-8 to ISO-8859-1 to use in pdf::writer here:
http://www.peterkrantz.com/2007/utf8-in-pdf-writer/
Definitely an inferior solution to full Unicode support, but it might
have to do in the interim.
I had a brief look at the PDF spec a month or 2 ago to see how hard it
would be to monkey patch pdf:writer with Unicode support, but
unfortunately the task was beyond the limited amount of free time I
have. The spec is > 1200 long and not for the feint-hearted!
-- James Healy <jimmy-at-deefa-dot-com> Wed, 6 Jun 2007 23:34:02 +1000
tr
James, I also stubled accross the URL you posted 2 hours ago. That's a
really helpful one as my DB is currently in UTF8. Here's just one
addendum to the URL as the overwritten 'text' method doesn't help with
the table content generated by ruport.
If you add the following code to the environment.rb in a rails app it
works for me pretty well:
require 'pdf/writer'
$CONVERTER = Iconv.new( 'ISO-8859-15//IGNORE//TRANSLIT', 'utf-8')
module PDF
class Writer
alias_method :old_add_text, :add_text
def add_text(x, y, text, *options)
old_add_text(x, y, $CONVERTER.iconv(text), *options)
end
end
end
It just generates some warnings in my dev-env when starting up WEBrick
as the pdf/writer is requiring himself transaction/simple causing
these warnings. If somebody has an idea how to get rid of these I
appreciate any help - but again, these are just warnings ;-)
c:/_ruby/ruby/lib/ruby/gems/1.8/gems/transaction-simple-1.4.0/lib/
transaction/simple.rb:46: warning: already initialized constant
Messages
c:/_ruby/ruby/lib/ruby/gems/1.8/gems/transaction-simple-1.4.0/lib/
transaction/simple.rb:53: warning: already initialized constant
TRANSACTION_SIMPLE_VERSION
c:/_ruby/ruby/lib/ruby/gems/1.8/gems/transaction-simple-1.4.0/lib/
transaction/simple.rb:436: warning: already initialized constant
SKIP_TRANSACTION_VARS
Kind regards,
thorsten
Gregory Brown
>
> $CONVERTER = Iconv.new( 'ISO-8859-15//IGNORE//TRANSLIT', 'utf-8')
>
> module PDF
> class Writer
> alias_method :old_add_text, :add_text
> def add_text(x, y, text, *options)
> old_add_text(x, y, $CONVERTER.iconv(text), *options)
> end
> end
> end
maybe someone could package this as a Ruport plugin so that I can do
something like
class MyFormatter < Ruport::Formatter::PDF
use_utf8_converter
#... proceed as normal here
end
If someone puts something together, I'd be happy to host it @
gems.rubyreports.org
James Healy
A post on ruby-talk
(http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/227890) led me on a bit of a chase for a guide on how to
generate unicode PDF's without pdf:writer.
http://gir.deefa.com/rcairo_pdf_output.pdf is a pdf generated with the
cairo ruby bindings (rcairo). I'm no PDF expert, but it looks to me like
that's Unicode. I created the output by running
http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt through the
text2.rb sample code in the samples directory of rcairo.
The documentation is pretty bare, but it looks like it has potential. If
no one else gets to it first, I'll try and poke at some ideas for ruport
integration this weekend.
-- James Healy <jimmy-at-deefa-dot-com> Thu, 7 Jun 2007 00:33:36 +1000
Gregory Brown
> The documentation is pretty bare, but it looks like it has potential. If
> no one else gets to it first, I'll try and poke at some ideas for ruport
> integration this weekend.
Nice. Though I'll be the first to say 'not it', it'd be neat to have
rcairo support, either directly in Ruport or via ruport-util,
depending on what makes the most sense (ease-of-installation)
Even if you get as far as investigating the feasability, we'd be in good shape.
urbanus
> he can filter, sort, show/hide columns). My main question is if there
> will be an option in the future to properly export special chars
> (language depended ones like German ü,ö,ä and ß) to PDF?
> As far as I read the PDF::Writer doesn't support UTF8, but may support
Openoffice.org supports UTF8, and specifically German. You can
generate OpenDocument reports from Ruby or Ruby on Rails using
Documatic.
Regards,
Dave
Gregory Brown
Does Documatic generate nice tables? It'd be interesting to see how
it handles that, because it might be interesting to hook it up to
Ruport's Tables, which would open a whole lot of doors.
urbanus
> Does Documatic generate nice tables? It'd be interesting to see how
> it handles that, because it might be interesting to hook it up to
> Ruport's Tables, which would open a whole lot of doors.
As nice as you like. :) You create the table with whatever headers
and formatting you want. Then you loop over a row (or rows) inserting
values in the cells using ERb. There's a trivial example on the
website you can try out.
I want to put up a more complex example on the website, showing a
grouped report similar to Crystal Reports. For example, sales broken
up by region with subtotals for each region, and a grand total at the
end. You can do those sorts of things with Documatic.
I agree with you that it would be interesting to see how Ruport's data
structures, like Tables, could be utilised with Documatic as the
rendering engine. (I wonder if Documatic could become an add-in for
Ruport.)
Regards,
Dave
Gregory Brown
>
> > Does Documatic generate nice tables? It'd be interesting to see how
> > it handles that, because it might be interesting to hook it up to
> > Ruport's Tables, which would open a whole lot of doors.
>
> As nice as you like. :) You create the table with whatever headers
> and formatting you want. Then you loop over a row (or rows) inserting
> values in the cells using ERb. There's a trivial example on the
> website you can try out.
I guess my concern here is that it seems very easy for trivial
examples, but it might blow up in certain practical uses. For
example, does oOo gracefully handle wrapping the text and splitting it
across pages properly?
Do you have a meaningful way of paginating the output?
This kind of templating seems ideal for a specific form letter or
something like that, but I'm having trouble mentally seeing how it
would work if I say, had to generate a 500->1000 page report. (Which
is the bulk of the kind of work i'm doing)
> I want to put up a more complex example on the website, showing a
> grouped report similar to Crystal Reports. For example, sales broken
> up by region with subtotals for each region, and a grand total at the
> end. You can do those sorts of things with Documatic.
Please ping me when you have this up, sounds interesting.
> I agree with you that it would be interesting to see how Ruport's data
> structures, like Tables, could be utilised with Documatic as the
> rendering engine. (I wonder if Documatic could become an add-in for
> Ruport.)
That's along the lines that I'm thinking. It would be nice if
Documatic focused as nearly as possible on templating for oOo, and
didn't need to tackle things like handling grouping or table
manipulations or other things that really belong in Ruport. :)
To make Documatic an addon to Ruport, there are three ways you can do
it, they're listed in order of least to most autonomous. :)
1. Work with me to get it into ruport-util
2. Set up documatic as a gem plugin, by just depending on Ruport and
Gem::Plugin. This would just allow those who download documatic to
snap it into Ruport with any other plugins they might be running. It
would also work standalone, as long as you set your library up that
way.
3. We can set up a shim plugin that mallets Energon and Ruport
together, but keeps both of the libraries independant.
---
I've told the maintainer of Energon the same thing I'll mention here:
I can't look deeply into this until I have a project that requires it.
But if anyone is out there that wants to take the initiative, I'm
happy to help. I also will try to investigate further soon so I know
which of the above possibilities might make sense.
-greg
PS. We've got a mostly working csv2ods utility in ruport-util, on a
semi-related note. It should be released in the next couple days.
Gregory Brown
> 3. We can set up a shim plugin that mallets Energon and Ruport
> together, but keeps both of the libraries independant.
s/Energon/Documatic , whoops
Gregory Brown
>
> > Does Documatic generate nice tables? It'd be interesting to see how
> > it handles that, because it might be interesting to hook it up to
> > Ruport's Tables, which would open a whole lot of doors.
>
> As nice as you like. :) You create the table with whatever headers
> and formatting you want. Then you loop over a row (or rows) inserting
> values in the cells using ERb. There's a trivial example on the
> website you can try out.
Ran the examples. Your use of erb seems promising, makes documatic a
whole lot more powerful than the gap-filling based approach of
Energon.
I guess what we need is something that we can stick in the template
now that tells it to render a Ruport::Data::Row|Table|Group|Grouping.
That would officially rock. :)
urbanus
> I guess my concern here is that it seems very easy for trivial
> examples, but it might blow up in certain practical uses. For
> example, does oOo gracefully handle wrapping the text and splitting it
> across pages properly?
OpenDocument table cells are containers for block-level elements such
as paragraphs (and even other tables). Things like wrapping are not a
problem: the wrapping is dictated by the style of the paragraph (left,
right, centre etc.).
With OOo you have the option of specifying whether a row can break
across pages and columns, or not.
> Do you have a meaningful way of paginating the output?
The output will flow across pages automatically, just as with any
other OOo document. You can also force page and section breaks by
setting up an appropriate paragraph style in OOo: you go to "Text
Flow", "Breaks", turn on "Insert" then specify the sort of text break
you want. Then you can put that text break anywhere in your document
using the para() helper in a "Ruby Block" marker.
> This kind of templating seems ideal for a specific form letter or
> something like that, but I'm having trouble mentally seeing how it
> would work if I say, had to generate a 500->1000 page report. (Which
> is the bulk of the kind of work i'm doing)
I can't say I've had to do a 500 to 1000 page report with Documatic
yet, but I don't see that there would be any problems. As far as I
can tell, the text would just flow and it would all be sweet.
> Please ping me when you have this up, sounds interesting.
Sure.
> That's along the lines that I'm thinking. It would be nice if
> Documatic focused as nearly as possible on templating for oOo, and
> didn't need to tackle things like handling grouping or table
> manipulations or other things that really belong in Ruport. :)
Bingo. That's exactly the philosophy Documatic takes: you prepare the
source data in whatever format suits you and send it to Documatic for
rendering. Documatic doesn't constrain you in terms of what data you
can pass to it. Mmm, maybe Documatic really could be a good
supplement for Ruport...
> But if anyone is out there that wants to take the initiative, I'm
> happy to help. I also will try to investigate further soon so I know
> which of the above possibilities might make sense.
Yes, I'd be willing to look into this. I'll let you know how I go.
Regards,
Dave
Gregory Brown
> > But if anyone is out there that wants to take the initiative, I'm
> > happy to help. I also will try to investigate further soon so I know
> > which of the above possibilities might make sense.
>
> Yes, I'd be willing to look into this. I'll let you know how I go.
Great. This all sounds pretty promising. I'm not up on my OOo that
much, but manveru knows his stuff, it seems. Between us, maybe we can
get something going.
I'm sure this topic will come up at the roundtable.
tr
I did'n know about Documatic yet (even that I'm using Goldberg maybe
you should setup http://240gl.org/ pointing to all of your projects?).
As for today I have to have PDF support directly generated from the
webapp I'm developing I've to use Ruport. But review the discussion
between you and Greg I'm looking forward to OpenDocument support in
Ruport as personally I always prefer the more open alternative, so I
at least would like to offer it within the application.
Kind regards,
thorsten
James Healy
I've put together a little wrapper that uses cairo and pango underneath
a PDF::Writer like API called PDF::Wrapper.
It's still just a proof of concept, and is not really usable for
real-world scenarios yet, but it can place utf8 text and svg/png images
onto the canvas and render to a string or file.
I'm intending to continue hacking at it over the next week, so any
feedback is welcome. To use it, the ruby bindings for cairo and pango
are required. Both are available via apt-get in debian/ubuntu, and the
cairo ones at least are available as a gem. On non-linux platforms I'm
unsure of their availability so i'd be interested in hearing if people
get it working.
Linkies: http://gir.deefa.com/pdfwrapper.rb
-- James Healy <jimmy-at-deefa-dot-com> Mon, 11 Jun 2007 15:00:05 +1000