Announcement

Collapse
No announcement yet.

Using XPRINT for first time - Centering

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Using XPRINT for first time - Centering

    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

  • #2
    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

    Comment


    • #3
      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.
      Client Writeup for the CPA

      buffs.proboards2.com

      Links Page

      Comment


      • #4
        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

        Comment


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

          Code:
          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

          Comment


          • #6
            CSET$ might be worth a look in the help file.
            Michael Mattias
            Tal Systems (retired)
            Port Washington WI USA
            [email protected]
            http://www.talsystems.com

            Comment


            • #7
              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

              Comment


              • #8
                What about Print Preview for XPRINT?

                Comment


                • #9
                  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

                  Comment


                  • #10
                    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.
                    Last edited by Fred Buffington; 14 Jan 2008, 10:43 PM.
                    Client Writeup for the CPA

                    buffs.proboards2.com

                    Links Page

                    Comment


                    • #11
                      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.
                      Michael Mattias
                      Tal Systems (retired)
                      Port Washington WI USA
                      [email protected]
                      http://www.talsystems.com

                      Comment


                      • #12
                        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

                        Comment


                        • #13
                          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

                          Comment


                          • #14
                            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....
                            Michael Mattias
                            Tal Systems (retired)
                            Port Washington WI USA
                            [email protected]
                            http://www.talsystems.com

                            Comment


                            • #15
                              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.
                              Client Writeup for the CPA

                              buffs.proboards2.com

                              Links Page

                              Comment


                              • #16
                                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

                                Comment

                                Working...
                                X