The preview is supposed to show the document as it is printed. It
would be complete nonsense to adjust the appearance of the preview to
a theme. Changing the preview to show some other colors or fonts would
render this preview completely useless. GNumeric at least would then
need to write its own previewer to show the sheet as it will print.

This isn't nonsense at all.  I agree that the default rendering of a
"preview" should be as WYSIWYG as possible.  However this bug is about
accessibility requirements; some users with specific types of vision
problems need the print preview to behave differently in order for it
to be usable for them.  If we don't address this need, the print
preview will be useless to them.

For instance, if a user has a vision problem that makes large white
areas onscreen physically painful (not such an uncommon condition,
 actually) then the "normal" print preview will be unusable for them,
they would need white text on a black "paper" background; and of
course they would realize that the result would be printed
black-on-white as normal.  Also, some users (with different needs) who
need very high contrast may want all text to be "black" on "white"
paper even if the actual printing will be in a lighter color or on a
darker paper or background.

I hope this explains to some extent why it is sometimes useful and
desirable to display a print "preview" with color attributes that are
not 100% WYSIWYG.  At any rate it is required to meet accessibility
guidelines and requlations in a number of countries.

-Bill

Phew, Bill saved me the trouble of saying all that myself :)

What we need to discuss here is how best a theme-compliant preview
option would work.  My initial thought was just to have a monochrome
preview like the 'monochrome' option in GIMP's Print dialog-- that is,
it literally rendered each pixel either black or white depending on
whether it's actual value was above or below a certain threshold. 
(Where 'black' and 'white' would be appropriate gtk theme colours in
our case.)

However, I gather that the print preview uses a canvas rather than
just displaying a pixmap, so we can probably do something more useful
like displaying all text in 'black' even if its actual colour is quite
pale.

The problem then is how to render filled "shapes".  For example, in a
drawing or presentation program, a flowchart might use dark filled
shapes with pale text superimposed.  If we filled such shapes in
'black' and also displayed all text in 'black', you wouldn't see the
text.  One possibility, assuming we even have control over this, might
be to only ever draw the outline of such shapes, rather than filling them.

Also, any pixmaps embedded in the preview would probably still need to
be rendered using something like the threshold-based monochrome scheme
that GIMP offers, which I mentioned above.

Lets nail this sucka'

dunno what that means ;-) but I'd like to fix this.

excellent!

The way I think we should fix it is by implementing two properties:

1. One property that sets the preview to a)normal b)grayscale c)black
& white &
2. A boolean property to not fill non-text objects. For the example
about a presentation above.

#1 is simple and #2 is tricky, I'll fix #1 since #2 is not a problem
as of right now. Whenever there is a gnome-print app that is drawing
text above a background (like the example above) then we can reopen
this bug and finish the second part, there is no point in me
implementing something right now that nobody is going to use and I
don't have a good way of testing it.

3. An invert boolean flag too

hmm, I see some problems with this approach.

If the configurable behavior is simply whether to use the gtkstyle's
text, base, fg, bg colors, then there is no need for an inverse
boolean (which in any case would be hard to figure out when to apply).

It'd be better to base this on the theme's colors.  Just adding
"accessibility features" actually doesn't meet accessibility
requirements, since there's a legal requirement that the UI respect
system colors (as opposed to a requirement that the UI be able to do
black and white or inverse, etc.)

Also, I don't think changing the non-textual elements to a non-filled
shpare would be satisfactory for low-vison, since the resulting line
art could be hard to see.  I think that here, too, elements from the
theme's colorset would be better.

So in my opinion there should be only one boolean flag, which
determines whether the print preview is WYSIWYG or restricted to the
theme colors.

So if this flag is true then all the objects printed (previewd) are
the theme text color and the paper is the color of the theme's
background. If so, i guess we don't need a gconf key for this
particular feature. What is the 'global' accessibility enable/disable
switch.

If this flag is true then all objects (no matter what their original
color are) will be printed with the theme text color and the paper
with the background.

Does this work?

There still should be a switch for gnome-print.
That's because there isn't really a "global accessibility switch"
since there are many kinds of accessibility.  The existing gconf key
is for assistive technology support, not theming, thus users who need
strict theme compliance wouldn't necessarily (or normally) have it
turned on.

