Re: Cocoa text rendering and setUsesScreenFonts: ATSUI? QuickDraw? Something else?
Re: Cocoa text rendering and setUsesScreenFonts: ATSUI? QuickDraw? Something else?
- Subject: Re: Cocoa text rendering and setUsesScreenFonts: ATSUI? QuickDraw? Something else?
- From: Evan Jones <email@hidden>
- Date: Thu, 10 Apr 2003 15:24:41 -0400
On Thursday, Apr 10, 2003, at 14:36 US/Eastern, Douglas Davidson wrote:
What does [NSLayoutManager setUsesScreenFonts] do to get "screen
fonts"? Does it change the ATSUI drawing settings? Does it draw with
QuickDraw instead of Quartz? Is it actually selecting alternate fonts
using ATS? It is in cases like this that I wish Apple would release
the code for Cocoa, so I could answer this question myself.
It selects alternate fonts, using the -[NSFont screenFont] method.
Okay, that makes sense. Unfortunately, it doesn't seem that is the
entire answer. I tested a quick hack below to use this Cocoa class to
find my font which I then draw with using ATSUI. It doesn't appear to
be the answer to my problem.
ATSUFindFontFromName( "Monaco", 6, kFontFullName, (unsigned)
kFontNoPlatform, kFontRomanScript, (unsigned) kFontNoLanguage, &fontid
);
NSString* fontName = @"Monaco";
NSFont* font = [NSFont fontWithName: fontName size: 10];
assert( font != nil );
NSFont* screenFont = [font screenFont];
assert( screenFont != nil );
// When I execute this line, my font id and the NSFont's font id have
the same value
// I found this private _atsFontID method using RuntimeBrowser
// When I use ATSUI to draw with this font, I get the same output as
before: Antialiased
// Monaco 10, instead of Project Builder's nice un-antialiased Monaco
10.
fprintf( stderr, "My id = %p NSFont's id = %p\n", fontid, [screenFont
_atsFontID] );
fontid = [screenFont _atsFontID];
So my question is still: What does this class do, or does Cocoa's text
rendering system do, to get "screen fonts". There was a mention of this
issue in David Hyatt's weblog (Safari development) that sheds some
light on this issue:
http://www.mozillazine.org/weblogs/hyatt/archives/2003_03.html
(1) Safari *is* using the wrong fonts for rendering to the screen.
Because of our use of lower-level APIs, we missed out on a font
substitution step that happens when rendering to the screen where the
bitmap font ends up getting chosen for rendering. This is a bug in
Safari, and we're looking into fixing it.
(2) The global OS AA setting is not being obeyed.
(3) Above and beyond the OS AA setting, AppKit also has hardcoded rules
at a higher level, e.g., don't AA Courier or Monaco. Again we are
missing these hardcoded rules.
My problem appears to be exactly the same, as I am doing the same
thing: Using the lower level ATSUI APIs for drawing Unicode strings.
I'm not surprised about #3. But interestingly, it doesn't ALWAYS turn
off antialiasing: Only for Monaco at 10 points or less. If you make it
12 points, it is AAed again, and looks the same (more or less) as my
text. So I would say that Apple needs to expose these hard coded rules
to ATSUI/Carbon somehow, to provide a consistent user experience.
And then later:
We have successfully switched to selecting the appropriate fonts when
rendering to the screen (vs. rendering to a printer). Safari still
antialiases everything, but at least the same fonts are being chosen as
with other Cocoa apps that use AppKit.
So what was this fix? It would be nice to know, if possible. Maybe I'll
email him, and see if he can tell me. At any rate, I've wasted FAR too
much time on this now. I'm going to live with antialiased text, even if
in some cases it isn't as nice.
Thanks for your assistance.
--
Evan Jones:
http://www.eng.uwaterloo.ca/~ejones/
"Computers are useless. They can only give answers" - Pablo Picasso
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.