Having had a quick look at the Set_Printer('INIT') parameters of OI 9.3, it appears the best we can do at present is make a .PDF file.

Wouldn't it be cool if we could create an image file (bitmap would be fine) that we could then put on a web page?

are you familiar with Bob Carten's posting here?

The Sprezzatura Group

The Sprezzatura Blog

World leaders in all things RevSoft

»…on a web page - What about RTF

Hi Andrew and Barry

Thanks for your responses.

No I wasn't familiar with Bob's post but I was aware of that general possibility. No I don't think .RTF is the way to go. We just want to create and display an image.

Basically I already have some OI software that uses OIPI to create a unique graphic based on OI data. The easy option for me would be simply specifying .JPG or .BMP (instead of .PDF) as an OIPI output option. I would envisage that the image could then be displayed on a web page.

The alternative seems to be rewrite that software in something else that can plug into OI.

It seems to me that OIPI does a pretty good job of allowing the software developer to do some cool stuff - if only it could produce an image as an output.

Cheers

Robert

I wouldn't expect OIPI to export images. It's a document based reporting tool, and as such has options to export to various document formats.

If you wish to convert these to images, there are plenty of tools out there which can convert documents to images. The most popular seems to be ImageMagick.

The Sprezzatura Group

The Sprezzatura Blog

World leaders in all things RevSoft

We have luck with PDF to Image Converter from VeryPDF.

Dave Harmacek

Harmacek Database Systems

Hi Andrew and Barry

Thanks for your responses.

No I wasn't familiar with Bob's post but I was aware of that general possibility. No I don't think .RTF is the way to go. We just want to create and display an image.

Basically I already have some OI software that uses OIPI to create a unique graphic based on OI data. The easy option for me would be simply specifying .JPG or .BMP (instead of .PDF) as an OIPI output option. I would envisage that the image could then be displayed on a web page.

The alternative seems to be rewrite that software in something else that can plug into OI.

It seems to me that OIPI does a pretty good job of allowing the software developer to do some cool stuff - if only it could produce an image as an output.

Cheers

Robert

Hi, Robert.

Does this need to be a programmatic/automated process? Once you've generated the OIPI output, you could manually export it to a variety of output formats, including BMP, PNG, GIF, JPG and TIFF. Of course, I'm referring to output generated via OIPI.NET (where you have VSPRINTER2 specified in your CFG_OIPI record) rather than the original OIPI, and although the category is OIPI.NET I don't know for sure which one you're using now…?

Click on the little floppy disk on the OIPI.NET preview window (the "Save As" button), and see if you like any of the results you can generate from there.

Hope that helps,

- Bryan Shumsky

Revelation Software, Inc.

1. Yes this would be a programmatic/automated process.

2. Yes I am using OIPI.NET

3. Answer 1 would preclude using a Save As option and I presume using the pletora of available tools available to manually convert images.

I am of course aware that OIPI began life as a document production tool. Its just that it already has most everything one could wish for to programatically generate graphical images. You can put images on there, draw lines and circles - in colour. The language to do all these things is already well defined and well tested. An extra parameter or two in INIT to set the size of the image in pixels and image type and away we go…

…he said with a glint in his eye … just a SMOP … Simple Matter Of Programming …

1. Yes this would be a programmatic/automated process.

2. Yes I am using OIPI.NET

3. Answer 1 would preclude using a Save As option and I presume using the pletora of available tools available to manually convert images.

I am of course aware that OIPI began life as a document production tool. Its just that it already has most everything one could wish for to programatically generate graphical images. You can put images on there, draw lines and circles - in colour. The language to do all these things is already well defined and well tested. An extra parameter or two in INIT to set the size of the image in pixels and image type and away we go…

…he said with a glint in his eye … just a SMOP … Simple Matter Of Programming …

Well, when you do _manually_ use the available outputs, do they generate the kind of image that would work for you? If it's just a matter of providing other "export" formats - either via the INIT call, or via some other SET_PRINTER message - that may be something that can be added…

…but if the 'save as' images are still not what you're looking for, it's a bigger problem to solve, and thus isn't something to just "pop in" to the product, I'm afraid.

- Bryan Shumsky

Revelation Software, Inc.

Getting warm… Yes, any of the formats such as .png, .bmp, would be perfect (jpeg is more suitable for photos but ok).

So as far as I can tell, you would only need some new options in the INIT call to select say .png (and/or the other image options) as an output. I think the only other requirement would be to set the size of the image in pixels. At present the Save As option saves a whole page.