I think a preferences checkbutton under Print Preview, with something
like "Use theme colors only", would work here.  The gconf key would be
something like /desktop/gnome/print/preview_uses_theme,
or perhaps we could create a /desktop/gnome/interface/strict_theming
key that could be respected by other applications (putting the key in
/apps seems odd for a library function like gnome-print, perhaps we
should have /desktop/gnome/libs as well as
/desktop/gnome/applications).  If you don't think putting this under
an "applications' gconf key folder, then
/gnome/desktop/applications/gnome-print/preview_uses_theme seems OK.

what does "under Print Preview" mean? which menu/dialog/property box.

I am referring to where the gconf key lives.
I don't have an opinion (yet ;-) on where a corresponding
user-settable checkbox should be, among our capplets.

My initial guess would be that you'd just want a checkbox menu item on
the Print Preview's View menu... although it would probably also be
nice if accessible metathemes were able to preset this :)

Ok, good. I was just fearing that you meant on the print preview
window to put a widget there to set/unset it ;-).

Find with me, i don't need to the EXACT gconf key to do the development.

So it looks like the only thing needed is the code ;-) right?

The code will do:
If the "follow-themese-for-pp-or-whatever" key is set, don't honor the
'paint' color take it from the theme. Same for the backgound.

If the "don't-use-grayscale-for-print-preview" key is set, the all of
the 'paint' elements are black, only on/off no shades (where black
could be modified by the above key).

Ok?

Created attachment 13050 [details] [review]
patch

Attached a patch

- To test:
 1. cvs up & make install libgnomeprint
 2. patch, make libgnomeprintui
 3. in libgnomeprintui/tests run:

[chema@entropy tests]$ ./test-preview 
[chema@entropy tests]$ export
GNOME_PRINT_PREVIEW_STRICT_THEME_COMPLIANCE="True"
[chema@entropy tests]$ ./test-preview 
[chema@entropy tests]

- I still don't love the patch, need to sleep over it
- I'm taking the state from an env variable, because libgnomeprintui
does not depend on gconf. How do we set/unset this flag?

Comments wellcomed.

Created attachment 13052 [details] [review]
Minor update to the patch

Created attachment 13053 [details] [review]
don't screw up this time

I'll keep the latest version of the patch at:
http://www.gnome.org/~chema/libgnomeprintui_96802.diff

disregard all other patches.

Have gotten enough mail from bugzilla yet? ;-)

Hmm, this doesn't create a libgnomeprintui/tests/test-preview for me...?

I did try setting the environment variable, running gedit, and doing a
Print Preview from there... but while the colours looked *different*,
they didn't seem to follow the theme in any noticeable way... so I
guess that's not the way to test it :)

(Oh, also GNOME_PRINT_PREVIEW_STRICT_THEME_COMPLIANCE is too long a
variable name for tcsh to handle, I had to run it in bash instead!)

D'oh darn sticky tags, didn't have latest libgnomeprintui from HEAD :)
 Let me try again...

Hmm, still doesn't work for me, I see exactly the same monochrome
preview whichever theme I have selected :/

Did you patched libgnomeprintui? Also, note that test-preview is in
libgnomeprintui not libgnomeprint.

Yes, the patch worked.  I'm seeing a difference (colour v. monochrome)
depending on whether I have the environment variable set or not.  But
when the variable is not set, I'm just seeing the same preview
whichever theme I use (screenshot attached).

Oops, I mean "when the variable is set", not when it is unset.

Created attachment 13075 [details]
Preview that I'm seeing with variable set, regardless of chosen theme

Oh, and by "the patch worked", I mean "the patch applied" :)

Yes, I need to know which theme elements do you want me to use to draw
on the screen, right now I'm using:

style->text [GTK_STATE_NORMAL] & style->bg [GTK_STATE_NORMAL]

which are probaly not the right ones to use.

About the preview being strict even without the env var not set, I
think the bug is somewhere between the keyboard and the chair ;-),
here is the code to determine if we go strict or no:

