Regarding the fuzzy fonts, I may not understand the particular problem here, but perhaps this will help.  There is some issue with Snow Leopard not activating sub-pixel antialiasing on some monitors that don't report that they are a LCD.  Other causes of fuzzy fonts are running your display at non-native resolutions, unusual subpixel ordering, incorrect monitor profile, perhaps bad fonts?

One fix is to force antialiasing on with this command in Terminal:
defaults -currentHost write -globalDomain AppleFontSmoothing -int 2

You need to log out and back in to fully take effect.  The number at the end can be one of the following:
* 0 - CRT rendering (looks horrible on LCD)
* 1 - Light smoothing
* 2 - Medium (Best for Flat Panel)
* 3 - Strong

You can reset with:
defaults -currentHost delete -globalDomain AppleFontSmoothing
or in the Appearance System Preference, uncheck "Use LCD font smoothing when available".

References:

[...]

On Nov 6, 2009, at 17:30, ghe wrote:  
  On Nov 6, 2009, at 9:02 AM, Christiaan Hofman wrote:

[...]

No, that's not possible. A big difference with CSS is that the latter  
has prioratized settings. Views just have setting. 

 Christiaan  
  

Please file enhancement bug request for what you would like the OS to provide.

Patti

On Nov 6, 2009, at 7:06 AM, ghe wrote:

[...]

[...]

