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
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
