I am the outer part of a transformed view of another pasteup. I know how to translate requests to pan, tilt and zoom into appropriate changes to the transformation

	drag and drop
	acceptDroppingMorph:event: wantsDroppedMorph:event:

	initialization
	createInteriorTransform initialize

	scripting
	cameraPoint cameraPoint: myTransformMorph offsetX offsetX: offsetY offsetY: scale scale:

	as yet unclassified	top
	changeOffsetBy: improve behavior at high magnification by rounding change to whole source pixels
	changeOffsetTo:
	changeScaleTo:
	changeTiltFactor:
	changeZoomFactor:
	extent:
	getTiltFactor
	getZoomFactor
	panImageBy:
	scaleImageBy:
	step Do some periodic activity. Use startStepping/stopStepping to start and stop getting sent this message. The time between steps is specified by this morph's answer to the stepTime message. The generic version dispatches control to the player, if any. The nasty circumlocation about owner's transformation is necessitated by the flexing problem that the player remains in the properties dictionary both of the flex and the real morph. In the current architecture, only the top renderer's pointer to the player should actually be honored for the purpose of firing.
	stepTime Answer the desired time between steps in milliseconds. This default implementation requests that the 'step' method be called once every second.
	tiltImageBy:

	drag and drop	top
	acceptDroppingMorph:event: The supplied morph, known to be acceptable to the receiver, is now to be assimilated; the precipitating event is supplied
	wantsDroppedMorph:event: we don't, really, but it avoids problem of outer pasteup rejecting a drop for inner pasteup

	initialization	top
	createInteriorTransform
	initialize

	scripting	top
	cameraPoint
	cameraPoint:
	myTransformMorph
	offsetX
	offsetX:
	offsetY
	offsetY:
	scale
	scale: