Graham,
Why on earth does RR do this? It drives my students crazy. Why do you have to lock the size of an image to keep it the size you set it? Is this a feature or a bug?
Whenever you change an image (via fileName or import), the issue for RunRev is what to do about the image object's size (notice I said "image object" not "image"). Should it stay the height and width that it is currently on screen? Or should it be resized to the formatted height and width of the new image that it's going to display? lockLoc is the hint that tells RR what to do.
Personally I never use lockLoc, always resizing the images I need on the fly, and in your case it sounds like you need more control, and so you might not want to set lockLoc. But imagine a stack of many cards, each with dozens of thumbnails, all pointing to different images on disk. Without lockLoc, a programmer would have to resize each image on every openCard rather than having them stay the size they were set at.
It drives me crazy too because it's not clear how you turn off the 'revert
to original' feature permanently, for example if you want to repurpose the
image entirely and completely lose the original size.
There are two types of image, ones you set via the fileName property, and ones you set via the import command. They are similar, but subtly different. For example, you can't use the clipping command on fileName images.
But one way they're the same is that both types of images retain their original or "formatted" height and width when you resize them. When you set an image object's height and width, you're not resizing the original image (the one on disk), you're resizing the "RunRev image object" which happens to have a copy of your image's data in it.
If you want that new image height and width to be permanent, you will need to rewrite the image data to disk, and the way to do that is via the export command.
I mean, if I'd
altered the shape of an image in a graphics package, I wouldn't expect the
'original size' to haunt me forever, would I?
Of course you would. In Photoshop, until you hit Save, and save over the original file, you have access to the original image through undo, or the Revert to Saved menu item. Right? You'd be very very upset if Photoshop threw away your original data just because you resized the image.
I don't see an original size
as a 'natural' size; it's just what I started with, neither more nor less.
As I see it, a resized image is a new image, and the idea that the system
has a mysterious way of retaining its history is eccentric to say the
least.
The original pixels are in the image object, and you can scale it up or down at any time. Would you really want RunRev to throw away the original image data because you scaled the image down to 100,100? What if you wanted to scale it up to 250,250, and then back down again, or wanted to animate it? Do you want to have to reload the image from disk for each size change?
What if I duplicated it seven times and make each of the dupes a
different size, and then made each of the dupes part of a shape-changing
animation, moving between the new size of the dupe and some other size
dictated by the animation (this is an extension of a real case)? The way
things are now, I'd have to use an external package to do all these
transformations.
Each image object will have its own copy of the pixels and each image object can be resized to a different size without impacting the other objects.
I'd like it so if I wanted the history, I could save it myself - otherwise
transformations should stay transformed.
They do stay transformed, until one of two things happens. One, if you change the image object via the fileName or import commands, or two, if you leave the card and return. When you return to a card, RR uses the lockLoc property as a hint about how to size the image object as it redraws the screen ("hmmm, do I use the image size, or do I use the image object size?").
BTW I am not convinced that the
lockLoc feature works completely in all situations - at least I've had some
problems with editing groups (by script) which contain resized images. I
admit that these were too obscure to chase down into proper Bugzilla reports.
Sorry, I can't help you with that as I don't use the feature for images.
-- Frank
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
