28 replies to this topic

[Lewis Mccabe]

We have had some direct emails sent to us regarding a reporting solution. I will follow up with additional information as well as company information if the interested firms will permit us to release their names (to help generate interest). I will also check with PRO-IV and see where they are in addressing this issue or if they are interested in moving forward with us.

Anyone interested in moving forward with this in any capacity, please let us know. I will put this subject in a new topic shortly after I have compiled some information.

Lew

Edited by Lewis Mccabe, 08 April 2004 - 03:49 PM.

[Sindre Solem]

Regarding the questions about our Pro-IV -> XML + XSL -> PDF solution.

We only use this method for form type reports, not for lists. With list reports, the layout (e.g. lines, fonts, etc)
aren't so important for our users, and regular Pro-IV printing is quicker.

When you already have a report function in Pro-IV, changing it to output to XML isn't difficult. We use a few
global logics to initialise the XML file and add records to it, all within the existing report characteristics.
We don't use the native XML report, because we made this solution before Pro-IV could ouput XML. And still
there are a couple of limitations with the Pro-IV XML report that makes it unusable for us.

Overall, not much extra work to be with the report function, once you have the framework ready.

The XSL stylesheet is where most work will be needed, depending on how complex the report is. If it is only
a list, you only have to list the tag names and adjust the sizes.

As I said, we only use the solution for form reports, e.g. invoices. Many of these need some of the information
accurately placed on the paper, for OCR scanning, and will require some fine tuning.

We also have a couple reports that produce graphs that is made with SVG in the stylesheet. It works very
well, but requires some effort to program.

Joseph: Page breaks are not an issue with XSL FO. From what you write, I guess your reference is HTML. With
XSL FO (and PDF) you work with pages and and you can specify static headers and such.
Check it out at "http://xml.apache.org/fop".

I've attached a sample. Warning: Norwegian language is used.

And I'll attach one more sample to show how graphs are included.

Attached Files

•  test.pdf   16.32KB   285 downloads

[Sindre Solem]

An example with graphs.

Attached Files

•  test2.pdf   221.15KB   308 downloads

[Rob Morgan]

Sindre,

sorry to barge in on this thread but is it possible for you to contact me or give me a way of contacting you?

I am moving to Norway at the end of June and would like to have a chat.

mail to :info@rpms-recruitment.com
tel : 0044 7710 497137

[George Macken]

Hi Andy Kay,

In your initial posting you mention that Adobe/Jetform has no processing power.

Has Jetform the functionality to apply some formatting to text data, like in Word where formatting can be applied to alpha data. The immediate issue is to convert data like GEORGE MACKEN to George Macken.

Of course this can be remedied by outputting the data in the required format, and more longer term ensure the source data is in the correct format.

If anyone knows of a Jetform solution for this issue then your reply is required.

Thanks

George

[Kevin Bruss]

I used the Jetform 5.26 Designer on a site for about a year and a half and don't recall such an option. I know you can do italics, bolding, underlining within the designer, as well as with control strings prior and after the string in question.

Perhaps someone can upload their jetform designer manual in pdf form as I don't have access to it anymore.

We used a 'dictionary table' (as part of Glovia's MultiLingual package) which
allowed us to "translate" a phrase of text to a different language for use as
headers and such on common reports. But in this case, perhaps even a global logic may be well suited to format the string prior to passing it
to the (.tmp/.dat) file for jetforms to process. That, or perhaps a quick SQL update for a particular field within a table that can fix the formats for you.. but it won't stop any future incidents of new entries.

[mdexter]

We have used Crystal Reports for about 9 years with great success. There is no runtime cost to customers unless they want to customize the reports. We can distribute the client-side runtime programs as part of our application with no royalties. If a customer wants to customize their reports, the cost for the Crystal program is reasonable (around $500).

Crystal has state-of-the-art runtime interface and development environment.

The only catch is that you need to be able to connect to the database. This of course is no problem if you are using a SQL database. Crystal also reads XML, so that might work from PRO-IV. (But we haven't tried that.)

We generally do the processing in PRO-IV (i.e., to prepare temporary report tables) and then using Crystal to view and print the report.

Hope this helps. Mark Dexter

[gdmjdkc]

I just found this thread and have some issues with Crystal.

Do you have any problems with the interface with Crystal?

We have Crystal 10 and have problems with the user interface activex control. We have pushed back to Crystal and they have recreated the issue. The problem, from what we have been told, is in the DLL. It has been 9 months now and they have not come up with a solution.

If we want to send the reports directly to the printer and not allow user interface it works perfectly.

[mdexter]

We are not using the Acitive-X interface. We wrote a DLL program that we call from PRO-IV using the LINK_CLIENT command. This DLL in turn calls the Crystal Runtime Print Engine API (CRPE32.DLL). This has worked well for us, including in V10. However, Crystal tells us that this is no longer being supported and that we need to switch to the Active-X or .NET interface. We will be looking into this sometime in the next year.

What problems are you having with the V10 interface? Mark Dexter

[gdmjdkc]

1. The V10 ActiveX control does not simply plug into ProIV. It required a Visual Basic wrapper before it could interface properly. Hopefully that issue will be solved with the release of version 6 of ProIV.

2. When you sending the print directly to print preview, ProIV will crash on the initial instance. After the initial crash ProIV and Crystal will run correctly.

3. If you allow the user the interface control which allows the use to cancel, print or print preview and the user selects cancel print it will crash ProIV every time.

We have been working with ProIV and Crystal with this issue and Crystal has stated that the problem is with their DLL and it only affects Visual Basic interfaces. We have been patiently awaiting them to implement a fix, but as of this writing none has been announced. We have been hoping that other users would also have this issue and contact Crystal with the problem.

[mdexter]

If this is a problem just with Crystal V10, you could use Crystal V9. You should still be able to use V10 to create and edit the RPT files and just use the V9 control to view and print the reports. As far as I know, there were no significant changes made in V10 that would cause problems viewing reports in V9.

Otherwise, it sounds like you don't have a good option there. It's too bad, because Crystal has been a great reporting tool for us. Mark Dexter

[GBabula]

Joseph,

Are you still using HTML to generate reports, or have you moved on to something else? If you are still using HTML, are you using CSS to format, or are you just using embedded tags in the file you dynamically generate?

Up to now we have just been using stock ProIV reports for the limited printed output we generate, but I have a project now for which I need to generate professional looking forms with a logo, proportional fonts, font attributes, and boxes around data elements. The need is not yet to the point of justifying a product like PlanetPress, so I've been trying to render this in HTML. It's been slow going!

I'm just curious about what you've done since your post here.

~G

[George Macken]

Hi G

How many reports are you looking for ?

Out client (large Insurance Company) is using
1) Jetforms for production of client-facing documents (100+ forms/letters/etc.,)- tnks to AK for advising on this - I think JF would meet your requirements below.
2) Business Objects for MIS reports and also come client-facing documents
3) Some Pro-IV reports

From some other postings on the forum I've seen professional looking outputs developed using Excel, again AK seems to be knowedgeable of Pro-IV & Excel.

Depending on the DB you are using there may be report applications available and also depending on how user friendly you DB is. Its really a combination of the right tools (Pro-IV, Excel, BO, JF) and the right person using the tools.

hope this helps

Rgds

George

[GBabula]

Thanks. Right now it's just a handful of documents so I was trying HTML before looking to purchase third-party software. Most of our output will just be form letters that need to have our logo on them, so using HTML is not so bad. There's just one form that needs more sophisticated format that's proving difficult to render.