DRM for Images and Text in Stacks

Sivakatirswami katir at hindu.org
Fri Mar 17 06:16:09 EST 2006

FYI, setting a customProp with the compressed image data actually  
increases the size of the stack if those images were resized to  
larger than their original incoming size (that's expected behavior)  
This presents somewhat of a conundrum. Since the import of a 3 X 5  
jpeg whose original resolution was 72 DPI  (all that is needed for  
the screen) and if is scaled up, storing it as image data (even  
compressed) bloats the stack. Since the "quest" is internet delivery,  
one is looking for the opposite effect: smaller stack sizes. So, one  
gets caught between a rock and a hard place: you want to deliver  
media efficiently but protect them from "theft" but then to protect  
them from theft you have to make a stack that is so big that delivery  
is difficult. hmmm...

I would still opt for a new feature to protect stacks in the IDE.  
Then you simply store images in a substack which are obviously  
unavailable if driven from a standalone player. Another developer  
then tries to open your substack in the IDE and he can't, without a  
password. You shouldn't need push the image data around thru hoops to  
get your DRM.

Without this, we are "stuck with PDF's" as a container for delivery  
of content where DRM is mission critical. We're not talking little  
gif graphics here but high end photos with strict copyright-usage  

Musings: PDF's are very efficient and one can set security on the  
images to block another Acrobat Professional user from accessing the  
"extract images" menu item (it will be dimmed), but this "act of  
protection" does not impact the size of the container...(the PDF  
still has the images stored in "lo-quality" jpg form). So I'm looking  
to see how that model can be implemented in Rev, but efficiently in  
terms of the final stack file size. The name of the game is getting  
from the vertical rect of the old print world to the horizontal rect  
of the digital revolution. It's actually a very hard nut to crack.

  We recently exported some Key notes with embedded media to Power  
Point: file sizes were so large that internet delivery was  
unthinkable. one would have to put them on DVD disk and sell them to  
cover costs. We are just interested in deploying content, not making  
money on most of this content, and would rather avoid the whole burn  
it, package it, warehouse it, catalog it, sell it, cycle.  We're  
looking into recording the screen thru a whole presentation and  
turning these into movies, but for a full 600X800 rect the  
resulting.mov file will also be enormous, even as an MPEG or h.264...  
It means burning disks again, and packaged-postal delivery. No matter  
how well you do this, that paradigm dramatically decreases  
distribution compared to a web download.

  I'm sitting there knowing full well that the same content deployed  
as a revolution stack could be packaged in 1/20 the space...or  
incrementally delivered in a few separate stacks...and the media  
wants to in the stack (at least photos)  and come very, very close to  
the equivalent files sizes for the same content packaged as PDF's.  
(if not smaller)  Besides-- the compress and decompress thing was  
very sluggish... So secure PDF's of printed pages with vertical  
orientation still rules... and users must scroll and zoom and scroll  
and zoom and scroll and zoom.....there is a lot of resistance to this  
among a certain strata of users... InDesign has some great export to  
XML options and with a little standardization on templates in Rev, it  
would not be hard parse a print magazine article-page file and get it  
all repackaged into a horizontal rect. But it comes back to DRM- 
security on the images or substack. Without that, the exercise is  

OK , 'nuf said... I'm copying this to support at Rev as a feature  
request. Oh... and text wrap around photos would also be dynamite!

Himalayan Academy Publications
at Kauai's Hindu Monastery
katir at hindu.org


On Mar 07, 2006, at 9:05 AM, Sivakatirswami wrote:

>> Here's a simple example using compress/decompress:
>> set the uStuff of this card to compress(the imageData of img 1)
>> put "" into img 1
>> set the imageData of img 1 to decompress(the uStuff of this card)

More information about the Use-livecode mailing list