Thorsten wrote: > 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 ;) > http://bugs.scribus.net/view.php?id=1041 > Better written, but german: http://www.dtp-praxis.de/tipps/ > pdfboxen.htm Wow scribus, a pre-press oriented (that is their product vision) dtp app. 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 forward? --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
