dax702 wrote: > I suppose then it depends how you work. To me, it seems like bad practice to > just take any ol (bitmap) image and drop it into DTP only to then mess with > its dimensions. I've worked with images on the web, and in video and I > *always* create the image to the specs I need and then import it into > wherever it needs to go. I am approaching DTP in the same manner because it > makes logical sense.
I'm not convinced it does, personally - you've been doing it that way before because you've been working with largely pixel-oriented media. In DTP most output media are mixed bitmap/vector formats that target real physical output or closely simulate it, so the concerns are somewhat different. That's not to say that adapting each resource before using it is bad - it's not. It's just that DTP apps are designed specifically so that you don't have to do that. There are some areas where DTP apps do things a certain way because they always have and people are used to it. There aren't many, and this isn't one of them. Once you seriously use these apps for the purposes they're designed for (creating layouts for physical media) you will probably start to notice how all the oddities like the frame-based design start making sense. > I wasn't entirely clear. I don't have a problem with the image frame > feature itself, or making decorative frames, rotating, duplicating, moving, > etc. the image frame. I simply believe that for the people who take the > time to create their bitmap images exactly as they want them, then Scribus > should allow those people to be able to simple create an image frame, insert > the image and have the frame automatically resize itself to the ACTUAL > dimensions of the image, whether it be, pixels, inches, whatever. and then > and only then we should have the option to screw around with resizing.. Because DTP users work with images that have *huge* pixel dimensions, it would usually be counterproductive to do that. You're asking for the app to be optimised for an unusual workflow that makes the user do more work than they need to. In the vast majority of cases, when designing a layout your design dictates the size and position of the image rather than the image data dictating its size and position in your design. As such, it makes more sense to create a place for the image (the frame) then fit the image to it. The only time I worry about the image data is if I have a client-supplied image that's so low res that there's a very definite limit on the physical size at which I can print it. If you _do_ want to use the image according to the resolution & physical dimensions hints in the image file, you can do this by right clicking on the frame and choosing "Adjust frame to Image". The properties palette permits you to have the image fit to the frame instead (IMO this should be in the context menu). Honestly, this is largely a culture clash issue. In most cases you do *not* need to edit your resources in a bitmap editor before using them in Scribus, and you will work more quickly and flexibly if you get out of the habit. You're working with different media, and that does impose some real changes to how you need to work, much like print designers need to get over their obsession with tiny type in obscure fonts when designing for the web. The exception with Scribus is that its' handling of very large images is still pretty terrible, so unless you have a massive amount of RAM there are some definite upper limits on image sizes above which you do need to pull out your bitmap editor. Hopefully these issues will be addressed in time - I know it's already much improved in 1.3.5, but still has to store at least one decompressed copy of the entire bitmap in RAM. The frame-based DTP workflow isn't some abitrary choice or historical accident. It's that way because it helps designers work faster and more easily. It takes a bit of thought to get used to if you're used to thinking of images as having a physical size (which they provide as a hint only, they're really just a 2D map of coloured points of undefined size and shape that the app can use as best fits the medium) but you'll benefit from getting used to the approach. -- Craig Ringer
