dax702 wrote: > As far as I (a beginner who just needs to get work done) can tell, image > frame is utterly useless in Scribus. The image frame should adjust to the > exact dimensions of the image you're placing.
The trouble is how to determine "exact dimensions". Bitmap images have pixel dimensions, eg 2000x1500 pixels. That's their only fundamental measurement. Many formats also contain hints to the application about the creator's desired physical display size or, equivalently, the expected physical DPI of the image. However, these hints are often ignored, incorrectly set, or simply misunderstood by users. Since Scribus, like any DTP app, works in real-world physical units like cm, there's no one correct way to use a bitmap. It all depends on the resolution the job will be output at - something that the user (by design) can vary at export time. Scaling a bitmap DOWN is generally a good quality process, it's only scaling up that can be ugly. If you have an image with small pixel dimensions and a high-res output target, that means you must place the image in a small frame. I do think it'd be good to be able to resize an image and its frame together to the bitmap's optimal physical size at a given output resolution. There are, however, good reasons why things are done like they are, and image frames are both important and useful for DTP work. The other utility of image frames is that they permit you to quickly and easily crop off bits of the image you don't want without having to go and make a new version of the original resource. With the contour editor the crop doesn't even have to be rectangular. Their entire purpose is to let you quickly crop & scale images, because that is useful and important in DTP. It sounds like you've come from working in a bitmap editor, where your concerns would be valid. When targeting output that works in real-world physical sizes like PDF, though, it makes much less sense. -- Craig Ringer
