> 10. better printing support
> Paper, maybe better called media, could be handled as special kind of
> layer that is restricted to stay below all image layers (unless hiding
> stuff below it makes any sense).
Think workflow, not about highjacking a image concept (layers):
_putting_ it on paper will be handled as a dedicated workflow.
It looks logical to reuse the main window for that, to reuse all that
space, looks logical to us.
> But paper alone is not a sufficient model, I fear. There's the thing
> you print on and the final product (after cutting, perhaps) ...
> PDF has this media/crop/trim/bleed/art box model. Scary stuff ;)
> Better written, but german: http://www.dtp-praxis.de/tipps/
Wow scribus, a pre-press oriented (that is their product vision) dtp
GIMP's ambitions to not reach that far.
The essence of working on the user interaction level is to concentrate
on what in GIMP will enable the user to deliver artistic results, and
to handle all that technical gobbledegook in the code.
> 7. save for web
> Should include indexing for GIF (mandatory) and PNG (optional).
> If one needs to create a number of images in indexed colour mode that
> share some colours and where deviations are not acceptable, there
> should be an alternative to indexing them all as one image to then
> cut them apart.
I would really measure this static-indexed requirement against the
product vision before throwing in yaUIc (yet another UI complication).
And why are we talking teensy little details here when the presentation
and blog entry was about solutions models: the general direction
principal user interaction architect
man + machine interface works
http://mmiworks.net/blog : on interaction architecture
Gimp-developer mailing list