damianzalewski wrote:

What gimp is not:

"not a web page mock-up application I brought up web mock-ups, but we realised that seriously supporting this would mean introducing a ton of functionality; it is better done in a specialised application"

I really don't understand what tons of functionality you mean.

Well, let's see:

First we would have to support the task of figuring out the right page structure and proportions by the designer. This would mean multicolumn layout, aligning sections vertically. This all of course in modern fluid (resizing) web layouts. This is all vector oriented work, because it is about structure.

Next: although the structure of html text mark-up and the typographical capabilities of css do not need to go 100% into the GIMP text system, a complete _understanding_ of the structure of html text mark-up and the typographical capabilities of css does needs to go into GIMP.

Can those links highlight on mouse-over? yeah sure, we should include that.

Can we then click those links to go in the mock-up from page to page? yeah sure, we should include that.

When that all works, can GIMP export a click-dummy in html, css and images? yeah sure, we should include that.

And I am sure there is more...

That is serious work to implement. And all the interaction elegance of sewing a third leg on the GIMP.

The most bothering shortcoming for webdesign workflow is slice tool and save for web (integrated into one app).

Those both will be in GIMP, in the future.

Maybe your research methods are wrong.

Webdesigners DO NOT design elements of page separately. Webdesigners DO NOT slice page and then open sliced files to save them for web. It would be great waste of time.

We do imagine that a set of website graphics pieces gets _produced_ on a single canvas, and when everything works well together graphically, with a single 'cutting mask' all pieces are cut out and saved in the right web format, in a single action.

As a matter of fact approach 'not a web page mock-up application' means that gimp is useless for any modern form of webdesign.

Designing the structure of web pages and building mock-ups is the work for an interaction designer, and there are other apps to do that in.

The production of high quality image pieces for the final web site is the work of a graphics artists, and GIMP is the application for that.

--ps

principal user interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

peter sikking wrote:

We do imagine that a set of website graphics pieces gets _produced_ on a single canvas, and when everything works well together graphically, with a single 'cutting mask' all pieces are cut out and saved in the right web format, in a single action.

I don't see how this can work in practice.

I often need to hide or isolate layers before exporting the selection they affect and many selections are a very small part of an element's area (say 1 pixel wide) because they will be tiled by the browser as part of a background image. In other words, some manual work needs to be done with the majority of web graphics taken from a concept. Comparatively few images are cut out as they are.

--- Scanned by M+ Guardian Messaging Firewall ---

David,

peter sikking wrote:

We do imagine that a set of website graphics pieces gets _produced_ on a single canvas, and when everything works well together graphically, with a single 'cutting mask' all pieces are cut out and saved in the right web format, in a single action.

I don't see how this can work in practice.

I often need to hide or isolate layers before exporting the selection they
affect

we were thinking the same, so a cutting mask is not part of a layer...

and many selections are a very small part of an element's area (say 1 pixel wide) because they will be tiled by the browser as part of a background
image.

that is what we expect, too...

In other words, some manual work needs to be done with the majority of web graphics taken from a concept.

can you tell me what you mean with "manual work needs to be done"? that can help us with our work.

Comparatively few images are cut out as they are.

I can clarify that in general we do not expect that some mock-up is taken, and then the bits are cut out, and finished.

in general we expect that graphics artists set up the canvas and layers in any way that works for them: sometimes a creating continuous area and cutting out pieces from there, sometimes laying out pieces just as a set adjacent to each other. Set up variations of sets of graphics by duplicating layers, or by switching layers on and off, or by switching GEGL operations on or off? do whatever you want, we can handle it. use any combination of hand-made selections and one or more cutting masks (these contain any number of selections), be our guest.

we feel that with this flexibility we cam truly support web graphics work in a flexible way.

thanks for your feedback,

--ps

principal user interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

Sorry fo my intrusion here guys

But the correct behavior ( exporting layout for web ) can be seen on Macromedia / Adobe Fireworks. Let say Firefox 8 ( I dont try yet CS version ).

They had a proven model that already got the general acceptance. If some similar model ( to cut in slices - to rename every slice in your way - to choose export format individual for each slice [ this can be a killer feature ] - to hide or show some layers / objects / slices depending on your needs ) - well that will be a major / expected move.

peter sikking wrote:

David,

peter sikking wrote:

We do imagine that a set of website graphics pieces gets _produced_ on a single canvas, and when everything works well together graphically, with a single 'cutting mask' all pieces are cut out and saved in the right web format, in a single action.

I don't see how this can work in practice.

I often need to hide or isolate layers before exporting the selection they
affect

we were thinking the same, so a cutting mask is not part of a layer...

and many selections are a very small part of an element's area (say 1 pixel wide) because they will be tiled by the browser as part of a background
image.

that is what we expect, too...

In other words, some manual work needs to be done with the majority of web graphics taken from a concept.

can you tell me what you mean with "manual work needs to be done"? that can help us with our work.

Comparatively few images are cut out as they are.

I can clarify that in general we do not expect that some mock-up is taken, and then the bits are cut out, and finished.

in general we expect that graphics artists set up the canvas and layers in any way that works for them: sometimes a creating continuous area and cutting out pieces from there, sometimes laying out pieces just as a set adjacent to each other. Set up variations of sets of graphics by duplicating layers, or by switching layers on and off, or by switching GEGL operations on or off? do whatever you want, we can handle it. use any combination of hand-made selections and one or more cutting masks (these contain any number of selections), be our guest.

we feel that with this flexibility we cam truly support web graphics work in a flexible way.

thanks for your feedback,

--ps

principal user interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

On 6/22/07, Nemes Ioan Sorin wrote:

But the correct behavior ( exporting layout for web ) can be seen on Macromedia / Adobe Fireworks. Let say Firefox 8 ( I dont try yet CS version ).

They had a proven model that already got the general acceptance. If some similar model ( to cut in slices - to rename every slice in your way - to choose export format individual for each slice [ this can be a killer feature ] - to hide or show some layers / objects / slices depending on your needs ) - well that will be a major / expected move.

Personally I think the slicing a grid approaches encourages a habit in web-design that should be strongly discouraged. The habit to use pixels as measurement unit for interfaces / designs, never displays _will_ have higher resolution, and designs created need to accommodate wider ranges of resolutions.

It should be possible to create elements for such designs with tools provided; but this is a very narrow use case; that I personally would hope wouldn't be a focal point for how to use GIMP when creating designs for the web.

/Øyvind K.

On Sun, 24 Jun 2007 15:08:47 +0200, Øyvind Kolås wrote:

On 6/22/07, Nemes Ioan Sorin wrote:

But the correct behavior ( exporting layout for web ) can be seen on Macromedia / Adobe Fireworks. Let say Firefox 8 ( I dont try yet CS version ).

They had a proven model that already got the general acceptance. If some similar model ( to cut in slices - to rename every slice in your way - to choose export format individual for each slice [ this can be a killer feature ] - to hide or show some layers / objects / slices depending on your needs ) - well that will be a major / expected move.

Personally I think the slicing a grid approaches encourages a habit in web-design that should be strongly discouraged. The habit to use pixels as measurement unit for interfaces / designs, never displays _will_ have higher resolution, and designs created need to accommodate wider ranges of resolutions.

It should be possible to create elements for such designs with tools provided; but this is a very narrow use case; that I personally would hope wouldn't be a focal point for how to use GIMP when creating designs for the web.

/Øyvind K.

I dont think a msg that starts "the correct behavior" will carry much weight, especially when it continues "as can be seen on Macromedia".

They had a proven model that already got the general acceptance.

Outlook Express and FrontPage have general acceptance as well , hardly a sound basis for recommendation or adopting something as a design model.

I would expect that someome who decides to use an image processor for complex page layout is likely to be aiming a notch higher than your average WYSIWYG FrontPage Express or Dreamweaver user.

I agree that the tools should aimed towards "top end" users not splicing. Gimp's declared aim is to provide tools for creating elements for web design not page layout.

Thanks Øyvind.

peter sikking wrote:

can you tell me what you mean with "manual work needs to be done"? that can help us with our work.

Well the most common case is simply selecting a slither of an area to be tiled as a background image. Sometimes you have to hide a foreground layer before making the selection such as filler text or an image. You will also want to pick a colour with the pipette tool that will be used as the background colour of the element. Most of the background images I deal with are gradients, so the colour I want to use is either the darkest or lightest colour of that gradient.

Otherwise you often need to select the right combination of layers. I've already mentioned foreground layers that might need to be hidden. Other times they might need to be isolated. In Photoshop the issue is further complicated by the use of adjustment layers. Transparent gifs or pngs will need to be isolated altogether.

Sometimes a background image will be larger than the dimensions of the containing element so the final thing you'd want to do is toggle a layer mask to get the whole image.

This is the routine I tend to follow when using PS 9:

1) Toggle visibility of layers and masks until I can make a selection of the area I need to save.

2) Select area with marquee tool. Can be very annoying when zoomed in because selection always overshoots when I scroll. PS does not share Gimp's sensitivity when zoomed in.

3) Copy visible. Gimp should probably have a short cut key bound to this operation as it is always required.

4) Open new canvas. PS automatically populates the canvas dimensions with those of the paste buffer so this operation isn't as cumbersome as it would be in Gimp, but really it wouldn't be required at all if PS allowed you to edit an image during the next stage. The only editing I ever need to do here is convert background to transparency.

5) Save for web. Compare compressed images against original. Adjust for best compromise of size and quality then save.

With a "save *selection* for web" feature, steps 3) and 4) could probably be omitted altogether for most of the time. Step 5) is often made cumbersome by the fact that the default save destination is the last directory used by the application. Life would be easier if a web images directory could be set in preferences (maybe it can and I don't know about it!).

It's getting late so I'll leave it there. I think I may follow this email up with a more fundamental description of what a designer is trying to achieve when marking up a concept, if you think it would be useful. Let me know if there are other things you want to know. I'd be interested to follow your progress as you design this feature.

Regards,

Davidm

--- Scanned by M+ Guardian Messaging Firewall ---

On Mon, 25 Jun 2007 12:02:48 +0200, damianzalewski wrote:

gcn> I agree that the tools should aimed towards "top end" users not splicing.
gcn> Gimp's declared aim is to provide tools for creating elements for web
gcn> design not page layout.

Does it really mean I have to use separate program to make few cuts.

no. Select , cut, paste as new.

And how can I make web page without slicing ?

I have no idea what you are trying to "slice" or what effect you are trying to achieve but assuming you are trying to design a layout that is capable of adapting to different screen sizes (which you certainly ought to be doing) you will need to be a bit more engenious than just making a 600x800 and chopping it into a few chuncks.

This is not the place for a tutorial but you should be able to create the necessary graphic elements by selecting a rectangle , possibly defining a transparency colour and saving in a suitable format. All that is readily available in gimp.

The selection tools are now very easy to use precisely and well adapted for this task.

/gg

On Mon, 25 Jun 2007 00:52:53 +0200, David Marrs wrote:

With a "save *selection* for web" feature, steps 3) and 4) could probably be
omitted altogether for most of the time.

well save for web is a plugin but it probably could be extended to save a selection. Sounds like a time saver.

Step 5) is often made

cumbersome by the
fact that the default save destination is the last directory used by the application. Life would be easier if a web images directory could be set in
preferences (maybe it can and I don't know about it!).

Yes I find this annoying as well. I always end up having to set the destination each time I save something. That may be gtk filechooser (one of my pet hates on linux) rather than gimp directly. Even if I open a file and want to save_as straight away it seem to want to put is somewhere else. The time it takes to log a directory exaserbate this problem as well.

It's getting late so I'll leave it there. I think I may follow this email up
with a more fundamental description of what a designer is trying to achieve when
marking up a concept, if you think it would be useful. Let me know if there are
other things you want to know. I'd be interested to follow your progress as you
design this feature.
Regards,
Davidm

Some studies were done last year on usage but since the UI is undergoing a major design effort now it's probably a good time to point out anything that holds you back in your work flow.

thx.

David wrote:

peter sikking wrote:

can you tell me what you mean with "manual work needs to be done"? that can help us with our work.

Well the most common case is simply selecting a slither of an area to be tiled as a background image.

yep, we expect this kind of stuff to be your daily routine.

actually right now I am specifying how the selection tools should deal with long, very narrow selections, with the web guys in mind.

Sometimes you have to hide a foreground layer before making the selection such as filler text or an image. You will also want to pick a colour with the pipette tool that will be used as the background colour of the element. Most of the background images I deal with are gradients, so the colour I want to use is either the darkest or lightest colour of that gradient.

Otherwise you often need to select the right combination of layers. I've already mentioned foreground layers that might need to be hidden. Other times they might need to be isolated. In Photoshop the issue is further complicated by the use of adjustment layers. Transparent gifs or pngs will need to be isolated altogether.

Sometimes a background image will be larger than the dimensions of the containing element so the final thing you'd want to do is toggle a layer mask to get the whole image.

lot's of layer action to get the right combinations _visible_, that is what we also thought would prelude the cutting of web images.

This is the routine I tend to follow when using PS 9:

1) Toggle visibility of layers and masks until I can make a selection of the
area I need to save.

2) Select area with marquee tool. Can be very annoying when zoomed in because selection always overshoots when I scroll. PS does not share Gimp's sensitivity when zoomed in.

3) Copy visible. Gimp should probably have a short cut key bound to this
operation as it is always required.

there we go: visible. what you see is what you export. we are thinking in the same direction.

4) Open new canvas. PS automatically populates the canvas dimensions with those of the paste buffer so this operation isn't as cumbersome as it would be in Gimp, but really it wouldn't be required at all if PS allowed you to edit an image during the next stage. The only editing I ever need to do here is convert background to transparency.

sounds to me that this whole new canvas is superfluous. the transparency thing is noted.

5) Save for web. Compare compressed images against original. Adjust for best
compromise of size and quality then save.

interesting to see "Compare compressed images against original", would it be enough to see the compressed one and balance that against the size and what your customer expects?

With a "save *selection* for web" feature, steps 3) and 4) could probably be
omitted altogether for most of the time. Step 5) is often made cumbersome by the
fact that the default save destination is the last directory used by the
application. Life would be easier if a web images directory could be set in
preferences (maybe it can and I don't know about it!).

yeah, we are seeing that for these individual saves, but also for saving 20 images from a cutting mask in "one click", working with fixed and also
variable destination directories is part of the game. we need to support you guys there.

It's getting late so I'll leave it there. I think I may follow this email up
with a more fundamental description of what a designer is trying to achieve when marking up a concept, if you think it would be useful. Let me know if there are other things you want to know. I'd be interested to follow your progress as you design this feature.

now it is getting late here too. if you can make that description really fundamental (like in principle for tens of thousands of web graphic designers), and filter your own biases out, then that would be great input for us.

but you better be sure it is fundamental >^}

thanks,

--ps

principal user interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

David Marrs writes:

4) Open new canvas. PS automatically populates the canvas dimensions with those of the paste buffer so this operation isn't as cumbersome as it would be in Gimp, but really it wouldn't be required at all if PS allowed you to edit an image during the next stage.

I might have misunderstood this step (I definitely don't follow the comment about PS not letting you edit -- maybe that's a PS issue) but it sounds like if you did a "Paste as New" in gimp, you wouldn't need to create a new canvas or figure out any dimensions.

...Akkana

On Tue, 2007-06-26 at 01:30 +0200, peter sikking wrote:

[...]

actually right now I am specifying how the selection tools should deal with long, very narrow selections, with the web guys in mind.

Please don't forget other users :-) I routinely have a selection that's, say, 10,000 pixels by roughly 40 pixels. This might not be a usual case for Web graphics...

Liam

Liam,

actually right now I am specifying how the selection tools should deal
with long, very narrow selections, with the web guys in mind.

Please don't forget other users :-) I routinely have a selection that's, say, 10,000 pixels by roughly 40 pixels. This might not be a usual case for Web graphics...

an aspect ratio of 1000 to 4. cool.

at what zoom level(s) do you adjust this selection? and why?

thanks,

--ps

principal user interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

On 6/26/07, peter sikking wrote:

Please don't forget other users :-) I routinely have a selection that's, say, 10,000 pixels by roughly 40 pixels. This might not be a usual case for Web graphics...

an aspect ratio of 1000 to 4. cool.

at what zoom level(s) do you adjust this selection? and why?

At one point a few years ago I was working on very large maps for MMORPGs stitched together from many smaller images. It was not uncommon for me to have a 10000x250 selection. Not quite what Liam is doing, but still extreme. I generally created the selection at about 10x zoom, which meant I had to scroll 100 screens (1024 display width, 10000*10x image width) sideways. This would be much harder today, as it seems that GIMP has lost a lot of its old "scroll super fast if i drag far outside the window" functionality in more recent 2.3 builds.

Akkana Peck wrote:

I might have misunderstood this step (I definitely don't follow the comment about PS not letting you edit -- maybe that's a PS issue) but it sounds like if you did a "Paste as New" in gimp, you wouldn't need to create a new canvas or figure out any dimensions.

Oh yeah. Thanks for the tip. :)

--- Scanned by M+ Guardian Messaging Firewall ---

peter sikking wrote:

interesting to see "Compare compressed images against original", would it be enough to see the compressed one and balance that against the size and what your customer expects?

I usually do comparisons when I'm trying to get the best image quality out of jpegs. There seems to be a threshold with jpegs beyond which reducing compression only has a negligible effect on quality. I usually search for that point by reducing the compression of a low quality jpeg until it looks the same as (or close to) a high quality one. I suppose I could just reduce compression until it looks "good enough" but I prefer to do spot-the-difference style comparisons.

--- Scanned by M+ Guardian Messaging Firewall ---

On Tue, 2007-06-26 at 19:11 +0200, peter sikking wrote:

Liam,
Please don't forget other users :-) I routinely have a selection that's, say, 10,000 pixels by roughly 40 pixels. This might not be a usual case for Web graphics...

an aspect ratio of 1000 to 4. cool.

at what zoom level(s) do you adjust this selection?

100% or 50% most often. A sample use case is that I've scanned a woodcut or engraving with a border, such as http://www.fromoldbooks.org/Brown-LettersAndLettering/pages/171-English-Gothic-Capitals/ and I want to erase marks from the edges, such as fibres in the paper, foxing, or dirt... I'll start by making the whole image visible -- drag the borders of the window to make it smaller, then control-shift-E, then make the window bigger, and now I can use rect tool... the dragging is needed so as to get a border around the image so that I can drag the mouse pointer over it to select the whole image, as otherwise it's hard or impossible to select the edge at (say) 6% zoom... then I can go to 100% (or 50% or sometimes even 25%) and adjust the edge of the selection, then either crop or fill with white.

Another workflow is to make several selections, say 20, one at a time, because adjusting the selection can still use a lot of memory, although if you clear the undo history often enough it's OK.

Another use case might be if an image was damaged, e.g. the page was creased, or it's across 2 pages, or scanned in two parts, and I have to make a patch to cover a hole. Sometimes after rotating a scanned image by, say, 0.5 degrees, if there's a texture on the page I want to keep, I'll make a patch in the same sort of way.

Anyone working with print images is likely to have need for selections that are several thousand pixels long, too. E.g. consider making a selection and using "curves" in order to create a border.

Hope this helps, although I'm not sure how :)

Liam

peter@piments.com wrote:

Neither is chosing the appropriate format specific "the web" so "save for the web" concept is misleading. It should be "select best compression format" or so.

I have no argument with this. If we can do away with a separate dialogue altogether, so much the better.

It would be interesting to have a direct means of comparing various levels of jpeg compression side by side but this is not something you need to do in detail every time you save an image. There are so many variants once you have several formats and all thier parameters, that I think it would be hard to design an all encompassing interface. It would probably have to be done in several stages. A screen full of thumbnails with mouse-over zoom could eliminate the blantantly unsuitable formats and ratios. Then a second level do a closer comarison and probably a third level to fine tune compression options.

I don't think it really needs to be that complicated. All we're talking about is the options already available in the export dialogue and 2 or more preview panes. The controls could change to reflect the active pane.

BTW David I find jpeg "quality" param break-point is 82 -84 , beyond that as you say it gets bigger with no gain. You can drop to 65 if you're really byte conscious and quality is not important.

Somewhere between 70 and 80 per cent is about normal for me, but on my latest project I've been getting good quality at as low as 60. You're probably right that I could just use my eyes but I always succumb to the temptation to do a direct comparison. :p

--- Scanned by M+ Guardian Messaging Firewall ---

peter sikking wrote:

interesting to see "Compare compressed images against original", would it be enough to see the compressed one and balance that against the size and what your customer expects?

As an experiment at work I decided to work on just the one image when "saving for web" and found that I really don't need to do the spot comparisons between images after all. What's more important is the ability to change the quality of a jpeg with minimum faff. It turns out that PS's "save for web" has a couple of flaws in this regard:

1) No adjustment is made until *after* the slider has been released. This means that I can't just drag the slider up and down the scale to watch how the image quality changes. This wouldn't be so bad if it weren't for 2).

2) The slider's really small! It's easy to lose the slider after I've released it, especially as my attention is on the image, not the slider.

Basically I just want a way to assess the quality of an image at different compression ratios quickly. One idea that appeals to me is to have a row of 10 images all compressed at 10% intervals. Then I could just click the best of those. This would probably be good enough for most cases. If it isn't, I could have an additional step: click two adjacent images (e.g. 70% and 80%) to reveal another row of 10 images, this time compressed at 1% intervals between 70% and 80%.

--- Scanned by M+ Guardian Messaging Firewall ---

peter sikking wrote:

now it is getting late here too. if you can make that description really fundamental (like in principle for tens of thousands of web graphic designers), and filter your own biases out, then that would be great input for us.

but you better be sure it is fundamental >^}

Well the fundamental principle that every designer should understand is that your page is not going to look like your concept all of the time (this is where you often see print designers cocking up). A web page is a fluid thing that changes shape and it's important to account for this when you're cutting out images.

Unless you are tiling your background image both horizontally and vertically you're going to have to consider what the background of your element looks like once the background image exceeds its limit.

For example, you've got a that stores blog posts. You may have a vertical gradient as part of the styling of that div. The background image that makes the gradient is 100px high but the height of the div may be much greater. Typical styling might look like this:

#news { background: url(../img/news_bg.gif) white top repeat-x }

What's important here is that we've set a default colour to use if the div grows beyond 100px (which it will because bloggers have egos!). The tiled gif used in this case is a linear gradient that fades to white so that the overflow looks as natural as possible.

The other possible use of a background image is that it isn't tiled at all. In this case we still need to be able to ensure that, if the element grows, a bleed into a background colour keeps the styling as intentional-looking as possible.

I'm not entirely sure how I'd go about designing a website in gimp to deal with this problem - I'd probably use separate files. In PS I'd use nested layers and masks. Design the image for use in an infinitely large element and then use a mask to only show the image dimensions at the elements intended size. In this way, the concept can be shown to a client and then, when it comes to extracting the image, the layer can be isolated and its mask switched off to reveal the full image needed by the style sheet. The styling might look like the following:

# news { background: url(../img/news_bg.jpg) white center no-repeat; width: 20em }

I hope that's clear. I think the two things I'm trying to get across the most are that:

1) You always need a default background colour; 2) There are some parts of a concept you may want to hide because they deal with what happens when an element exceeds its designed limits and not with how the site is intended to look.

Sorry it took me a while to get back to you with this.

davidm

--- Scanned by M+ Guardian Messaging Firewall ---

On Wed, 11 Jul 2007 19:04:59 +0100, David Marrs wrote:

As an experiment at work I decided to work on just the one image when "saving for web" and found that I really don't need to do the spot comparisons between images after all. What's more important is the ability to change the quality of a jpeg with minimum faff. It turns out that PS's "save for web" has a couple of flaws in this regard: [...]

I think that Photoshop also does a couple of things in the right way and I would like to confirm that but I do not have access to PS. Besides allowing you to quickly check how changes in quality affect the final output size, it also automatically changes the way a file is saved compared to a normal "Save". I remember reading somewhere that "Save for Web" was automatically discarding metadata that is not useful for the web and also allowing you to easily omit ICC profiles and other things that increase the file size (assuming that web browsers use sRGB).

It would be nice if you or any other Photoshop user could confirm that "Save for Web" automatically discards metadata. I am almost sure that it discards XMP and probably EXIF (at least the thumbnail), but I am not sure about IPTC. So if you have an image that contains metadata such as copyright, author, location, all camera settings and so on, please try to save it with "Save for Web" and reply to this list saying which of these fields are preserved in the final output and which of these are discarded.

-Raphaël

David,

first of all thanks for taking the time to give us input.

There is one phrase here that I am not sure how to interpret:

I'm not entirely sure how I'd go about designing a website in gimp to deal with this problem

The "designing a website in gimp" sounds scary to me because I then immediately think of the overall layout and how it fluidly resizes. I can only hope that for you it actually means producing the actual images that go into a website.

Overall, I see that you call for support in GIMP to evaluate how a certain image will work over a solid background color (hmmm, that could
be also over a background image), and support for flexible masking to evaluate how things work under resizing.

--ps

principal user interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture