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
issues.
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
pointless.
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!
Sivakatirswami
Himalayan Academy Publications
at Kauai's Hindu Monastery
[EMAIL PROTECTED]
www.HimalayanAcademy.com,
www.HinduismToday.com
www.Gurudeva.org
www.Hindu.org
On Mar 07, 2006, at 9:05 AM, Sivakatirswami wrote:
Here's a simple example using compress/decompress:
SETUP:
set the uStuff of this card to compress(the imageData of img 1)
put "" into img 1
PLAYBACK:
set the imageData of img 1 to decompress(the uStuff of this card)
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
