bammi@dsrgsun.ces.CWRU.edu (Jwahar R. Bammi) (08/16/88)
Can someone shed some light on the following:
- The `red' book defines FontBBox as an array type (of 4 elements).
- On the Apple LaserWriter and the Apple LaserWriter-II/NTX
FontBBox pushes four values on the stack (not in an array).
- Under NeWS V1.1 FontBBox pushes an array of 4 elements on the
stack.
Which of the above is the correct behavior of FontBBox??
If it matters we tested the behavior of FontBBox using the
following program (in interactive mode):
/Times-Roman findfont 10 scalefont % font dict on top of stack
/FontBBox get ==
--
usenet: {decvax,sun}!mandrill!bammi jwahar r. bammi
csnet: bammi@dsrgsun.ces.CWRU.edu
arpa: bammi@dsrgsun.ces.CWRU.edu
compuServe: 71515,155rainero@rocksanne.UUCP (Emil Rainero) (08/16/88)
In article <21@cwjcc.CWRU.Edu> bammi@dsrgsun.ces.CWRU.edu (Jwahar R. Bammi) writes: >Can someone shed some light on the following: > > - The `red' book defines FontBBox as an array type (of 4 elements). > > - On the Apple LaserWriter and the Apple LaserWriter-II/NTX > FontBBox pushes four values on the stack (not in an array). FontBBox is defined as an executable array on our LaserWriter+ (38.0). > - Under NeWS V1.1 FontBBox pushes an array of 4 elements on the > stack. The reference manual does not specify. >Which of the above is the correct behavior of FontBBox?? Both. Thats the advantage of a loose specification. By the way, has anyone else noticed that the only mention of how to set the an outlined font's stroke width is in Program 16 of the Tutorial and Cookbook. Is the StrokeWidth field in the font dictionary documented in the reference manaul? On an even touchier note, does anyone in netland have an extensive list of PostScript bugs? This is for whatever printer/version you have, whether the bug is a show stopper or just a compatibility problem between your printer and the reference manual. Heres a small teaser. Program 5 in the Tutorial and Cookbook does an "idiv" with a real first argument which is a typecheck error according to the Reference Manual but works just fine on a LaserWriter+ version 38.0. The actual computation is 276.0 60 idiv This is the type of nonportable problem I would like to see documented. -- Emil Rainero -- Xerox Webster Research Center UUCP: {seismo,allegra,decvax,cmcl2,topaz}!rochester!rocksanne!rainero Arpa Internet: Rainero.wbst@xerox.arpa
geof@imagen.UUCP (Geoffrey Cooper) (08/17/88)
In article <21@cwjcc.CWRU.Edu>, bammi@dsrgsun.ces.CWRU.edu (Jwahar R. Bammi) writes: > Can someone shed some light on the following: > > - The `red' book defines FontBBox as an array type (of 4 elements). > > - On the Apple LaserWriter and the Apple LaserWriter-II/NTX > FontBBox pushes four values on the stack (not in an array). Actually, it IS an array, but by convention of the built-in fonts (not mentioned in the RedBook... (did I mention that already?)) an EXECUTABLE array. So if you do something like: /Times-Roman findfont begin FontBBox the interpreter will EXECUTE the array. Executing an array containing 4 numbers is equivalent to pushing them on the stack. So all the implementations are right. Some PS code uses this feature to be more concise (probably not significantly more efficient). To get the array itself, try: /Times-Roman findfont /FontBBox get - Geof -- UUCP: {decwrl,sun}!imagen!geof ARPA: imagen!geof@decwrl.dec.com
geof@imagen.UUCP (Geoffrey Cooper) (08/18/88)
In article <598@rocksanne.UUCP>, rainero@rocksanne.UUCP (Emil Rainero) writes: > Is the StrokeWidth field in the font dictionary documented in the reference > manaul? See redbook, page 92. > 276.0 60 idiv My testing indicates that idiv applied to real numbers that cvi to integer with no change in value works as if the CVI had already been done. Try taking /foo length or even 0 length % PS-38 Of course, these are pretty minor things we're talking about. - Geof -- UUCP: {decwrl,sun}!imagen!geof ARPA: imagen!geof@decwrl.dec.com
geof@imagen.UUCP (Geoffrey Cooper) (08/18/88)
Run this and be confused as to why the two objects printed
don't look the same:
/Times-Roman findfont 18 scalefont setfont
0 setlinewidth
72 720 moveto (T) true charpath 40 40 rlineto stroke
72 620 moveto (T) true charpath currentpoint moveto 40 40 rlineto stroke
showpage
(printed on LW+ with PS42.2)
- Geof--
UUCP: {decwrl,sun}!imagen!geof ARPA: imagen!geof@decwrl.dec.comthomas@bnlux0.bnl.gov (Richard A. Thomas) (08/19/88)
Well, it is ``documented'' (sort of). On page 212 of the Green Book
(PostScript Language Program Design), there is a discussion of Debugging
Techniques and the TYPECHECK error:
Here are some common causes of the typecheck error:
...
There is a difference between an integer and a real number. Make
sure you supply each operator with the correct type. This is especially
important with the idiv operator, since early versions of the PostScript
interpreter graciously permitted real operands as arguments when they
should not have.
End of quote.
Richard Thomas
Brookhaven National Labcurtj@pogo.GPID.TEK.COM (Curt ) (08/19/88)
In article <21@cwjcc.CWRU.Edu> bammi@dsrgsun.ces.CWRU.edu (Jwahar R. Bammi) writes: >- The `red' book defines FontBBox as an array type (of 4 elements). >- On the Apple LaserWriter and the Apple LaserWriter-II/NTX > FontBBox pushes four values on the stack (not in an array). Only if you execute the array. >- Under NeWS V1.1 FontBBox pushes an array of 4 elements on the stack. >/Times-Roman findfont 10 scalefont /FontBBox get == % OMNI laser % LaserWriter You must have a differant LaserWriter than I do. /Times-Roman findfont 10 scalefont /FontBBox get == flush produces { -170 -223 1024 896 } on the operand stack. This is an executable array. (a procedure if you will) It still is an array, but if you execute it, it will replace the array with the 4 numbers. ---------------------------------------------------------------------- Curt Jutzi (Jutz) ... tektronix!pogo!curtj Tektronix Inc. ... pogo!curtj@tektronix Del. St. 63-356 (503) 685-3723 P.O. Box 1000 "LIFE IS AN ADVENTURE,, GIVE IT A GO." Wilsonville,OR 97070