Print invoices from linux

[Vaalen]

Hi,

We use a rather old character-based application, which is running on a linux platform (redhat). We use openedge 10.2A.
To print invoices we use preprinted paper.

We would like to print invoices on plain A4-paper. This includes logo's and so on.
Ofcourse we could buy an application, but they are quite expensive.

Just wondering if anyone here has any experience with this? Any tips would be appreciated.

Thanks in advance.

 

[tamhas]

For an all ABL solution, consider PDFInclude http://www.oehive.org/pdfinclude
Otherwise, consider a reporting package with good format controls and do this and lots else.

 

[Vaalen]

Thanks Tamhas.

I think pdfinclude is worth trying.

 

[medu]

or you can use a java reporting engine and once you have the report designed (with a nice graphical tool) you can run the report and save it in what ever document format you like most... i've just finish the poc on a report engine loader for Jasper Report, i can even load the report preview from progress (even from character mode in windows, on linux it should work if you are in graphical mode or you can export the terminal with xming or something like that).

normally the data access gets through jdbc using SQL but now you can call a plain abl 'stored procedure' over appsrv or use plain abl for each syntax if you have the proper driver

 

[Vaalen]

Thank you medu.

The knowledge of Java here is non-existing. We do NOT have any sort of graphical interface on linux.
I am not sure I understand what you are writing.

 

[medu]

The knowledge of Java here is non-existing.

nor do you need any, see http://jasperforge.org/projects/jasperreports

once you have designed the report in jasper report designer you can simply call it from progress and make it output the result in PDF, Word, Excel or send it to the printer.

 

[Vaalen]

Ah, thank you.

I will look into that too.

 

[tamhas]

The choice of pdfinclude vs a reporting tool is one that depends on context. With pdfinclude there is some learning curve, but you stay 100% in ABL and probably you are happy about the investment if you never do a second document. With the reporting tool, the up front learning curve will be higher, you are having to learn skills which are not ABL, and the payback probably comes because you use the tool for many projects. There are many reporting tools. Some open source; some you have to buy. Some seem very easy to learn and some not. If there is a role in your organization for making more reports than just this invoice "pretty" (which there might not be if you are ChUI Linux!) or there is a role for a tool that allows non-programmers to do some of their own reporting, then the reporting tool approach can be very attractive. But, if this invoice is the only thing you are ever going to do, chances are the pdfinclude route will require less work.

 

[medu]

Well I beg to differ, the learning curve with PDF Include is far longer that what is required to do some mouse-driven report design in a visual manner. It used to be a good tool, I used it myself for a while when all I knew was Progress and if you think that you should do everything in ABL no matter what then yes it might be a choice. But once you shift a bit from that ABL mind set you'll find there are a lot of other options out there that means a lot less effort to implement.

The fact that the Progress application runs on linux in text mode does not mean that there are no graphical environment on workstations, a linux desktop or a windows workstation is probably something that everyone has around so you can use that to design the report in a graphical mode... to print or export the report in PDF, Excel, Word does not require a graphical environment so it can be done from linux chui.

 

[tamhas]

I suppose learning curve is relative to both the experience base of the user and the difficulty of the problem. I saw a demo of CyberQuery a few months back and it was very impressive in what it could do with very little work and how it could produce a pretty interesting report without having to do any actual programming. And, one could do little bits of programming to express things that might be hard to express in the graphical interface without having to take over the whole thing. But, I didn't get a good sense of what it could do if one was very fussy about the output ... as people sometimes are about their invoices ... or what happened when the logic got really complex. I know that some years ago I kept being disappointed in reporting products because they were good at doing the simple stuff ... where "pretty" wasn't actually critical, but fell down when it came to the hard stuff and basically provided no solution at all for that ... i.e., it didn't do that which was the most important. The one exception to this was Actuate in which I did some horrifically complex things and it never fell down on me. I haven't really kept up with what is available these days except when it drops in my lap, like that CyberQuery demo at a PUG meeting, so I can't speak to what is available today, but it still seem clear that there is a lot more justification for considering a reporting tool to solve the invoice if one is also going to use it for other things.

 

[Vaalen]

Wow, this is some discussion.

I just started to explore pdfinclude. The samples are really bad, the latest changes are not yet documented.
A lot of trying I guess. But I think for our purpose (at this moment all we want is to reduce the paper cost) of printing invoices it seems promising.

Thank you both for your input, I see lots of study coming

 

[tamhas]

There is a support community at both OE Hive and on PEG list for the purpose.

 

[Casper]

Well compared to progress examples I thought pdfInclude was pretty ok. The samples all have the corresponding programs with it and they are easily tweaked. Most of the library is documented. I think you find it pretty easy to catch up with it. If you put a days work in it you have a pretty ok invoice I think.

 

[Vaalen]

Actually, yes, that's true.
The thing that bothers me though is the positioning. I am just trying and trying until I have a number that seems to do the trick.
There should be a better way. Any suggestions?

 

[medu]

Actually, yes, that's true.
The thing that bothers me though is the positioning. I am just trying and trying until I have a number that seems to do the trick.
There should be a better way. Any suggestions?

hehehe, didn't i just said there is quite a difference between a blind design and a graphical wysiwyg report designer?

and beside that you mess-up all your code that retrieves data and do computations (BL) with report output formatting (UI more or less)... i'm sure one have a lot of fun when it need to add a new column somewhere before the last one, more fun with matching numbers

if you think a report designer is somehow a better way then i've just finished the abl bridge to Jasper Report and one can export/print/preview reports directly from progress client and you can simply pass it the result-set temp-table as input... and as it is java you don't loose anything on os independence side (for preview a graphical environment is needed... might be unix/linux x-server as well).

 

[Vaalen]

Thank you Medu.

I will take a close look at jasperreports. I guess I have to download proprint from the openedge hive?

 

[medu]

I guess you can use that, from what I knew it's going to start java through a command line and have the data passed in XML format using a temporary file. What I was working on is using a shared library approach that loads the Java virtual machine and directly call the report engine methods passing data as in-memory XML or let the report engine connect to the database server using JDBC. It provides report print/export in a non graphical environment and print preview if a graphical environment is available, supports reports with parameters and using JDBC it can even connect to external databases or to the Progress business logic through our own ABL JDBC driver (through Progress Application Server).

 

[Vaalen]

I think for your approach I would need some Java knowledge, which I haven't.

 

[medu]

I think for your approach I would need some Java knowledge, which I haven't.

You need no Java knowledge at all, there is a library and an OO implementation for Progress ABL. If you don't like Jasper Report and prefer Birt (as being based on Eclipse you can use it in OE Architect environment) this engine will probably be added in the next days, other Java reporting engines might be added in the future.

The only thing is I did not go open-source with that one and I don't have plans to do it right now, so it's more like a product than a free beer

 

[Vaalen]

There is a library somewhere to be found in the openedge hive?