CXT105@psuvm.psu.edu (Christopher Tate) (11/04/90)
When transforming the coordinate space into landscape orientation, what is the "accepted" procedure for placing the origin? As I see it, there are a couple of possibilities: First, you could move the origin over to the other physical corner of the page, like this: Before: | After: | | | | | <-- right left --> | | ===> | | edge of edge of | +------- ----+ | paper paper | | (X axis) (Y axis) +------------ ---------+ (0,0) (0,0) Or, you could move the origin (0,0) to be the corner of the *IMAGEABLE* page, instead of being offset from the corner by some small amount. Or, third, you could try to arrange it so that the offset from the origin to the corner of the imageable region of the page is the same after the transformation as it was before. Kind of "All I did is cut some stuff off of the top, and added some stuff on the right" in effect. Which of these is "right?" I'm tempted to use the last method, which preserves any positioning offset from the origin exactly. What say the rest of you? ------- Christopher Tate | "Living in a fisheye lens, caught | in the camera eye; I have no cxt105@psuvm.psu.edu | heart to lie: I can't pretend a {...}!psuvax1!psuvm.bitnet!cxt105 | stranger is a long-awaited friend." cxt105@psuvm.bitnet | -- Rush, "Limelight"
woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) (11/04/90)
The generic way to do landscape is 612 0 translate 90 rotate. This suffices for anything that I need to do. You wind up with the page rotated, and the lower left corner is 0, 0 just like it would be normally, except that the width is now 792 and the hight is 612 Cheers Woody
lee@sq.sq.com (Liam R. E. Quin) (11/06/90)
woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) claims that > The generic way to do landscape is > 612 0 translate 90 rotate. This is not in the least generic! Anyone who, like me, has spent years using North American software in England and Europe knows that it's often hard to get support for A4 and A3 paper... wiring in the size of the page in this way makes it very hard to change. Until recently I'd never _seen_ a printer that could print on anything as _weird_ as 8.5 x 11 inch paper, the `standard' American size. You could do /PaperWidth 72 8.5 mul cvi def % width of a page in PostScript points PaperWidth 0 translate 90 rotate though, and that's much better. Lee -- Liam R. E. Quin, lee@sq.com, SoftQuad Inc., Toronto, +1 (416) 963-8337
jef@well.sf.ca.us (Jef Poskanzer) (11/06/90)
In the referenced message, lee@sq.sq.com (Liam R. E. Quin) wrote: }woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) claims that }> The generic way to do landscape is }> 612 0 translate 90 rotate. } }This is not in the least generic! }You could do }/PaperWidth 72 8.5 mul cvi def % width of a page in PostScript points }PaperWidth 0 translate 90 rotate }though, and that's much better. Looks the same to me. If you really want to avoid paper-size dependencies, try something like this: newpath clippath pathbbox newpath % llx lly urx ury 3 -1 roll % llx urx ury lly sub % llx urx height /pageheight exch def % llx urx exch sub % width /pagewidth exch def pagewidth 0 translate 90 rotate Jef Poskanzer jef@well.sf.ca.us {ucbvax, apple, hplabs}!well!jef "I like a man who grins when he fights." -- Winston Churchill
aas@boeygen.nr.no (Gisle Aas) (11/07/90)
In article <21504@well.sf.ca.us> jef@well.sf.ca.us (Jef Poskanzer) writes: > Looks the same to me. If you really want to avoid paper-size dependencies, > try something like this: > > newpath clippath pathbbox newpath % llx lly urx ury > 3 -1 roll % llx urx ury lly > sub % llx urx height > /pageheight exch def % llx urx > exch sub % width > /pagewidth exch def > pagewidth 0 translate 90 rotate To get the right pageheight/width you have to add together ury/x and lly/x. The clippath defines an area smaller than the physical page. -- Gisle Aas | snail: Boks 114 Blindern, N-0314 Oslo, Norway Norsk Regnesentral | X.400: G=Gisle;S=Aas;O=nr;P=uninett;C=no voice: +47-2-453561 | inet: Gisle.Aas@nr.no
woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) (11/08/90)
In article <1990Nov5.194437.12060@sq.sq.com>, lee@sq.sq.com (Liam R. E. Quin) writes: > woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) claims that > > The generic way to do landscape is > > 612 0 translate 90 rotate. > > This is not in the least generic! Anyone who, like me, has spent years using This is a well taken point. Basicaly, I was saying that the simplest way was to do a translate followed by a rotate. I totaly overlooked the obvious 8). I have an A5 tray, and a legal tray, but I've never seen a sheet of A5 sized paper in my life, and the only reason for the legal tray was a contract job for one of my clients. 8} This brings up a good question, and there is probably an answer, but I have not taken the time to look it up, as I have never needed it, but is there a standard way to determine what the width of the page and the height of the page is? I would assume that the current clip path would do it. Cheers Woody > printer that could print on anything as _weird_ as 8.5 x 11 inch paper, the > `standard' American size. > > You could do > /PaperWidth 72 8.5 mul cvi def % width of a page in PostScript points > > PaperWidth 0 translate 90 rotate > > though, and that's much better. But it *still* assumes 8.5 inch paper. granted, you can alter it manualy, but it is essentially no better than 612 .... Cheers
jef@well.sf.ca.us (Jef Poskanzer) (11/08/90)
In the referenced message, Gisle.Aas@nr.no wrote: }> newpath clippath pathbbox newpath % llx lly urx ury }> 3 -1 roll % llx urx ury lly }> sub % llx urx height }> /pageheight exch def % llx urx }> exch sub % width }> /pagewidth exch def } }To get the right pageheight/width you have to add together ury/x and }lly/x. The clippath defines an area smaller than the physical page. You're saying I should add instead of subtracting? That doesn't make sense to me. Could you be more specific? Provide corrected code perhaps? --- Jef Jef Poskanzer jef@well.sf.ca.us {ucbvax, apple, hplabs}!well!jef "If two wrongs don't make a right, try three." -- Laurence J. Peter
aas@boeygen.nr.no (Gisle Aas) (11/09/90)
In article <21532@well.sf.ca.us> jef@well.sf.ca.us (Jef Poskanzer) writes: In the referenced message, Gisle.Aas@nr.no wrote: }> newpath clippath pathbbox newpath % llx lly urx ury }> 3 -1 roll % llx urx ury lly }> sub % llx urx height }> /pageheight exch def % llx urx }> exch sub % width }> /pagewidth exch def } }To get the right pageheight/width you have to add together ury/x and }lly/x. The clippath defines an area smaller than the physical page. You're saying I should add instead of subtracting? That doesn't make sense to me. Could you be more specific? Provide corrected code perhaps? As far as I can see the following code is correct, but it depends on the clippath being centered on the physical page: %! initgraphics clippath pathbbox newpath 3 -1 roll % llx urx ury lly add % llx urx height /pageheight exch def % llx urx add % width /pagewidth exch def An example: Our printer eats A4 sheets. The dimension of A4 is 842 times 595 points (297x210mm). When I send 'clippath pathbbox pstack' to the printer it responds with: 819.84 577.68 22.08 17.28 As you can see 842 = 819.84 + 22.08, and 595 = 577.68 + 17.28 (add a small delta if you like) -- Gisle Aas | snail: Boks 114 Blindern, N-0314 Oslo, Norway Norsk Regnesentral | X.400: G=Gisle;S=Aas;O=nr;P=uninett;C=no voice: +47-2-453561 | inet: Gisle.Aas@nr.no
CXT105@psuvm.psu.edu (Christopher Tate) (11/10/90)
In article <21532@well.sf.ca.us>, jef@well.sf.ca.us (Jef Poskanzer) asks: >In the referenced message, Gisle.Aas@nr.no wrote: >}To get the right pageheight/width you have to add together ury/x and >}lly/x. The clippath defines an area smaller than the physical page. > >You're saying I should add instead of subtracting? That doesn't >make sense to me. Could you be more specific? Provide corrected code >perhaps? The origin is located at the corner of the PHYSICAL page. The actual boundaries of the printable page are smaller than the physical page, so you have to compensate for that. When you pull the llx, lly, urx, and ury coordinates from the clippath bounding box, you get the boundaries of the PRINTABLE rectangle, not of the page rectangle. If you do the following: urx 0 translate The origin will now corrospond to the opposite (along the x axis) corner of the PRINTABLE rectangle, which is not what you want. To make the new origin the corner of the physical page, you also have to add the distance between the x-axis edges of the physical and printable page rectangles. Assuming that the printable rectangle is correctly centered, this distance is the same as the distance between the "default" origin and the edge of the paper, i.e. the llx value. So, if you do this: llx urx add 0 translate you'll wind up translating the origin all the way over to the other corner of the PHYSICAL page. Then, when you rotate into landscape orientation, the "lower left" corners of the page will be related in the same way as when you use the default portrait orientation. You'll just have more room in the x direction, and less in the y direction. (I hope this was clear.... :-) ------- Christopher Tate | | Of alle songes this is best: cxt105@psuvm.psu.edu | Verbum caro factum est! {...}!psuvax1!psuvm.bitnet!cxt105 | cxt105@psuvm.bitnet |
jef@well.sf.ca.us (Jef Poskanzer) (11/10/90)
In the referenced message, Gisle.Aas@nr.no wrote: }In article <21532@well.sf.ca.us> jef@well.sf.ca.us (Jef Poskanzer) writes: } In the referenced message, Gisle.Aas@nr.no wrote: } }To get the right pageheight/width you have to add together ury/x and } }lly/x. The clippath defines an area smaller than the physical page. } } You're saying I should add instead of subtracting? That doesn't } make sense to me. Could you be more specific? Provide corrected code } perhaps? } }As far as I can see the following code is correct, but it depends on }the clippath being centered on the physical page: ^^^^^^^^ Ok, I get it now. You're not really adding two coordinates, which would of course be silly. What you're actually doing is interpreting the llx and lly coordinates as distances -- the distance that the imaging area is offset inwards from all sides of the physical page. Then adding the margin distances to the urx and ury imaging coordinates gets you the urx and ury physical coordinates -- assuming, as you say, that the imaging region is centered. I'll change my code, and add a big comment crediting this disgusting hack to you... --- Jef Jef Poskanzer jef@well.sf.ca.us {ucbvax, apple, hplabs}!well!jef Safe when taken as directed.
lee@sq.sq.com (Liam R. E. Quin) (11/11/90)
woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) writes: > lee@sq.sq.com (Liam R. E. Quin) writes: >> woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) claims that >> > The generic way to do landscape is >> > 612 0 translate 90 rotate. >> >> This is not in the least generic! >> [since it wires in the size of the page] >is there a standard way to determine what the width of the page and the >height of the page is? I would assume that the current clip path >would do it. This was debated a lot on the UK PostScript list a few years ago... I seem to recall that the best answer involved initgraphics and clippath; I don't think you can do it portably in an EPS file, though. I suggested >> /PaperWidth 72 8.5 mul cvi def % width of a page in PostScript points >> PaperWidth 0 translate 90 rotate >> because, although, as Woody points out: >it *still* assumes 8.5 inch paper. granted, you can alter it manualy, it is now clear where the number comes from; Imagine that you have never _heard_ of this strange paper that is 8" by 11.5" (or whatever), and you come across the magic "612"... well, it isn't a multiple of the paper size, what could it be? The comment at least gives the person mantaining the code a _bit_ of a chance! Incidentally, the LaserWriter design is such that PostScript cannot distinguish between "no paper tray" and "US letter paper" when you do these operations, which means that if you're filling the paper tray at the wrong time, everything comes out shifted by half and inch or so! Lee -- Liam R. E. Quin, lee@sq.com, SoftQuad Inc., Toronto, +1 (416) 963-8337
wolfgang@wsrcc.com (Wolfgang S. Rupprecht) (11/13/90)
CXT105@psuvm.psu.edu (Christopher Tate) writes: >The origin is located at the corner of the PHYSICAL page. The actual >boundaries of the printable page are smaller than the physical page, >so you have to compensate for that. Is the origin supposed to be at the lower-left *exactly*? I have just undertaken a small treasure hunt into the inner working of printing latex via these two avenues: latex -> dvijep -> LaserJetII latex -> dvi2ps -> Adobe-PS-Cart -> LaserJetII There is a noticeable difference in page centering using these two methods. The problem boils down to the fact that dvi2ps assumes that the lower-left physical page is *exactly* (0,0), just as you have said. The printer seems to think that the lower left of the paper is (0.07 in, 0.07 in) in from the origin. This comes out to the edge of the paper being roughly at (5,5) on the initial postscript coordinate system. Is there a definitive standard on the exact location of the origin relative to the lower left of the physical page? If this is a bug, is there some way to fix it up the offset? Setmargins seems to have much too coarse a granularity to fix up a 5 pt. offset. Setmargins claims to have a 16 pixel (0.05 inch, or 3.8 pt.) granularity. So far, I have simply added a 5 pt. offset to each axis in dvi2ps, but this still leaves my margins off the page for normal postscript files. -wolfgang In case anyone else feels like wasting an otherwise perfectly good sheet of paper and measuring their PS printer's offset, here is my ruler hack. %! %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %% %% %% File: ruler.ps %% %% Author: Wolfgang S. Rupprecht <wolfgang@wsrcc.com> %% %% Created: Mon Nov 12 20:39:34 EST 1990 %% %% Contents: ruler (graph paper) generator for measuring %% %% virtual->physical coordinate system offsets %% %% and distortions %% %% %% %% Copyright (c) 1990 Wolfgang S. Rupprecht. %% %% All rights reserved. %% %% %% %% $Header$ %% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% /Times-Roman findfont 18 scalefont setfont 0 72 612 { newpath dup 0 moveto dup 792 lineto stroke dup 8 add 80 moveto 4 string cvs show } for 0 72 792 { newpath dup 0 exch moveto dup 612 exch lineto stroke dup 8 add 80 exch moveto 4 string cvs show } for showpage % end -- Wolfgang Rupprecht wolfgang@wsrcc.com (or) uunet!wsrcc!wolfgang Snail Mail Address: Box 6524, Alexandria, VA 22306-0524
shiva@well.sf.ca.us (Kenneth Porter) (11/17/90)
lee@sq.sq.com (Liam R. E. Quin) writes: > I don't think you can [determine what the width of the page and > the height of the page is] portably in an EPS file, though. Why would anyone want to know what the page size is in an *EPS* file!? The whole point of EPS is that it doesn't make assumptions about the importing environment. The importing application might want to map the EPS picture onto an arbitrary surface, perhaps not even resembling a page outline. I have written an ECAD application that generates an EPS file which assumes a default coordinate system of 0.001". The bounding box comment is also given in the same coordinate system. A typical image just fits the page at 1-to-1 scaling. If you just send one of these files to the printer, the image will be way to big to fit on the paper (about 1000/72 too big). I run the resulting file through a post-processor to scale the EPS by 72/1000 and center the resulting image on the page. Why would I do such a thing? Well, the EPS spec requires that the bounding box be given in integral points. By retaining the original coordinate system of the application, I get greater precision in the bounding box. Of course, any importing application must be able to handle an image considerably larger than a normal sheet of paper. One thing to look out for in importing applications is whether they provide enough bits for their scaling operations when importing an EPS file. Borland Sprint fails here, as it does all calculations in 16 bits, and its coordinate system is 1800 units/inch. I had to fudge Borland's EPS scaling macro to synthesize some extra precision so that images wouldn't run off into surrounding text (this involved implementing a multiple-precision multiply in Sprint's macro language). Try, for example, to import the AutoCAD Space Shuttle drawing: the tail fin pokes up into the text above the drawing because roundoff causes Sprint to assume the picture is smaller than it is. Ken (shiva@well.sf.ca.us)