Export snapshot question...

[Paul Dupuis]

On 11/8/2015 4:39 PM, Richard Gaskin wrote:
> Richmond wrote:
>
>> I wonder if, instead of doing /export snapshot from stack xxx/ you might
>> not be better doing /export snapshot from card zzz/: my experience
>> of doing the thing from the stack has not been altogether satisfactory .
>> . . Oops . . .  haven't tried that since DreamCard 2.6 (remember
>> that???): just tried /export snapshot from stack xxx/ and it "threw a
>> bluey", so I don't know what you are doing.
>>
>> However, /export snapshot from card zzz/ does a perfectly respectable
>> job.
>
> Exporting a rect grabs the specified portion of the screen buffer,
> which will also include anything an external blitted to the window but
> of course is limited to the screen bounds.
>
> Exporting an object will cause the object (and if it's a group or a
> card any interior objects) to be rendered into a new buffer, which
> will work regardless of where the source object is located (even off
> screen), but what an external may paint over the card isn't an object
> per se so LC's rendering engine has no way to create that when it
> generates into its buffer.

Unfortunately, this also is true.

export snapshot from rect tRect to image tImage as PNG
export snapshot from rect tRect of window tWindowID to image tImage as PNG
export snapshot from window tWindowID to image tImage as PNG

all are effectively the same. They capture the output of the External in
the window, including a certain amount of the window that may be "off
screen" below the bottom. But if any of the window is off the top of the
screen or after some small buffer below the bottom of my screen - every
thing outside of the screen buffer fails to be captured in the export.

export snapshot from this card of stack tStack to image tImage as PNG
export snapshot from rect tRect of this card of stack tStack to image
tImage as PNG

also both work the same in that NONE of the content rendered by the
External is captured.

>
> If the external could be modified to use an image object as its output
> you'd have all sorts of flexibility for handling it.
>
Very true, and so this is now the plan to add image support to the external.
FYI Richard, this is the long-in-the-works PDF external, which is
finally turning out to be pretty slick. Recently migrated from Foxit's
overpriced PDF SDK to Google's open source PDFium, eliminating Foxit
licensing costs and royalty fees.