[pro] Professional Reports
I am looking for tips to create professional multi-page reports, invoices, etc, preferably producing standalone files like PDFs that can be emailed. Automatic page calculation would be great, and I'd like to include generated and static images (e.g. graphs and logos). The solution does not have to be open source, although most of my applications are web based for which I do prefer GNU Linux as a hosting platform (I am a LispWorks user and have both Linux and Windows licenses). I know about cl-pdf and cl-typesetting, although I have only had a fleeting glance at them. Maybe there is an easy WYSIWYG layout editor that a list member can recommend among the hordes that Google spits out. How do list members typically solve this (boring) problem with their CL applications? Regards. Nico
We use cl-pdf and cl-typesetting directly (as part of invoice generation), creating some text, layout, adding images, etc. We email many of them, and then use pdftk on the command line to join all PDF invoices into one big file for easy printing. We don't have to deal with page numbers, but I think pdftk's "multistamp" or "multibackground" function could be probably be used (abused?) to apply page numbers. See http://www.pdflabs.com/docs/pdftk-man-page/ Thanks, Ryan Davis Acceleration.net Director of Programming Services 2831 NW 41st street, suite B Gainesville, FL 32606 Office: 352-335-6500 x 124 Fax: 352-335-6506 On 5/19/2011 2:11 AM, Nico de Jager wrote:
I am looking for tips to create professional multi-page reports, invoices, etc, preferably producing standalone files like PDFs that can be emailed. Automatic page calculation would be great, and I'd like to include generated and static images (e.g. graphs and logos).
The solution does not have to be open source, although most of my applications are web based for which I do prefer GNU Linux as a hosting platform (I am a LispWorks user and have both Linux and Windows licenses).
I know about cl-pdf and cl-typesetting, although I have only had a fleeting glance at them. Maybe there is an easy WYSIWYG layout editor that a list member can recommend among the hordes that Google spits out.
How do list members typically solve this (boring) problem with their CL applications?
Regards. Nico
_______________________________________________ pro mailing list pro@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro
On 19/05/2011 08:11, Nico de Jager wrote:
I am looking for tips to create professional multi-page reports, invoices, etc, preferably producing standalone files like PDFs that can be emailed. Automatic page calculation would be great, and I'd like to include generated and static images (e.g. graphs and logos).
The solution does not have to be open source, although most of my applications are web based for which I do prefer GNU Linux as a hosting platform (I am a LispWorks user and have both Linux and Windows licenses).
I know about cl-pdf and cl-typesetting, although I have only had a fleeting glance at them. Maybe there is an easy WYSIWYG layout editor that a list member can recommend among the hordes that Google spits out.
How do list members typically solve this (boring) problem with their CL applications?
Regards. Nico
_______________________________________________ pro mailing list pro@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro
I have used cl-pdf and cl-typesetting in a commercial web application but only for small stuff and I do not recommend it for large reports with multi-page tables and so. You do not want to become a pixel counter. I prefer using LaTeX now. Used it with MixTex in a C# project. Generate a LaTeX source file, run it through xelatex a couple of times and you are done. In Lisp it should be even better because you can write some nice macros to hide your LaTex macros. -Jan
On May 18, 2011, at 11:11 PM, Nico de Jager wrote:
I am looking for tips to create professional multi-page reports, invoices, etc, preferably producing standalone files like PDFs that can be emailed. Automatic page calculation would be great, and I'd like to include generated and static images (e.g. graphs and logos).
The answer depends upon how fancy and whether or not criteria may shift radically over time. Not for everyone and may be overkill for your particular needs: For the extreme case, I generated LaTeX and TeX much like one /might/ produce HTML: concatenating static portions and generated portions. This gave the most flexibility of known options in 2005, when I was getting back into CL and didn't know of all the places to look for libraries. (Thanks Xach for Quicklisp and liberating us from those dark ages!) While this resembles "not invented here" syndrome, we knew that our tables required very specialized styling unsupported by libraries found at that time: e.g., some column groups having two extra risers/labels, minimal use of grid lines, etc. Some criticized this approach and suggested DocBook, but I perceived that to be bloated beyond my baseline loathing of xml. I found the TeX/LaTeX approach more familiar based upon strict HTML and CSS (you can see TeX's influence on HTML and CSS), and people we hired appreciated the decision as well. Start here: www.tug.org and www.latex-project.org -Daniel PS - for completeness, the project started in Python, and Lisp came later. I'd take the same approach now that I've been almost exclusively in CL since then, assuming the same criteria. -- first name at last name dot com
you can use either Tex/LaTex or cl-pdf and cl-typesetting depending on the project requirements and/or constraints. In general the way I work is avoid going on tangent about layout perfection and pixels counting/optimization. I'd do paper prototyping (pencil and paper), iterate as needed, then computer sketch (using inkscape) and when i get almost satisfied look I'll start coding the details you can automate a little bit of the process by doing the design in Inkscape and then parse the output SVG file to generate the cl-pdf and/or cl-typesetting code. (try using cl-html-parse). keep it simple and avoid the tendency of trying to develop a full svg2cl-pdf parser/compiler. this will help in case you wanted to hire a designer who will take care of pixels optimization. Regards, Ala'a On Thu, May 19, 2011 at 10:11 AM, Nico de Jager <ndj@bitart.cc> wrote:
I am looking for tips to create professional multi-page reports, invoices, etc, preferably producing standalone files like PDFs that can be emailed. Automatic page calculation would be great, and I'd like to include generated and static images (e.g. graphs and logos).
The solution does not have to be open source, although most of my applications are web based for which I do prefer GNU Linux as a hosting platform (I am a LispWorks user and have both Linux and Windows licenses).
I know about cl-pdf and cl-typesetting, although I have only had a fleeting glance at them. Maybe there is an easy WYSIWYG layout editor that a list member can recommend among the hordes that Google spits out.
How do list members typically solve this (boring) problem with their CL applications?
Regards. Nico
_______________________________________________ pro mailing list pro@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro
be emailed. Automatic page calculation would be great, and I'd like to include generated and static images (e.g. graphs and logos).
we use cl-typesetting and cl-pdf. page numbers are *kludged* by generating the entire document twice... unicode characters were a headache, but this might be fixed since then. we had some major headaches with this framework, because these libraries have a tendency to fail quietly (e.g. numbers are quietly not rendered into table cells when they don't fit). if i were to start today, i'd either generate libreoffice's xml format (you can exec commandline tools to generate pdf); or look into using latex, although i have zero first-hand experience with it. the former, if libreoffice was just a little bit smarter, could yield a brilliant templating engine: - you edit the initial template with libreoffice - save it in xml - using xml namespaces, you introduce your "unquote"'s that generate the dynamic part. these chunks may contain libreoffice xml nodes down deep somewhere, which LO should be smart enough to display (e.g. when generating a table, then the xml node describing a literal table cell would be lying somewhere under the unquote xml nodes. LO could provide a list of nodes it understands for editing, and leave xml nodes it doesn't understand untouched.) - hand out the template for the users for editing with LO we have something less sophisticated (no WYSIWYG editing under the first unquote). unfortunately LO is not too friendly for such use-cases (e.g. no unnamed inline styles; xml node order matters and styles must be emitted first. argh...) -- attila Notice your eroding (digital) freedom, and do something about it! PGP: 2FA1 A9DC 9C1E BA25 A59C 963F 5D5F 45C7 DFCD 0A39 OTR XMPP: 8647EEAC EA30FEEF E1B55146 573E52EE 21B1FF06 BitCoin: 154uf86Vd9rpjMULd9CXa7nVwikknYZJiB
On 05/22/2011 11:05 AM, Attila Lendvai wrote:
unfortunately LO is not too friendly for such use-cases (e.g. no unnamed inline styles; xml node order matters and styles must be emitted first. argh... s/LO/Microsoft Office 2003 xml/ as well, though the Office 2003 single file xml formats are a convenient target for MS centric environments.
if i were to start today, i'd either generate libreoffice's xml format (you can exec commandline tools to generate pdf);
I tried this two years ago and ran into some problems. As I remember: OpenOffice (of which Libre Office is a fork) had a weird client-server model for command-line use. It was a pain to set up initially, and the version of OpenOffice that came with Debian on our servers didn't work at all. The best way to check if a document would finish being printed as a PDF was to poll the filesystem. It took a long time to generate the PDFs, and what's worse is that this time varied widely with no apparent causes. The whole process was unreliable. The templating itself was tricky. As you mentioned the node order matters, but also there were all sorts of undocumented dependencies between nodes (I was templating spreadsheets) and how node attributes were used. Maybe things have improved by now, but if I had to do the same thing again I would not rely on Libre Office. There's too much bloat to deal with on both the development and system administration sides. The big draw with Libre Office was that you can let business users easily customize the templates. A friend of mine is doing a SaaS web app in Common Lisp, generating documents via LaTeX, and is making a small web app that lets users customize the template layout. IMO this is simple enough to do that it's the approach I would use today (using CL-PDF or maybe cl-typesetting directly instead of going through LaTeX). Vladimir
I just remembered one project I came across recently: http://code.google.com/p/wkhtmltopdf/ I would consider using that also, and wish I had come across it earlier. Templating or generating HTML documents is very convenient, and if you're doing a web front end, you have all the libraries you need already. Vladimir On Tue, May 24, 2011 at 3:30 PM, Vladimir Sedach <vsedach@gmail.com> wrote:
if i were to start today, i'd either generate libreoffice's xml format (you can exec commandline tools to generate pdf);
I tried this two years ago and ran into some problems. As I remember:
OpenOffice (of which Libre Office is a fork) had a weird client-server model for command-line use. It was a pain to set up initially, and the version of OpenOffice that came with Debian on our servers didn't work at all. The best way to check if a document would finish being printed as a PDF was to poll the filesystem. It took a long time to generate the PDFs, and what's worse is that this time varied widely with no apparent causes. The whole process was unreliable.
The templating itself was tricky. As you mentioned the node order matters, but also there were all sorts of undocumented dependencies between nodes (I was templating spreadsheets) and how node attributes were used.
Maybe things have improved by now, but if I had to do the same thing again I would not rely on Libre Office. There's too much bloat to deal with on both the development and system administration sides.
The big draw with Libre Office was that you can let business users easily customize the templates. A friend of mine is doing a SaaS web app in Common Lisp, generating documents via LaTeX, and is making a small web app that lets users customize the template layout. IMO this is simple enough to do that it's the approach I would use today (using CL-PDF or maybe cl-typesetting directly instead of going through LaTeX).
Vladimir
participants (8)
-
Ala'a Mohammad -
Attila Lendvai -
Daniel Pezely -
Jan Tolenaar -
Matthew D. Swank -
Nico de Jager -
Ryan Davis -
Vladimir Sedach