Four Js Development Tools Forum

I sent this to support and now this feature request has been created.
Why I post it in the forum is basically to generate pressure :) but also to see if someone might have a workaround for this issue.
----------------------------
We really need the ability to preview PDF-files in Genero. Preferably by something similar as WEBCOMPONENT, but in a reliable way that works on all platforms.

This also has to be independent of GRE/GRV. Either we pass a filename (local to the server)  to the component or an URL.

History:

We have about 160 reports in our system. This is legacy code, and we don't use old 4GL reports for this, we wrote the report engine ourselves. The biggest problem with our current system is that all reports use fixed font, although we can apply some decorations to the output (Bold, Italic, Underline).

Now we have started using a PDF java library called iText (http://itextpdf.com/). I have modified our report engine to make use of that, so just by changing a few lines of code in each of our reports we now get columnar reports with proportional fonts that look so much better than the old ones.

In the old system, when the user runs a report he gets a preview of it in a TEXTEDIT. We just create a \<pre\> html page and the final report is reasonably presented. In the new system I generate a more complex HTML and it looks OK. However, we also have other reports that are based on filling out PDF-forms (possible in iText). These reports are impossibe to preview. Therefore we really need this functionality.

What do you think?

Hi Snorri,


Tip: quote the feature request number, that way it is easier to get fellow requesters added to the same request.



You say "preview", does this mean you want something less than "view"?

To "view", the answer is use the shellexec or the launchurl front-call.  That way you'll get the default PDF viewer for your desktop, or the default PDF viewer for your web browser (note also launchurl can be used from GDC).  This will give you the functionality of the viewer such as text search, printing etc.  What you won't get is this embedded inside a GDC window or a Genero Web Client web page.  A good way to think of this is its the same viewer as if you had received a PDF in an e-mail.

To "preview", one thing I did a few years ago with a demo I made for the Picture Flow Table style added in Genero 2.20.  I used a tool "imagemagick" http://www.imagemagick.org/ which amongst its functionality has the ability to create an image for each page of a PDF, something like in here http://superuser.com/questions/633698/convert-pdf-to-jpg-images-with-imagemagick-how-to-0-pad-file-names.  I then displayed the images in a Table with Picture Flow style container as per attached image.   

Reuben

(PS if you are the point of "starting using a PDF library called itext", you should probably re-consider using GRW)

Thanks Reuben for you reply.

The request number is #GDC-03088.

I am aware of the shellexec method but because of how our report writer works it's not good enough. For example, we warn the user if he closes the report window without printing the report (or saving it). This is because some reports take a long time to run and we don't want the user accidentally to close them. Another issue is that if the user re-runs the report he will be presented with a new document all the time, we have no way of closing the other instances of shellexec'd output.

Creating images from the pdf is a possibility, of course. There are some problems though, mainly that you will end up with lots of files (typically one for each page) and there are quality problems as well. I've tried various options with GhostScript and the outputted image tends to be "blurry".


As GRW is concerned we looked at that as well (of course!) Firstly, the GRW previewer is totally detached from a form, so you don't get all the control you'd like.  So there you have similar problems as with the shellexec method.  But most importantly, modifying  out reports to use GRW (rather than using the same function calls with few additions) requires 10 times more effort. That's because there is no way to programatically create a GRW report from scratch (unless you reverse-engineer the unpublished XML-layout of a GRW report file).

Thanks,
-Snorri