Yeah, I know the developer sets it (and sorry about calling it a  
window -- it's been a while since I was there). I was thinking it  
might be possible for Quartz (that's what actually makes the display,  
right?) to set the color to something specify-able every time it  
creates a view. [...]

On Nov 6, 2009, at 16:06, ghe wrote:  
 More reaction to the yellow screen...

[...]

No, that would help nothing. What you see is not the window background  
but whatever color the view has. And that is some fixed value that is  
essentially set by the developer (though probably through IB, but   [...]

More reaction to the yellow screen...

[...]

Apple people: might it be reasonable, in the Accessibility prefs, to  
tell Quartz to set the background of all windows to a selectable  
value? And maybe text areas and buttons and other widgets too?? Or   [...]

[...]

Forwarded, and reply:

[...]

Thank you, Martin!  
 Now, the fonts. How to make them big and black and hard-edged?  
 --
Glenn English
email@hidden  

 

Hi Glenn,  
The UI is not be very clear on the app, but if you turn on the menu or  
slider control, that is what actually sets the brightness, not the Min  
brightness slider. Your friend might not have realised this. Here is a  
photo of a yellow tint with the actual brightness slider in shades set  
to minimum (screenshots don't capture it. Also excuse the ruler but  
otherwise the iPhone tries to shift the white balance to remove the  
yellow, had to put a white object in shot): http://dropbox.mcubedsw.com/skitchpics/Yellow%20screen.png 

 Martin  
 On 5 Nov 2009, at 10:34 pm, ghe wrote:  
  On Nov 5, 2009, at 8:46 AM, Martin Pilkington wrote:

[...]

I forwarded your suggestion. His reply:

[...]

Hi,

I have a custom NSCell that's in a table view and the Accessibility
Inspector and Verifier are complaining about not being able to get a
window attribute. The documentation seems to suggest that NSCell
should be able to provide it, but it doesn't and there's no way for me [...]

[...]

Forwarded (with comment), and his reply:

[...]

[...]

I forwarded your suggestion. His reply:

[...]

In the Appearance system preference, there's a popup button to determine the font size to not use text smoothing.   Try change it to the largest value possible, so smaller fonts will not be displayed with the soft edge.

Patti

On Nov 5, 2009, at 6:59 AM, ghe wrote:

[...] [...]

Hi Glenn,  
I'm not sure how to get around the font issue, but I do have a  
suggestion for the yellow-ish background. There is an application I  
use called Shades (http://www.charcoaldesign.co.uk/shades) which  
allows you to add a tint to your screen. [...]

My very good friend, Jerry, is losing his eyesight to glaucoma. At  
this point, his ability to read depends very greatly on chars having  
hard edges, being very large, and a high contrast display on a yellow- 
ish background. He lives 1000 miles away, so I have to work on this by  
email. [...]

All examples that used to ship under /Developer should now be in the ADC sample code library. If not, it should probably be logged as a bug (in this case that there is a sample missing)

If it hasn’t been updated, that’s probably a different situation. Is the API is present? [...]

Done.    rdar://7358047    Cheers,       Tomas     Le 2 nov. 2009 à 19:55, James Dempsey a écrit :    Have you filed a bug for this issue?  If not, please do so at bugreporter.apple.com.     Thanks,     James       On Nov 1, 2009, at 1:32 AM, Tomas Zahradnicky wrote:   Hi Martin,    I've faced this problem in the past and finally solved it with the following code. VO ignores the control move and does not refocus the VO cursor to another control. Try this code, it might help you.      void AU_SynchronizeVoiceOverCursorForWindow( WindowRef inWindow )  {      //-------------------------------------------------------------------      //  Theory: In fact, it should be sufficient to just move      //  the control. All standard controls should do the same      //  as Window Manager does when a window moves, that is,      //  broadcast a kAXWindowMovedNotification notification.       //  This kind of notification does not work when the actual      //  window position does not change.      //      //  Current state: Control Manager either does not broadcast      //  kAXMovedNotification or it gets ignored by the VoiceOver.       //        //  Result: VoiceOver cursor overlay does not update.      //      //  To go around paragraph 1 limitation, we really change window      //  bounds and return it quickly back. As a result, VoiceOver      //  cursor sticks the original user element it was above and      //  updates its position.      //      //     Author: T. Zahradnicky      //  Cite this:      //    @inproceedings{1427145,      //      author = {Zahradnick\'{y}, Tom\'{a}\v{s} and L\'{o}rencz, R\'{o}bert and Musil, Pavel},      //      title = {Making ProTools Accessible for Visually Impaired},      //      booktitle = {ICCHP '08: Proceedings of the 11th international conference on Computers Helping People with Special Needs},      //      year = {2008},      //      isbn = {978-3-540-70539-0},      //      pages = {781--788},      //      location = {Linz, Austria},      //      doi = {http://dx.doi.org/10.1007/978-3-540-70540-6_116},      //      publisher = {Springer-Verlag},      //      address = {Berlin, Heidelberg},      //    }          //      //-------------------------------------------------------------------      Rect bounds;         DisableScreenUpdates();      GetWindowBounds( inWindow, kWindowContentRgn, &bounds );      MoveWindow( inWindow, bounds.left-1, bounds.top, FALSE );      MoveWindow( inWindow, bounds.left, bounds.top, FALSE );      EnableScreenUpdates();  }     Best Regards,       Tomas         Le 26 oct. 2009 à 20:56, Martin Pilkington a écrit :   Hi Patti,    After a view slides in, it seems that the VoiceOver cursor still tracks the previously pressed button. As I simply hide the controls after they have moved off screen, doing control-option-left/right will go to the first or last element in the window, so that seems to be another problem (how would you change the selected VO item in code?). But yes, users do have a way to explore the new controls in the window, but it's a case of how do you inform the user there are new controls to explore. To give a better idea of what is going on in the UI I've done a quick screencast of how the system works: http://dropbox.mcubedsw.com/regsystem.mov . As you can see, once the register button is pressed the view changes immediately, but there's only a visual indication that this has happened. And it's worse with the verify button as the change happens some time after the button was clicked, not immediately like with the register button.      The sheet is accessible and can be fully controlled with VoiceOver, but I'm also wanting it to be user friendly, which to VoiceOver users it isn't yet.     Thanks     Martin     (Re-posted due to just hitting reply... stupid mailing list/email client/everything but me)     On 26 Oct 2009, at 6:07 pm, Patti Hoa wrote:   Hi Martin,   If you are using NSView to hide/show the panel, then it would be best to leave it up to AppKit to determine what notifications to send (probably a combination of AX destroyed/created notifications).  In any case, right now VoiceOver is not really listening for any of those notifications.   What happens when you do control-option-left/right arrow after one of the new panel slides in.  Can VO cursor continue to land on the new UIs?  If so, users still have a way to explore the new UIs in the window.   If not, then explain in detail the behavior of VoiceOver interaction after a new panel slides in.     Patti  VoiceOver Engineer     On Oct 26, 2009, at 6:22 AM, Martin Pilkington wrote:  > quoted text
        Attachment:
smime.p7s 
Description: S/MIME cryptographic signature 
  

Ian,

You can also safely ignore this warning.  Although the search field is a single cell, it does have a few sub-elements which are reported to accessibility as children.  The magnifying glass is a button and can be configured to be a popup button that reveals search options or recent searches. [...]

Ian,

You can safely ignore these warnings.

The first warning is for a private attribute that Accessibility Verifier seemingly doesn't know about yet, so it reports it is unexpected.

The second warning may simply be an issue with the Services menu.  I am seeing those same verification errors running the verifier on TextEdit, so it looks like it is either an issue with the verifier or with the Services menu.

Please file a bug for each of these two issues at bugreporter.apple.com, including the warning text - bug reports are greatly appreciated.

Thanks,

James

On Nov 1, 2009, at 3:11 PM, Ian Piper wrote:

[...]


 

Have you filed a bug for this issue?  If not, please do so at bugreporter.apple.com.     Thanks,     James       On Nov 1, 2009, at 1:32 AM, Tomas Zahradnicky wrote:   Hi Martin,    I've faced this problem in the past and finally solved it with the following code. [...]

Hi all,  
I have come across another oddity in running the Accessibility  
Verifier. I have a searchfield on the main window of my application,  
and when I run the Verifier I see this warning: 

Fetching all elements (no errors or warnings) 
Parent/Child (no errors or warnings)  [...]

Hi all,  
I am using Accessibility Verifier on a program that I have written. I  
see a message (under the Role Verification section) saying "Unexpected  
extra attribute: AXTextInputMarkedRange". The message is related to a  
TextView control. This first message is followed with a large number   [...]

Hi Martin,    I've faced this problem in the past and finally solved it with the following code. VO ignores the control move and does not refocus the VO cursor to another control. Try this code, it might help you.      void AU_SynchronizeVoiceOverCursorForWindow( WindowRef inWindow )  {      //-------------------------------------------------------------------      //  Theory: In fact, it should be sufficient to just move      //  the control. All standard controls should do the same      //  as Window Manager does when a window moves, that is,      //  broadcast a kAXWindowMovedNotification notification.       //  This kind of notification does not work when the actual      //  window position does not change.      //      //  Current state: Control Manager either does not broadcast      //  kAXMovedNotification or it gets ignored by the VoiceOver.       //        //  Result: VoiceOver cursor overlay does not update.      //      //  To go around paragraph 1 limitation, we really change window      //  bounds and return it quickly back. As a result, VoiceOver      //  cursor sticks the original user element it was above and      //  updates its position.      //      //     Author: T. Zahradnicky      //  Cite this:      //    @inproceedings{1427145,      //      author = {Zahradnick\'{y}, Tom\'{a}\v{s} and L\'{o}rencz, R\'{o}bert and Musil, Pavel},      //      title = {Making ProTools Accessible for Visually Impaired},      //      booktitle = {ICCHP '08: Proceedings of the 11th international conference on Computers Helping People with Special Needs},      //      year = {2008},      //      isbn = {978-3-540-70539-0},      //      pages = {781--788},      //      location = {Linz, Austria},      //      doi = {http://dx.doi.org/10.1007/978-3-540-70540-6_116},      //      publisher = {Springer-Verlag},      //      address = {Berlin, Heidelberg},      //    }          //      //-------------------------------------------------------------------      Rect bounds;         DisableScreenUpdates();      GetWindowBounds( inWindow, kWindowContentRgn, &bounds );      MoveWindow( inWindow, bounds.left-1, bounds.top, FALSE );      MoveWindow( inWindow, bounds.left, bounds.top, FALSE );      EnableScreenUpdates();  }     Best Regards,       Tomas         Le 26 oct. 2009 à 20:56, Martin Pilkington a écrit :   Hi Patti,    After a view slides in, it seems that the VoiceOver cursor still tracks the previously pressed button. As I simply hide the controls after they have moved off screen, doing control-option-left/right will go to the first or last element in the window, so that seems to be another problem (how would you change the selected VO item in code?). But yes, users do have a way to explore the new controls in the window, but it's a case of how do you inform the user there are new controls to explore. To give a better idea of what is going on in the UI I've done a quick screencast of how the system works: http://dropbox.mcubedsw.com/regsystem.mov . As you can see, once the register button is pressed the view changes immediately, but there's only a visual indication that this has happened. And it's worse with the verify button as the change happens some time after the button was clicked, not immediately like with the register button.      The sheet is accessible and can be fully controlled with VoiceOver, but I'm also wanting it to be user friendly, which to VoiceOver users it isn't yet.     Thanks     Martin     (Re-posted due to just hitting reply... stupid mailing list/email client/everything but me)     On 26 Oct 2009, at 6:07 pm, Patti Hoa wrote:   Hi Martin,   If you are using NSView to hide/show the panel, then it would be best to leave it up to AppKit to determine what notifications to send (probably a combination of AX destroyed/created notifications).  In any case, right now VoiceOver is not really listening for any of those notifications.   What happens when you do control-option-left/right arrow after one of the new panel slides in.  Can VO cursor continue to land on the new UIs?  If so, users still have a way to explore the new UIs in the window.   If not, then explain in detail the behavior of VoiceOver interaction after a new panel slides in.     Patti  VoiceOver Engineer     On Oct 26, 2009, at 6:22 AM, Martin Pilkington wrote:  > quoted text

       # Ing. Tomas Zahradnicky, Jr. # Assistant Professor # Department of Computer Systems # Faculty of Information Technologies # The Czech Technical University in Prague       

     Attachment:
smime.p7s 
Description: S/MIME cryptographic signature