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):
> I thought I did. Think about workflow.

Then how do you end up selecting an intra-image concept (layers)
to support the task of putting the actual image itself on another
medium (paper)?

If you concentrate on understanding the task, then thinking about
layers feels wrong within a second, and you can move on to solve
the problem in another way.

>>> 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:
>>> pdfboxen.htm
>> Wow scribus, a pre-press oriented (that is their product vision) dtp
>> app.
>> GIMP's ambitions to not reach that far.
> The nature of Scribus is not of interest here, Ther just happens to be
> an english language description of the terms in their bug tracker.

The different nature of scribus is of interest here, because its
users that fit their product vision (pre-press) need awareness of
this technical pdf stuff.

> It doesn't matter if you deal with complex page layouts or "just  
> images".
> It also doesn't matter much whether you target your desktop printer
> or a larger machine. The issues of media size, printable area, bleed
> and desired final size are just there.

All those concepts fall within GIMP users' awareness and are actually
named in the blog entry as interrelated textfields that support the
placement. But they will be handled in the UI in a way that gets
artistic results done, and not in technical pdf file format terms.

>> And why are we talking teensy little details here when the  
>> presentation
>> and blog entry was about solutions models: the general direction
>> forward?
> It doesn't look to me like there is anything to discuss about your
> solutions model. I would mean this in a bad way if it didn't look like
> you know what you are doing there and if what I read didn't seem all
> agreeable.

What I mean to say is: can you see that all this detail stuff
does not really matter at this moment, unless one of these details
invalidates the overall concept?

This is the way to cut through the jungle of small details, and
to concentrate on major problems that need to be solved first.


         principal user interaction architect
         man + machine interface works
 : on interaction architecture

Gimp-developer mailing list

Reply via email to