So I would want to be able to say that the image size should be 200 pixels wide by 50 pixels high for example.

Once the image generated and saved on the server it could be immediately displayed on a web page. How cool is that?

I would of course be happy to beta test…

My estimate … about one and a half to two SMOP's for a guy like you

OIPI employs a third party component to generate output. We can drive it but cannot extend it. I suggest using a virtual image printer driver. Once you install it you can set OIPI to use it as the printer. I used to do this to get PDFS before OIPI had the capability. Google will show you several free and commercial products. The commercial ones say they can be scripted.

- Bob

Getting warm… Yes, any of the formats such as .png, .bmp, would be perfect (jpeg is more suitable for photos but ok).

So as far as I can tell, you would only need some new options in the INIT call to select say .png (and/or the other image options) as an output. I think the only other requirement would be to set the size of the image in pixels. At present the Save As option saves a whole page.

So I would want to be able to say that the image size should be 200 pixels wide by 50 pixels high for example.

Once the image generated and saved on the server it could be immediately displayed on a web page. How cool is that?

I would of course be happy to beta test…

My estimate … about one and a half to two SMOP's for a guy like you

Try this code:

Filename = "TIFF Test Print":@FM:@FM:"107":@FM:"c:\temp\test.tif"

x = SET_PRINTER("INIT", FILENAME, "", "", 5:@vm:@vm:1)

x = SET_PRINTER("TEXT", "Outputting to a TIFF file")

For I = 1 to 10

 x = SET_PRINTER("TEXT", "Line ":I)

Next I

x = SET_PRINTER("TERM")

and then look in your temp directory for TEST.TIF. Does that work?

There are additional (and quite possibly not yet documented) export types available in OIPI.NET, including:

102: XLSX

103: DOCX

104: JPG

105: GIF

106: BMP

107: TIFF

Perhaps one of these will yield the output you're looking for? Note that there's no provision to pass in an output size, so you might need to call a resizing routine if you're not happy with what's generated by default.

Hope that helps,

- Bryan Shumsky

Revelation Software, Inc.

Ok Bryan, we are getting red hot now. Your code works perfectly! I have tweaked it slightly as below. I draw your attention to Parameter 3, fields 5 & 6 which allow us to set the size of the page in inches. I note that 600 pixels equates to 1 inch. So I have attempted to set the page size to 200 pixels wide by 50 pixels high. It seems in theory this should work. However, the image size ends up being 600 x 600 pixels. It appears that OIPI unnecessarily sets a minimum page size of one inch x one inch.

Thus it seems the only fix necessary to make all this work is removing this minimum page size, which in my estimate would only be about 0.1 of a SMOP. How about squeezing this into 9.3.1?

Cheers Robert

BTW, what's the number for a .png? (my personal preference).

$Insert O4WEquates

$Insert OIPrint_Equates

Declare Subroutine Set_Printer

Declare Function Get_Printer, Set_Printer

p1 = "TIFF Test Print":@FM:@FM:"107":@FM:"c:\Revsoft\pdf\test.tif"

p3 = 0

p3<2> = 0

p3<3> = 0

p3<4> = 0

p3<5> = 200 / 600 ;* 200 pixels wide.

p3<6> = 50 / 600 ;* 50 pixels high

p5 = 5:@vm:@vm:1

x = SET_PRINTER("INIT", p1, "", p3, "", p5)

Set_Printer("LINESTYLE", PS_SOLID:@fm:1:@fm:255)

Set_Printer("FILLSTYLE", HS_DIAGCROSS:@fm:0)

Set_Printer("RECT",0:@fm:0:@fm:200/600:@fm:50/600, 1)

x = SET_PRINTER("TERM", 1)

