knut-skog%rglab.uit.uninett@NORUNIX.BITNET (Knut Skog) (05/07/89)
[[ Moderator's note: I edited this message before distributing it, to
repair the damage that happened in transit from Norway. The BITNET
mailers along the line are cleverly translating open brackets to
escapes, and close brackets to vertical bars. -Don ]]
Lately I have been troubled with some unexpected NeWS behaviour.
Whether this is due to my own foolishness, bugs in NeWS or features
of the system is difficult for me to say. Hence, I turn again to the
NeWS-brother/sister-hood for clarification.
1. I made an attempt to redefine some PostScript-operators in
a class definition. The methodecompiler (optimizer?) became
very unhappy as can be seen from its reaction on the following
piece of code:
/Testclass Object []
classbegin
/oldadd /add load def
classend def
/Inst /new Testclass send def
Reaction:
Process: 0x162C18 Error: typecheck
Stack: /oldadd marker 'add' array{19}
Executing: 'forall'
At: {dictionary[32] 'begin' /superpending 'false' 'def'
/selfpending 'false' 'def' /ParentDict 'exch' 'def' 'mark'
'exch' array{19} *'forall' ] 'cvx' 'end'}
In: {ParentDict *methodcompile 'def'}
.... etc. etc. .....
Could'nt the methodecompiler detect the basic operator and gracefully
stop its search for /self sending, or is the problem more intricate?
2. The kind of paths that NeWS' pathforall operator can handle
seems restricted. The clippath and clipcanvaspath is not
accepted as argument to pathforall. Storing a path
(/Path currentpath def) and setting it from this variable
(Path setpath) makes again a current path that is unacceptable to
pathforall. The NeWS-reaction given is invalidaccess.
The PostScript interpretor of my Laserwriter accepts the
current path provided by clippath - to pathforall.
Is this a bug or a feature of NeWS?
3. The impact on CTM caused by setcanvas is weird. Take a look
at the output made by the following sequence of statements.
framebuffer setcanvas
/Canv1 framebuffer newcanvas def
Canv1 /Mapped true put
gsave
200 200 translate 2 1 scale
matrix currentmatrix {==} forall % giving: 2 0 0 1 200 200
0 0 50 0 360 arc Canv1 reshapecanvas
grestore
Canv1 setcanvas 0 fillcanvas
matrix currentmatrix {==} forall % giving: 2 0 0 1 100 51
/Canv2 Canv1 newcanvas def
Canv2 /Mapped true put
-20 0 moveto 0 20 lineto 20 0 lineto 0 -20 lineto closepath
Canv2 reshapecanvas
Canv2 setcanvas 1 fillcanvas
matrix currentmatrix {==} forall % giving: 2 0 0 1 40 21
0 0 45 0 360 arc
Canv2 reshapecanvas
Canv2 setcanvas 1 fillcanvas
matrix currentmatrix {==} forall % giving: 2 0 0 1 90 46
Why the CTM initiated by the setcanvas operation is effected by
the shape of the canvas, I do not understand ?
I can not see any documentation or explanation of this
effect which to me is truly surprising. The manual states:
for the reshapecanvas operator;
", and it sets the canvas' default transformation matrix from
the current transformation matrix."
and for the setcanvas operator;
" Implicitly executes initmatrix"
which according to the red book;
" sets CTM to the default matrix of the current output device."
Krg,
Knut