[Scribus] Image frame doesn't make any sense to me

Craig Ringer craig
Wed Sep 5 06:03:58 CEST 2007

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

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

More information about the scribus mailing list