Return </QUOTE> —- === At 28 JAN 2012 12:05AM bshumsky wrote: === <QUOTE> <QUOTE>Ok Bryan, we are getting red hot now. Your code works perfectly! I have tweaked it slightly as below. I draw your attention to Parameter 3, fields 5 & 6 which allow us to set the size of the page in inches. I note that 600 pixels equates to 1 inch. So I have attempted to set the page size to 200 pixels wide by 50 pixels high. It seems in theory this should work. However, the image size ends up being 600 x 600 pixels. It appears that OIPI unnecessarily sets a minimum page size of one inch x one inch. Thus it seems the only fix necessary to make all this work is removing this minimum page size, which in my estimate would only be about 0.1 of a SMOP. How about squeezing this into 9.3.1? Cheers Robert BTW, what's the number for a .png? (my personal preference). $Insert O4WEquates $Insert OIPrint_Equates Declare Subroutine Set_Printer Declare Function Get_Printer, Set_Printer p1 = "TIFF Test Print":@FM:@FM:"107":@FM:"c:\Revsoft\pdf\test.tif" p3 = 0 p3<2> = 0 p3<3> = 0 p3<4> = 0 p3<5> = 200 / 600 ;* 200 pixels wide. p3<6> = 50 / 600 ;* 50 pixels high p5 = 5:@vm:@vm:1 x = SET_PRINTER("INIT", p1, "", p3, "", p5) Set_Printer("LINESTYLE", PS_SOLID:@fm:1:@fm:255) Set_Printer("FILLSTYLE", HS_DIAGCROSS:@fm:0) Set_Printer("RECT",0:@fm:0:@fm:200/600:@fm:50/600, 1) x = SET_PRINTER("TERM", 1) Return

Oh, sure, ask about that one!

You may have noticed that PNG is conspicuous by its absence; it's actually 108, _but_ in the current release I think that 108 is used twice by mistake, so you may or may NOT get a PNG if you use it. You should feel free to go ahead and give it a try, though.

Unfortunately, I don't think we _can_ make the image any smaller; there's an "unprintable" area that the document will not let you intrude upon, and I'd guess you've hit it. So…either you have to live with that minimum size, or you have to resize the image after it's produced - or you can try to use a variety of different printers and see if OIPI.NET will let you into that "unprintable" area depending on the defined printer.

Hope that helps,

- Bryan Shumsky

Revelation Software, Inc.

</QUOTE>

Papua New Ginea files are very hip these days. :wink: I tried 108 / .PNG as you suggested and it appears to work perfectly. I tried displaying it in a few different programs and none seemed to have a problem displaying it.

I'm not convinced the issue is related to an unprintable area. Did you try my code? It works perfectly producing a nice little red rectangle 200 pixles wide and 50 pixels high in the top left hand corner of a large 600 x 600 pixel image. It's not like it is objecting to me using that part of the "document". You will note I also set the margins to zero which it seemed happy to accept. I can set the "page size" perfectly to anything bigger than 600 x 600 (eg 610 x 625).

I'll bet someone who wrote OIPI years ago thought no one would ever want to "print" a document smaller than 1 inch x 1 inch and put some sneaky bit of code in there to stop this "absurdity". Remember when software developers never thought their software would still be being used in 2000? And the Internet would never need IP addresses bigger xxx.xxx.xxx.xxx? Something like that.

Eg

If Page.Size < 1 Then Page.Size = 1 :* Stop some noddy from being an idiot.

Why not just use html to define the image visible size?

Dave Harmacek

Harmacek Database Systems

Hi Dave

I have given your suggestion careful consideration and respond as follows.

I must admit my first reaction was that your suggestion that it was a bit of a fudge. I continued who work on the software that produced the little graphic that I wish to produce and I encountered a further limitation of OIPI when working on what it considers a very small "document" (less than 1 inch square) , namely font size. It appears that it wont attempt to use a point size smaller than say 1 or 2 or something like that (If font.size < 1 then font.size = 1).

Therefore, in order to make the font size appropriate in relation to the graphic image I need to make the image twice the size of what it would display on a web page. My graphic should display on a webpage at about 250 pixels wide and about 50 pixels high. However, if I make the image 500 pixels wide and 100 pixels high, then the smallest font size is appropriate to the image.

As you correctly alluded to the HTML <img> tag allows us to scale the image (<img width="300" height="300") which would scale my OIPI 600x600 (1 inch square) image down to a 300 x 300 image. The next issue is cropping the surplus unused white space to the right and bottom of the image. I have discovered I can crop an image by placing the <img> tag inside

tags and specify the width and height to crop the image to as follows:

<img width="300" height="300">

This is a long way of saying thank you for your suggestion - it appears to be a workable solution. Of course modern image formats such as .PNG don't waste a lot of space storing white space so no problem there.

Of course it wouldn't hurt if OIPI had its pagesize and font size (and any other) limitations eliminated in due course in order to make it a little easier to use as an image generation tool…

</QUOTE>

---

At 30 JAN 2012 07:01PM bshumsky wrote:

Of course it wouldn't hurt if OIPI had its pagesize and font size (and any other) limitations eliminated in due course in order to make it a little easier to use as an image generation tool…

