[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Re: Gtk+ printing dialog highlevel thoughts
From:       Bill Haneman <Bill.Haneman () Sun ! COM>
Date:       2006-01-23 13:47:30
Message-ID: 43D4DE72.7050201 () sun ! com
[Download RAW message or body]

Alexander Larsson wrote:

>On Mon, 2006-01-23 at 11:48 +0000, Bill Haneman wrote: 
>  
>
>>Alexander Larsson wrote:
>>    
>>
>>>Nobody is going to render their paper output with theme colors, that
>>>just isn't the way apps are set up (i.e. the printing output is not
>>>coupled to the current on-screen settings). So I think it will be hard
>>>to do it like this. Maybe we could just invert the pixmap before we
>>>paint it in the preview or something like that.
>>> 
>>>
>>>      
>>>
>>No Alex, that won't do.  The fact that users won't render paper output 
>>this way doesn't matter; what matters is that for some users, the "print 
>>preview" must be themed rather than WYSIWYG.
>>    
>>
>
>Of course I didn't mean people would render paper output this way. When
>I say "Nobody" it meant "no developers of applications that print".
>
>The fact is that applications print documents, and applications do not
>select colors of elements in a document based on theme settings in the
>current display, they select them based on the data in the document.
>
>  
>
>>The print preview mechanism MUST be theme-aware, or at least themeable 
>>(i.e. fg and bg colors must be speciable via the theme).  This is a 
>>"hard" (i.e. firm) accessibility requirement, I didn't make it up :-)
>>    
>>
>
>When you say that this is a "hard" requirement, from where did this
>requirement come?
>  
>
One place is the 1998 amendment to Section 508 of the Rehabilitation Act 
in the US:

The part usually cited with regard to "theme compliance" issues is

"1194.21 Software applications and operating systems.
...

(g) Applications shall not override user selected contrast and color 
selections and other individual display attributes."

It could be argued that a print preview widget is a special case (like 
an image viewer) which inherently is unsuited to this guidline, and in 
fact some OS's may do so.  But the fact remains that some end users who 
need specialized visual settings will be unable to effectively use a 
"normal" WYSIWYG print preview dialog.  For these users, regardless of 
the strictness of one's interpretation of 508.1194.21(g), a themed print 
preview widget is useful, because it allows those users to review 
formatting and pagination.

I think most people will agree, on consideration, that of the various 
things a print preview provides, pagination and formatting is somewhat 
more important than color feedback.  In this respect, theming the print 
preview dialog for such end users (as a non-default configurable 
setting) is a good thing.

The purpose of my post was to point out the need for this behavior in 
some cases (i.e. use of themed colors in print preview).  You rightly 
point out that there are some technically questions that arise, but I 
wanted to make sure everyone understood the use case before delving into 
details.

As you point out, making the background black would result in 
black-on-black printing unless the print preview widget understands the 
concept of "foreground" color.  I suggest that what is really 
appropriate here probably looks like this:

1) set paper color to theme "base" color (i.e. background for text)
2) convert all font/character colors to "text" foreground color (since 
print preview widgets can explicitly print text in colors other than 
'black')
3) omit background images (tricky since it may be difficult to determine 
if an image is a "background" image or not)

A problem arises with non-textual line art; if it's omitted, useful 
information can be lost, but if the line art is, for instance, a filled 
rectangle with text printed over it, the above transformations can ruin 
visibility.  A brute-force solution which probably would work for most 
of our target cases is to convert all line art to unfilled, drawn with 
"fg" color from the theme.

I believe I've seen print preview widgets that "themed" before, but 
can't say where.  To some extent it doesn't matter if other OS'es get 
this right yet or not, since the need is demonstrable.

In any case I would not argue in favor of this being the default; there 
will doubtless be some users of "accessibility" themes who still expect 
print preview to be non-themed.

Bill

>We can easily let you specify the background of the print preview
>widget, but there is no "fg" involved. The page contents is gonna be
>whatever the application prints. We could add a token "get_fg_color"
>method somewhere, but in practice apps wouldn't call it, because a
>document has no concept of "fg color". Take a word processor document
>where the user selected various colors for various parts of the text.
>Which parts are "fg"? In fact, setting fg to white and bg to black in
>such a setup is likely to mean black text on black background in most
>apps/documents.
>
>Does any other system handle this? For sure, having looked at windows
>and OSX neither of their printing APIs they seem to have a way to get at
>any sort of screen properties in their page rendering APIS.
>
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Alexander Larsson                                            Red Hat, Inc 
>                   alexl@redhat.com    alla@lysator.liu.se 
>He's a Nobel prize-winning overambitious farmboy on the wrong side of the law. 
>She's a vivacious extravagent Valkyrie with a knack for trouble. They fight 
>crime! 
>
>  
>

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]