gerry@seq1.keele.ac.uk (G.D.Pratt) (03/18/91)
Does anyone have any ideas or code about how to find what the *real* edges of the printing area are on a PostScript printer. If I draw from 0,0 I have missing bits and need to find the real origin for a driver. cheers, gerry -- gerry pratt -- workstation support -- university of keele email: gerry@seq1.keele.ac.uk * tel: 0782 621111 x 3290 "these opinions are mine, mine, mine....ALL MINE I TELL YOU!"
marc@sequoia.cray.com (Marc Bouron) (03/19/91)
In article <1014@keele.keele.ac.uk>, gerry@seq1.keele.ac.uk (G.D.Pratt) writes: |> Does anyone have any ideas or code about how to find what the |> *real* edges of the printing area are on a PostScript printer. |> If I draw from 0,0 I have missing bits and need to find the |> real origin for a driver. |> |> cheers, |> gerry |> -- |> gerry pratt -- workstation support -- university of keele |> email: gerry@seq1.keele.ac.uk * tel: 0782 621111 x 3290 |> "these opinions are mine, mine, mine....ALL MINE I TELL YOU!" You could try translating to a known position in the centre of the page, and then draw graduated horizontal and vertical rules outwards to some place known to be off the page. Then just look to see where the lines stop! [M][a][r][c] ################################################################################ # # marc@sequoia.cray.com # . . # # Marc CR Bouron # M.Bouron@cray.co.uk (ARPA) # _|\ /|_ # # Cray Research (UK) Ltd. # M.Bouron@crayuk.uucp (DOMAIN) # (_|_V_|_) # # +44 344 485971 x2208 # M.Bouron@uk.co.cray (JANET) # | | # # # ...!ukc!crayuk!M.Bouron (UUCP) # # ################################################################################ -- [M][a][r][c] ################################################################################
toms@fcs260c2.ncifcrf.gov (Tom Schneider) (03/19/91)
In article <1014@keele.keele.ac.uk> gerry@seq1.keele.ac.uk (G.D.Pratt) writes: >Does anyone have any ideas or code about how to find what the >*real* edges of the printing area are on a PostScript printer. >If I draw from 0,0 I have missing bits and need to find the >real origin for a driver. > >cheers, >gerry >-- >gerry pratt -- workstation support -- university of keele >email: gerry@seq1.keele.ac.uk * tel: 0782 621111 x 3290 >"these opinions are mine, mine, mine....ALL MINE I TELL YOU!" I recently worked out a really perfect solution to this general problem. Run the following program on all of your printers: _____________________________________________________________________________ %! this is a PostScript program % version = 1.01 of printerarea.ps 1991 February 12 % This program determines the printable area of a printer % and prints the coordinates out in readable form. % In addition, it draws a rectangle around the area, % then it makes a series of shrinking rectangles to help % visualize where the boundary is. Finally, the corners % of all these rectangles are connected to a single % point on the image, to make it clear what is going on. % Tom Schneider % National Cancer Institute % Laboratory of Mathematical Biology % Frederick, Maryland 21702-1201 % toms@ncifcrf.gov erasepage /Times-Roman findfont 30 scalefont setfont /down {0 -50 rmoveto} def /print {gsave show 10 string cvs show grestore down} def % obtain the imagable area of the printer using initclip gsave initclip clippath pathbbox grestore %pstack % use this if you want to see the stack % while running the program % capture the corners of the imagable area % (see pathbbox in the red book) /ury exch def /urx exch def /lly exch def /llx exch def % use the following if you want to see the values % llx lly urx ury % pstack % this stack should match the first one % clear 150 450 moveto (printer imageable area:) gsave show grestore down % print the values llx ( lower left x [llx]: ) print lly ( lower left y [lly]: ) print urx (upper right x [urx]: ) print ury (upper right y [ury]: ) print urx llx sub (Delta x:) print ury lly sub (Delta y:) print urx llx sub ury lly sub div (Delta y / Delta x:) print /tospot { % draw a line to a special spot % to help keep track of what's happening gsave currentpoint moveto 200 500 lineto stroke grestore } def /roundstroke{ % draw a box around the area llx lly moveto tospot urx lly lineto tospot urx ury lineto tospot llx ury lineto tospot llx lly lineto tospot stroke } def /shift 20 def % amount to decrease the area each time /shiftinward { % reduction of the area by the amount shift /ury ury shift sub def /urx urx shift sub def /lly lly shift add def /llx llx shift add def } def % draw a series of decreasing boxes to help figure % things out roundstroke shiftinward roundstroke shiftinward roundstroke shiftinward roundstroke shiftinward roundstroke showpage _____________________________________________________________________________ The 4 numbers given by the program define the exact region used by the printer. But, as you may have noticed, it is a pain to try to line up two pages. For example, I have three "printers": OpenWindows on a Sun4, an apple laserwriter and a Tektronix colorquick (doing PostScript thanks to a Freedom of the Press program). The print area decreases progressively as one passes from one to the next, so black and white pictures that come out fine on the apple are chopped off on the colorquick. The solution was to find the clip area of the colorquick, and to draw a rectangle around the outer edge of this. On OpenWindows and the laserwriter it shows up as a rectangle. On the colorquick the rectangle is EXACTLY one point outside the printable area and so does not show up! So to use it, I merely make sure that my image shows up in the rectangle, and get a perfect print on the colorquick "every time"! Here is the program I attach to the top of my color PostScript graphics: _____________________________________________________________________________ % set the clip area to the Tektronix colorquick printer's % version = 2.01 of colorquick.ps 1991 Mar 1 /llx 40 def /lly 40.33 def /urx 571.7 def /ury 752 def /newarea{ % draw a box around the area llx lly moveto urx lly lineto urx ury lineto llx ury lineto llx lly lineto clip } def /printedge 1 def /bigger{ /llx llx printedge sub def /lly lly printedge sub def /urx urx printedge add def /ury ury printedge add def } def /smaller{ /llx llx printedge add def /lly lly printedge add def /urx urx printedge sub def /ury ury printedge sub def } def gsave bigger newarea 0 setgray fill smaller grestore newarea gsave 1 setgray fill grestore _____________________________________________________________________________ The first four numbers were the ones given by the first program. I'd like to know how well this pair of programs works for people. Tom Schneider National Cancer Institute Laboratory of Mathematical Biology Frederick, Maryland 21702-1201 toms@ncifcrf.gov
mzellers@starnet.uucp (Mark Zellers) (03/22/91)
> >In article <1014@keele.keele.ac.uk>, gerry@seq1.keele.ac.uk (G.D.Pratt) writes: >|> Does anyone have any ideas or code about how to find what the >|> *real* edges of the printing area are on a PostScript printer. >|> If I draw from 0,0 I have missing bits and need to find the >|> real origin for a driver. >|> >|> cheers, >|> gerry >|> -- >|> gerry pratt -- workstation support -- university of keele >|> email: gerry@seq1.keele.ac.uk * tel: 0782 621111 x 3290 >|> "these opinions are mine, mine, mine....ALL MINE I TELL YOU!" > If you want to find the boundaries of the imageable area (rather than the paper) try using clippath pathbbox to get the llx lly urx ury of the current clipping path (which is by default the imageable area). Mark H. Zellers marc.com!bwayne!mark
stefan@shiva.systemware.de (Stefan Stapelberg) (04/15/91)
In article <1991Mar21.190956.21412@starnet.uucp> mzellers@starnet.UUCP (Mark Zellers) writes: >If you want to find the boundaries of the imageable area (rather than >the paper) try using > > clippath pathbbox > >to get the llx lly urx ury of the current clipping path (which is by >default the imageable area). My troff->postscript converter produces the following code to compensate for the lower boundary of the imageable area (lly) and to set a variable `pgtop' (top of page), which will be used (in procedure `Y') to compute the absolute vertical position from a given distance to the TOP. clippath pathbbox pop pop exch pop 0 exch translate clippath pathbbox /pgtop exch def pop pop pop /Y { pgtop exch sub currentpoint pop exch moveto } bind def IMHO this violates the rules of page independence, since the boundaries of the imageable area don't change if this output is scaled down and included within another document. Is this correct? I am also curious what the response for 'clippath pathbbox' would be on a Linotronic. Does the Lino return the physical dimensions of the imageable area or the values which may have been previously set with 'setpageparams'? Thanks in advance for any hints. __ Stefan Stapelberg, <stefan@systemware.de>
stephenf@suite.sw.oz.au (Stephen Frede) (04/17/91)
In <1473@shiva.systemware.de> stefan@shiva.systemware.de (Stefan Stapelberg) writes: >My troff->postscript converter produces the following code to compensate >for the lower boundary of the imageable area (lly) and to set a variable >`pgtop' (top of page), which will be used (in procedure `Y') to compute >the absolute vertical position from a given distance to the TOP. > clippath pathbbox pop pop exch pop 0 exch translate > clippath pathbbox /pgtop exch def pop pop pop > /Y { pgtop exch sub currentpoint pop exch moveto } bind def >IMHO this violates the rules of page independence, since the boundaries >of the imageable area don't change if this output is scaled down and >included within another document. Is this correct? Looks like tpscript code. When I wrote it (a long long time ago) there were no guidelines for page independance, and it was long before EPS. But in any case, programs that generate multi-page documents are much more likely to want to include other documents within them, than to be included themselves. Even enough independance for page-reversal programs etc is very difficult. Maybe in the next release (not soon) I'll add an option for EPS generation if only a single page is produced. Regards, - Stephen Frede Softway Pty Ltd, P.O. Box 305, Strawberry Hills, NSW 2012, AUSTRALIA Phone: +61 2 698 2322; Fax: +61 2 699 9174; Telex: AA27987 domain: stephenf@softway.sw.oz.au UUCP: ...!uunet!softway.sw.oz!stephenf