+	priv->theme_compliance = FALSE;
+	
+#ifdef __GNUC__
+#warning FIXME: Figure out how to set this
+#endif
+#if 1
+{
+	const gchar *env_var;
+	env_var = g_getenv("GNOME_PRINT_PREVIEW_STRICT_THEME_COMPLIANCE");
+	if (env_var && env_var[0])
+		priv->theme_compliance = TRUE;
+}
+#endif

This clearly makes a difference for me (under bash):

[chema@entropy tests]$
GNOME_PRINT_PREVIEW_STRICT_THEME_COMPLIANCE="true" ./test-preview
[chema@entropy tests]$ GNOME_PRINT_PREVIEW_STRICT_THEME_COMPLIANCE=""
./test-preview
[chema@entropy tests]$

hi:
should use text[NORMAL] on base[NORMAL]
(as opposed to text on bg).  That goes for any state.

I've updated the patch with the new theme elements, but it seems to
not be right. Do you have a URL for the inverted theme? that would
help me test it.

Yeah, it is not picking up the theme correctly. Fixing it...

I've updated the patch, this time it actually works ;-).

Fixed in CVS and will be in 2.1.5, the variable is
"GP_PREVIEW_STRICT_THEME"

Tested and seems to work as expected, great :)

However making it work via an environment variable isn't really a
viable long-term solution... what are the alternatives?  Xsettings
maybe? (Why doesn't libgnomeuiprint depend on gconf anyway, doesn't it
need to access things like user's preferred printer, paper size etc.?)

No, no Xsettings for me, if we need 'something' like gconf, it will be
gconf. We read paper/printers directly for cups right now, for the lpr
module we will read the pritncap file to know the printers, so no need
to store those settings, we still haven't solved the problem of where
the default printer is stored.

For per settings apps, apps get a string from gnome-print that they
save themselves and they can give it back to gnome-print to
deserialize it and make it a GnomePrintConfig again.

The main reason it does not depend on gconf is because there isn't aa
need for it yet.

I agree that the env var is sub-optimal.

Ah, that would certainly explain why the damn thing never seems to
rememeber my printer settings on Solaris, which doesn't use cups or
have a printcap file :)

But yes, we'll probably need to come up with some better solution
relatively soon, as I suspect using an environment variable to toggle
an accessibility feature probably isn't very 508-compliant.

Updating status_whiteboard field to reflect A11Y team's assessment 
of accessibility impact.

It doesn't look to me as though this bug should be marked "fixed"
since it uses an (undocumented) environment variable in order to work.

Correct fix is to make this behavior configurable, sounds as if
there's consensus to use gconf here.  So is someone going to do the work?

Bill,

Remember that the problem with gconf was not writing the code but that
libgnomeprint doesn't depend on the gconf chain: Orbit, oaf, linc & gconf.

Reopening this as I can't see why it should be NEEDINFO still.

This a11y stopper bug would be nice to fix before the July 7th
UI freeze deadline.

Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME
bug list :)

Removing the PATCH keyword as the patches that are attached to this
bug have been applied and there isn't a patch for the remaining issue.

I am wondering about the status of this bug.  It seems that Bill
wants the accessibility features to be configurable in a more
stable way than using an undocumented environment variable, but
Chema does not think it is appropriate to add gconf as a 
libgnomeprint dependency.  So I'm wondering if we can discuss what
the appropriate solution could be.  Could libgnomeprint call 
"gconftool-2" via the command line to get/set the value?  This
would allow libgnomeprint to use gconf without making it a compile
dependency.  It could fallback to the undocumented environment
variable if gconftool-2 isn't available on the system.  Just an
idea.

I think adding some API to libgnomeprint makes more sense; it could be
a generic property/value API or something more specific.

Then, an application calling libgnomeprintui can specify these
properties without resorting to use of gconf at all.  For instance, an
app could call libgnomeprintui specifying property
'use-theme-colors=true'.

Adding 'API' keyword.  This needs to be resolved in the next 3 weeks!

I don't see how gnomeprint api would help.  That just pushes the
problem up a layer to the application.  How would the apps know when
to set the magic flags.

Handling this at the theme level seems like the most acceptable
kludge, but at least its probably slightly better than adding a magic
'use theme for print preview' button is one of the a11y capplets. Are
there any mechanisms in place for a theme to set additional flags of
some sort ?
eg xsettings, or gconf ?

Lets walk through things slowly and see what fits.

Hi Jody:

maintainer has said 'no gconf, no xsettings'.  Existing patch uses an
environment variable, ugh.

Pushing the problem up to the parent application _does_ make sense
because 95% of the time the host/parent application uses gconf, and
thus can make a decision about whether to pass the info to
gnomeprintui or not.  Perhaps even better would be to have a new
variant API for creating a gnomeprintui dialog/preview, make that the
'preferred' API to use, and always pass some minimum theme info or
flag to that API.

The solution in terms of user-behavior that has been deemed acceptable
is to have gnomeprint's preview follow the theme colors (as opposed to
WYSIWYG colors) only if a particular gconf key is set - but since
libgnomeprintui doesn't depend on gconf...

Jody: since time is _so_ short for GNOME 2.6 API, a possibility which
I think would be 'ok' (though not ideal) would be to apply the
original patch, which uses an environment variable, and then in future
add a friendlier API for achieving the same thing.  I don't think we'd
need to remove the env variable API, we could keep it compatible
without heroics I think.

The API need is this: we need either a boolean that says "use theme
settings for the preview", or we need api that allows us to say "use
this style(s)/theme for the preview".  The second API would basically
use "no style" for the preview (e.g. WYSIWYG) if the style was NULL or
unspecified.

In reality the boolean would serve the purpose nearly all of the time;
I think tweaking the exact preview theme to make it different from
either WYSIWYG or the 'current gtk+ theme/style' is overkill.  I
believe the env variable in the existing patch is just that, a boolean.  

If we use something other than an env variable, then we do introduce
an additional burden on clients of gnomeprintui, since they would need
to decide (according to some gconf key, presumably) whether to set
this boolean in the gnomeprintui preview component or not.  This means
non-gconf apps couldn't play, which is a downside.  But relying on an
env variable means that we'd have to tell users who needed this
feature to modify their login environments (!), hardly a user-friendly
approach... can gnome-settings-daemon much with the user environment
in response to gconf keys?  Just wondering... if so, we could apply
the above patch, and just add a bit of code to gnome-settings-daemon
to manage the print-preview-uses-theme boolean.

As for the eventual exposure of this to the user, I don't know what's
best.  We could have put this as a checkbox in libgnomeprintui, but
then gnomeprintui would need a way to persist the setting, which it
currently doesn't seem to have.  But that would be a nice alternative.
 Otherwise, in what user-visible desktop preferences UI do we expose
the boolean key?

from recent IRC discussion:
<billh> so did we come up with plan?
<billh> IIRC options are:
<billh> (1) env variable
<billh> (2) checkbutton on print-preview GUI (not persisted across
apps/session
)
<billh> (3) put it in the theme and wait for the bug reports
<billh> (4) add API to print-preview that apps have to use, setting
according t
 something (a gconf key?)
<jody> I'm going to rule out #4 out of hand
<aguelzow> #2 preset by gconf ?
<jody> forcing cut-n-paste code into applications for this is not viable
<jody> aguelzow: with a global key to that stores the last setting ?
<aguelzow> yes
<jody> that would side step the requirement of a capplet to set the flag
<jody> and make it moderately more visible
<aguelzow> it is also where users migh expect it.
<jody> but would add gconf to the set of depends.  We'd need to be
able to disa
le that if gconf is not available for a win32 build
<aguelzow> yes, so without gconf we don't persist.
<aguelzow> (or replace gconf with some windows-only conf.)
<billh> so we're leaning towards #2 with persistance if gconf is
available?
<jody> y
* billh likes the sound of that


so I think there's a way forward here.

Any suggestions on the wording of the check button text? ("Show themed
preview"?)

What on the preview specifically should change? I can't see how
changing the fonts for example will make any sense since it would
affect linebreaks and the general layout.

Of course I don't really see how any preview that is not a real
preview makes sense.

Andreas:  the answer to question #1 is (alas) in the long bugzilla
history for this bug - much of which has already been fixed.  Short
answer is that we are concerned with colors  of the content (but not
size, as you say) and line-weight, etc. for non-content elements.  So
mostly this is a request to make everything in the preview pane theme
properly _except_ the content (which I think it does already), and to
make the content use the theme colors (as a user option).

I'd make the button say "use theme colors for content".
tooltip: "View the page's contents using theme color settings rather
than ink colors".

I think I'll need a bit more info, namely how should the colours be
mapped from specified colour to theme colour. Suppose we have a
background in colour1 with 1 square each in colour2 and colour3, with
two strings, each string running across the background and the 2
squares one string in colour4 and one in colour5:

    --------     ---------
    |      |     |       |
   first long string goes across
    |      |     |       |
   second long string goes across
    |      |     |       |
    --------     ---------

Which theme colour should be used for each of colour1 to colour5.

Andreas

The 'theme color' palette is very restricted - probably no really nice
mapping can be created which preserves the subtlety/distinguishability
of the content.  In order to avoid loss of contrast, I'd
recommend using 'text_gc' for all text, and 'base_gc' for the paper
color.  From there, fg_gc should be used for line art/graphics
primitives.  (I think light/dark/mid gc's are probably not too useful
in this case, and the mappings would be messy if we tried to use these
other theme gcs).  The primary use case for this feature is
HighContrast and HighContrastInverse (and the 'Large' variants of
these two themes), and in both of these cases, contrast is more
important than faithfulness to the content WYSIWYG.  

Probably the most important case is HighContrastInverse - some users
cannot tolerate large areas of white/bright screen, and need
white-on-black text and graphics.  As long as the checkbox allows
white text on a black page, I think we're OK here.  In the case of a
large light-colored graphic behind the text, the probable best mapping
would be for rectangular areas to be painted as 'unfilled' rectangles,
or rectangles with fg_gc outlines, but filled with bg_gc.  This would
of course reduce the content 'preview' to schematic 'line art', but of
 course the WYSIWYG view could be chosen by the user if his or her
vision made such a view useful as an adjunct.

Does that answer your question Andreas?

If I understand this right:

all text:                 'text_gc'
all background:           'base_gc'
all line art:             'fg_gc'
all fills:                'bg_gc'

and a special case for shapes (including images) that have no outline
but are normally recognizable by their fill alone:
               outline in 'fg_gc'
and            filled by  'bg_gc'  

sounds good, thanks!

Created attachment 23521 [details] [review]
Proposed patch

The above patch provides a check button in the preview to theme the
preview page's content (without the gconf dependency).

Created attachment 23522 [details]
Screenshot of the preview page with the changes

On first glance the patch looks good to me, I'll test it later today.
I am wondering about the location of the checkbox. Note that when the
preview page is completely empty (try gnumeric with an empty
worksheet) there is a relatively long text appearing instead of teh
second `1'. That would likely move the checkbox. It may be better to
place the checkbox on the right of the preview.

Agreed, I was going to suggest the same thing (aligning the right edge
of the checkbox with the right edge of the window)...

Hi Muktha:

Could you attach a screenshot as above ('preview page with the
changes'), either revised as suggested comments, or not - but with the
checkbox checked?  That way we can make sure the drawing is working as
designed (with the appropriate gc-s as suggested above); ie. text
white, page color nearly black, horizontal line white, etc.)

Created attachment 23550 [details] [review]
Modified patch to align the check box with the right edge of the window

Created attachment 23551 [details]
Screenshot with the checkbox checked and aligned to the right

Thanks Muktha
the screenshot looks good.
I do notice that the white text is still a little hard to read,
probably due to antialiasing/interpolative scaling since it's getting
reduced in size.  I wonder is there anything that can be done about
that, for instance turning off smoothing in the pango layout when the
'use theme' button is checked.

the print preview does not use any pango (unfortunately)

your patch is missing the corresponding Changelog entry

Hmm, your patch breaks previewing of coloured shapes (eg. coloured
filled rectangles). With your patch (and the checkbox off) the shape
appears in black.

Created attachment 23675 [details] [review]
Modified patch to take care of the colored shapes

nice work! I have committed the latest patch to cvs HEAD.

*** Bug 158012 has been marked as a duplicate of this bug. ***

Bug 158012 claims that things aren't perfect. If somebody from the accessibility
people agrees with that please reopen this bug.