Hi, Robert. I'm glad that you were able to find a work-around, using the tools already at hand.

I don't believe the modifications you suggested would be easy to make; if the problems you were encountering are indeed caused by "sanity checks" in the code, they are most likely located in the underlying .NET component that OIPI.NET is based upon, and thus beyond our direct control.

I think I can honestly say that the limitations (such as they are) are not overly burdensome to the majority of users, and so I predict that resolving these issues is going to be rather a low priority…

- Bryan Shumsky

Revelation Software, Inc.

---

At 30 JAN 2012 11:53PM Robert Lee wrote:

"I don't believe the modifications you suggested would be easy to make; if the problems you were encountering are indeed caused by "sanity checks" in the code, they are most likely located in the underlying .NET component that OIPI.NET is based upon, and thus beyond our direct control. "

I agree that it isn't a high priority now, although I don't seem to be quite out of the woods yet…

FWIW, I just noticed this in the Set_Printer('INIT') help:

"Always check the return code from the INIT message, because not all printers support custom page sizes. "

Perhaps this suggests that the "sanity checks" are in the Printer Driver not in OIPI…

Regardless, the following code works perfectly and generates the .PNG file into the Oinsight directory when run from the TCL. However, when this same routine is called from an O4W_ routine the Set_Printer('INIT',…) returns a 98 error code. I can't seem to find a list of OIPI error codes anywhere.

Any idea what an OIPI error 98 is?

---

At 31 JAN 2012 12:24AM bshumsky wrote:

"I don't believe the modifications you suggested would be easy to make; if the problems you were encountering are indeed caused by "sanity checks" in the code, they are most likely located in the underlying .NET component that OIPI.NET is based upon, and thus beyond our direct control. "

I agree that it isn't a high priority now, although I don't seem to be quite out of the woods yet…

FWIW, I just noticed this in the Set_Printer('INIT') help:

"Always check the return code from the INIT message, because not all printers support custom page sizes. "

Perhaps this suggests that the "sanity checks" are in the Printer Driver not in OIPI…

Regardless, the following code works perfectly and generates the .PNG file into the Oinsight directory when run from the TCL. However, when this same routine is called from an O4W_ routine the Set_Printer('INIT',…) returns a 98 error code. I can't seem to find a list of OIPI error codes anywhere.

Any idea what an OIPI error 98 is?

I don't know, off hand, what a 98 error is, but I do know what the problem you're encountering probably is.

OIPI interacts with the Windows GUI environment (even if you are just generating output to file), and thus is unavailable for direct calls in O4W (or any other environment that is run in a non-GUI, non-event context mode). Indeed, when we wish to generate PDFs in O4W, we must use RTI_TASK_SUBMIT to have a different (Windows-desktop-interacting) copy of OpenInsight generate the PDF for us (or, starting in 9.3, we can use the new Banded Report Writer, which does not require a GUI, event-context environment to generate output to file).

If your goal is to use O4W to generate the graphics, then, you'll need to use RTI_TASK_SUBMIT to have the graphics produced by a 'background process' OpenInsight, and then retrieve the results in your O4W procedure.

- Bryan Shumsky

Revelation Software, Inc.

---

At 31 JAN 2012 11:40AM bshumsky wrote:

However, when this same routine is called from an O4W_ routine the Set_Printer('INIT',…) returns a 98 error code. I can't seem to find a list of OIPI error codes anywhere.

Hey, wait a minute - you already know about RTI_TASK_SUBMIT (we've been discussing OIPI generation using it in a different thread). So…are you actually trying to run the OIPI from O4W here, or are you already using RTI_TASK_SUBMIT and it's failing?

- Bryan Shumsky

Revelation Software, Inc.

---

At 31 JAN 2012 04:54PM Robert Lee wrote:

<Embarrassed cough>. RTI_TASK_SUBMIT was last weeks lesson, which I forgot this week. I put it down to one of the following:

a) old age

b) Alzheimer's

c) Not enough coffee

d) Learning curve

e) Alll of the above.

---

At 31 JAN 2012 05:07PM bshumsky wrote:

<Embarrassed cough>. RTI_TASK_SUBMIT was last weeks lesson, which I forgot this week. I put it down to one of the following:

a) old age

b) Alzheimer's

c) Not enough coffee

d) Learning curve

e) Alll of the above.

You could have just used the old "that was a different Robert Lee posting those questions"…

- Bryan Shumsky

Revelation Software, Inc.

View this thread on the Works forum...