Using XPRINT for first time - Centering

[BOB MECHLER]

I'm learning XPRINT. Need to know how to center text on a page.

I've set scale
XPRINT SCALE (0,0)-(8.5,11) 'Inch scale for landscape mode (not sure)
I've positioned like this

XPRINT SET POS (5.5,4.25) 'Center of page

Now I want to print an arbitrary string ex ("This page left blank intentionally")

What do I do now?

Thanks,

Bob Mechler

[BOB MECHLER]

I'm guessing I just use the XPRINT TEXT SIZE statement and recalculate the position relative to the current position or just calculate and offset of where I want the reference center to be and subtract 1/2 the width of the text to be printed.

There seems to be an example in Help.

If that is all there is, then I can take it from here.

Thanks,

Bob Mechler

[Fred Buffington]

Bob, I think the scale will refer to the printable area rather than the entire page (unless the printer can print anywhere on the page).

Also, I think the center as you have defined it would be
xprint set pos (4.25,5.5)

personally i use 8.5*720 and 11*720 for my scale coming from doing a lot of
pcl programming. Of course I subtract from that left margin, right margin, top and bottom margins for my printable area.

[BOB MECHLER]

XPRINT had no problem creating over 40,000 pages using PDFCreator as the PDF printer. The program finished a pretty good while before PDFCreator and PDFSpooler finished the actual pdf in the assigned directory. Not sure how to tell when PDFCreator is actually finished except to periodically check the size of the file in the target directory and check whether the size of pdf file has stopped getting larger. It seems like it's running through the job twice. I think it is producing PostScript first and then converting to PDF since it has several output types.

Used Haru and got up to 8,000 pages before it started giving errors. I used the SlideShow example where the AddPage was associated with an array. Just starting playing with it so don't know if the pages should be created using arrays.

Bob Mechler

[Lee Bergeron]

This is what I do - Check to see if anything is in the SPOOLER. I check until
the Function returns 0.

FUNCTION GETSPOOL() AS LONG
        'RETURNS THE NUMBER OF SPOOL JOBS IN THE SPOOLER FOR "PDFCREATOR"
        'RETURNS -1 IF ERROR

   LOCAL n, nSize, needed AS LONG
   DIM pi(0) AS PRINTER_INFO_2
   DIM hPrn AS LONG


    FUNCTION = -1 'START WITH ERROR

    IF OpenPrinter("PDFCREATOR", hPrn, BYVAL 0) = 0 THEN  EXIT FUNCTION 'PRINTER ERROR
    IF hPrn = 0 THEN EXIT FUNCTION 'CAN'T OPEN THE PRINTER
    IF GetPrinter(hPrn, 2, BYVAL %NULL, 0, needed) = %FALSE THEN  'NEED TO FIND THE BUFFER SIZE TO USE
        IF GetLastError <> %ERROR_INSUFFICIENT_BUFFER THEN GOTO BADPRN 'SHOULD BE THE CORRECT ERROR
        n = needed \ SIZEOF(pi(0)): REDIM pi(n + 1)
        nSize = SIZEOF(pi(0)) * (n + 1)   'BUFFER SIZE NEEDED
        IF GetPrinter(hPrn, 2, pi(0), nSize, needed) = %FALSE THEN GOTO BADPRN  'REDO WITH CORRECT BUFFER SIZE
    END IF
    FUNCTION = pi(0).cJobs
BADPRN:
    ClosePrinter(hPrn) 'CLOSE THE PRINTER
END FUNCTION

[Michael Mattias]

CSET$ might be worth a look in the help file.

[BOB MECHLER]

Nice approach Lee, I'll definitely use this to let the operator know that the PDF is ready. This will be a nice feature to add to the XPRINT approach.

Ddoc however is what is failing. I've run it many time with PDFCreator not active at all. Clicking the .ddc as 131 meg gives me 44,000 blank pages.

I even used the ViewBuild and let it run right up to where the next command would be dpEndDoc and put a msgbox there. The Print Preview showed all data for 44,000 pages. As soon as I clicked OK on the message box, the next step in the program was dpEndDoc hfile&, %DDOC_END_CLOSE. At that point the data disappeared from the Preview screen for all 44,000 pages. This did not happend for 26,000 or less pages.

Bob Mechler

[BOB MECHLER]

What about Print Preview for XPRINT?

[BOB MECHLER]

