TABLE FILE CAR
PRINT
'CAR.ORIGIN.COUNTRY'
'CAR.COMP.CAR'
BY 'CAR.CARREC.MODEL' NOPRINT
ON TABLE NOTOTAL
ON TABLE PCHOLD FORMAT HTML
ON TABLE SET STYLE *
UNITS=IN,
SQUEEZE=ON,
ORIENTATION=PORTRAIT,
$
TYPE=REPORT,
GRID=OFF,
FONT='TIMES NEW ROMAN',
SIZE=10,
LINES-PER-PAGE=20,
$
TYPE=REPORT,
IMAGE=app/alogo.gif,
POSITION=(+0.000000 +0.000000),
SIZE=(2.000000 0.500000),
$
ENDSTYLE
END


The above code is generationg output for the format HTML ..But if i change the format to "PDF" it giving me this error :
(FOC3251) IMAGE FILE UNREADABLE OR INVALID: alogo.gif

This message has been edited. Last edited by: Kerry,

The image must be in an Application Folder for PDF reports. And leave out the '/app'.

Francis is right, for an HTML report, the image must be available to the Webserver, but with PDF must be available to the WebFOCUS server.

When the HTML report is generated, a link to the image is created, and put in the HTML.

For the PDF report, WebFOCUS needs to include the image in the PDF document, therefore the image must be available in the path specified.

APP SHOWPATH will show you the path currently set.

WHENCE will show you if a file is in the current path.

e.g.WHENCE myimage GIF|JPEG

Waz, thanks for taking the time to explain.

I think that it is important to understand why it has to be done this way.

Yeah, good one Waz!

I think the product documentation might do a better job at explaining the difference as its examples assume that both the Web Server and Reporting Server run in the same box and therefore any of them have access to the same image files. Reality check happens when both components live in different boxes and then is when the difference in access methods can be appreciated. Summarising what Waz previously explained:

HTML -> Produces a tag with a URL pointing to the image location which must be accessible to the webserver via HTTP (could indeed be a file hosted anywhere in the internet as long as the web server can see it).

PDF -> Document is "built" by the Reporting Server and later sent to the client, therefore image files must be available in an APP PATH visible to the reporting server because it is there where the PDF document is "assembled" including the image(s).

Prasad, if you want to use the very same physical file for HTML and PDF reports even when the web server and reporting server live in different boxes, you can attempt do the following although I am not suggesting that you use this technique in your Production environment; it could just be something you'd want to play with to better understand the concept:

Create an application directory in the reporting server where you'll keep your images and add it to your APP PATH. This way you can produce PDF documents with embedded images. Let's assume you call that directory "app_images" and that you want to include my_image.gif image file in a PDF report. Your stylesheet would look like:

APP PATH APPEND app_images  <- This is just to remind you that app_images must be "visible"
TABLE FILE blah
...
ON TABLE PCHOLD FORMAT PDF
...
TYPE=..., IMAGE=my_image.gif, $  <- This file is visible to the rpt. server via APP PATH

When it comes to HTML documents, you can still use a URL to reference the image located in "app_images" by using the Reporting Server's HTTP listener as follows:

TABLE FILE blah
...
ON TABLE PCHOLD FORMAT HTML
...
TYPE=.., IMAGE=http://rep_server_host:8120/approot/app_images/my_image.gif,$  <- URL to the image file in the rpt. server

The example above assumes that EDASERVE (or whatever name your node uses) is installed in the "rep_server_host" box and is listening on port 8120.

This is just an example and does not elaborate on specific security restrictions/best practices you may have implemented in you site.

- Neftali.

This message has been edited. Last edited by: njsden,

Thats well explained Neftali!!!!

Thank You vey much... It really solved my problem...

Rated

quote:

WHENCE will show you if a file is in the current path.

Nice! I did not know about that command Waz. It would have helped me a lot before when I was dealing with certain issues we had in an environment with multiple profiles and disparate application paths. Well, it's never too late and I will certainly find opportunities to use it from now on so I guess it's time to go back to the "playground".

Thanks much Waz

It was thanks to this forum that I found out about it.

I think it was Tony A.