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
[EMAIL PROTECTED] [EMAIL PROTECTED]
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