The only option I can think of is to give a choice of a PDF output if a preview is desired otherwise send it to the printer of choice.

Bob Mechler

[Fred Buffington]

Bob, I wrote a print/print preview for xprint/graphic. I have been thinking about selling it but havent decided yet. Actually, i think part of it should be on the forum either in source code or windows -- i'll look.

yes, an older version of the script interpreting program is in PowerBasic for Windows.
I first did one to print labels which is what i think is there. I have since written another that is somewhat more comprehensive.

Here's basically what I do.
I write the information to a text file with a kind of script.
I then call a printer selection routine that looks like printer dialog.
I then call a dll that interprets the script and if preview has been selected,
it uses GRAPHIC bla bla, then if printing uses XPRINT bla bla.

In my case, it's intended for 8.5 x 11 or 8.5 x 14 reports.

[Michael Mattias]

The only option I can think of is to give a choice of a PDF output if a preview is desired otherwise send it to the printer of choice.

How about splitting it into two or more print reports?

ddoc P&P has a function to let you specify the starting page number for the second and subsequent reports. (I already do this so I know it works).

Also..... I'm not an Adobe guy, but I would think Acrobat would let you merge two or more *.PDF files if there is an "I want exactly one file" thing in play.

[BOB MECHLER]

It's not a page number thing. It's a run of customer statements (11,516 to be exact) anywhere from 1 to 6 pages long with a separator page. They send this single PDF to an outfit that plows throught the PDF and sends each customer statement to whichever printer is free in a printer cluster. They then fold, stuff, postal certify and send. Much cheaper than doing it in-house. Merging two PDF's might be the answer but don't know how to do that except through the COM interface in PDFCreator, which is over my head.

BOB MECHLER

[BOB MECHLER]

XPRINT is great!.

Just finished creating some functions that will either launch the real dp* command or it's XPRINT equivalent. Why do this? A 5200 line program with hundreds of dp* commands is why. After writing the function library for just the functions I needed, I just did a search and replace on the dp* and changed them to xp*.

Using this, I was able to get around when ddoc would fail right when dpEndDoc was issued when working with PDFCreator and over 40,000 pages.

The XPRINT version attaches up front to the PDFCreator driver and skips the .ddc creation step.

I decided to generally keep using DDOC since the investment and time is so huge but eventually we will flesh out the library of XPRINT work-alikes and not have to change the programs at all (Except for dp* to xp*).

The PDF's using the XPRINT stuff look exactly the same as running the DDOC version on a smaller number of statements so my problem is now solved.

Bob Mechler

[Michael Mattias]

Why do this? A 5200 line program with hundreds of dp* commands is why. After writing the function library for just the functions I needed, I just did a search and replace on the dp* and changed them to xp*.

You know, that give me an idea.

I, too was looking for a way to use the XPRINT functions to replace the aging ddoc P&P, but the problem was with ddoc P&P, the same command set can be used for both printer and screen output, which is not true of XPRINT. IIRC the print/preview example written by Mr Hagsten used XPRINT for printer output but requires the GRAPHICS statements to provide on-screen preview.

I wonder if I might not be able to take your idea one step further, passing a "mode" parameter to each of the "Xp*" functions, and using either (or both?) XPRINT or GRAPHICS statements in that function. That would make the actual "send something to output" code the same... kind of like Windows GDI functions, which just don't care if you are sending to a screen or a printer... a device context is a device context is a device context.

Hmmm..... verrrrrrry interesting....

[Fred Buffington]

I think, Michael, that's the basic idea in my print/preview program for xprint/graphics. I use a 6 character 'command' followed by paramaters.
the 'command' is surrounded by [ ].

then i just use select case, one for graphics preview, one set for xprint replacing the 'command' with either graphc bla bal or xprint bla bla.

[BOB MECHLER]

In my programs that might need to use these XPRINT/ddoc equivalents, I default to using ddoc by setting a global in my startup include at the top of PBMAIN. I then use the xp replacements but in the library I just pass along the parameters to the normal dp command if USE_DDOC is true. If the user has chosen to go directly to PDF, I just set USE_DDOC to false and the xp functions use the XPRINT equivalents. That way for most reports, I can still use the Ddoc preview and print until I can fully implement a replacement. I would probably set a member of a type variable to control whether the library uses the Graphic or Xprint commands later. Right now this works fine.

Bob Mechler