FileMaker 7: Supports Quartz Text Smoothing – sort of
Posted by Pierre Igot in: MacintoshApril 15th, 2004 • 11:39 pm
The other thing that I noticed in FileMaker Developer 7 right away is that the application finally supports Mac OS X’s Quartz Text Smoothing.
I like Quartz Text Smoothing. I much prefer it to the font anti-aliasing schemes used in previous versions of the Mac OS. And I prefer it to non-anti-aliased text in most situations.
The problem is, of course, that it needs to be implemented properly… I am afraid that this is not the case in FileMaker 7. Take a look at the following two pictures:
The first one is what a FM field looked like in FileMaker 6. The second one is what the same field looks like in FileMaker 7.
What’s the problem? Well, obviously it’s the white smears all around the anti-aliased characters in the line selected in the pop-up list (“Courriel”). It’s positively horrible-looking. I don’t mind a little bit of fuzziness if that’s the drawback of having good-looking text on low-resolution display devices. But the smears are atrocious.
Now, I realize that FileMaker is far from being the only guilty party here. Similar smears can be seen around selected text in various places in numerous other Mac OS X applications, including Microsoft Explorer and Word, MacLinkPlus Deluxe, and, indeed, even some of Apple’s own applications.
There is therefore good reason to suspect that all these applications make use of some code routines in Mac OS X that simply have limited support for Quartz font smoothing and produce rather ugly results with certain combinations of font sizes, font face, and highlighting colour.
Here again, however, one cannot help but wonder what it will take to finally get rid of such problems in Mac OS X applications. If even Apple or its fully-owned subsidiary are not able to update their code so that it takes full advantage of Mac OS X’s built-in features without producing rather unacceptable results from a visual stand point, then how on earth can we expect other developers to fix their products too?
At this rate, Mac OS X and its applications are going to remain stuck in what can only be called a “beta” stage (from the point of view of usability and visual polish) for many years to come… And that’s pretty discouraging.
April 16th, 2004 at Apr 16, 04 | 12:13 am
Yes, first thing I noticed when using the app,
http://www.usercreations.com/weblog/2004/03/09.html#a531
April 16th, 2004 at Apr 16, 04 | 6:55 am
Word X does handle Quartz-smoothed OK – but not Excel X. The smears are definitely there. It’s just basically laziness or carelessness on the part of the developers as far as I can tell. I remember discussing this with the MacLinkPlus Deluxe developer and he admitted that he had been careless about it and said he was going to fix it. It’s been almost a year, though, and I have yet to see an update from DataViz. I guess they just don’t care.
April 16th, 2004 at Apr 16, 04 | 2:26 am
The appearance you show in the screenshot is typical of Carbon apps. As an example, the first Mac OS X Carbon native version of BBEdit (version 6.0, I think) exhibited the same problems with highlighted (selected text). BBEdit version 6.5 and later fixed this problem. So there is a way to do the Quartz text properly with a Carbon app. (Even Microsoft Office v.X apps do it correctly, more or less :-) ). There is apparently more work required, but a proper display of text _is_ achievable in Carbon apps. I am surprised that FileMaker didn’t do its homework, especially given its lineage.
April 16th, 2004 at Apr 16, 04 | 10:47 pm
Right. It is extremely difficult for end users to figure out where the blame lies when something is not working the way it should. Ultimately, we have no choice but to take the developers’ word — or not — when they say it’s Apple’s fault.
What we do have, especially for long-time Mac developers, is a track record. Let’s take, for example, the issue of support for long file names. No matter what excuses Microsoft has, it has taken way too long for them to add support for long file names to Office for the Mac. When they could no longer blame Apple for not providing the API to properly support them, they started blaming their own code, saying that providing such support required that entire portions of the Office code be rewritten.
At this point, the user can either hang his head and cry, or question the quality of Microsoft’s code in the first place. If providing support for long file names, even once Apple has provided the proper API, is so difficult for them to do, what does it say about the quality of their code? Surely they could see that one coming. If memory serves me well, support for long file names was even first introduced in Mac OS 9, many years ago, even before Mac OS X was introduced.
Ultimately, it’s also a question of priorities. Microsoft obviously decided, for example, that it was more important to add support for non-contiguous selection to Office X than to add support for long file names. I know they keep claiming that their user surveys tell them what their users really want… OK, so non-contiguous selection is a nice thing to have (although the fact that it’s poorly implemented in Word X doesn’t really make it such an important feature). But was it really more important than support for long file names?
I know that Microsoft seems to think that they always have to add new features, that only new features are “marketable”. But the track record of companies such as Bare Bones Software shows that it is not true. BB has a history of providing both new features and bug fixes/improvements on a regular basis, often in free of charge updates. When it comes to Microsoft, there are just too many bugs and things that need to be improved that are allowed to remain in the product for years. They don’t seem to think that these improvements/bug fixes are important for end users. They don’t seem to think that such things are “marketable” and therefore worthy of their efforts.
On that basis, it’s hard to always hear from Microsoft representatives that it’s all Apple fault. Even though I am not a Mac software developer, I am sure that it is not a black & white situation.
April 16th, 2004 at Apr 16, 04 | 6:09 pm
The developers probably would argue that the underlying problem belongs to Apple. They _could_ fix the frameworks or libraries, whatever, so that the routines called by Carbon apps work right. I think that the idea was that the Carbon libraries were supposed to effect proper performance under Mac OS 9.x and under Mac OS X so that the developers could get a single app, even a single build, to work under both OSs. But it is clear that Apple has made it quite difficult for developers by making Mac OS X a moving target, and it is reasonable for the developers to be unhappy about having to work harder to do something when it is likely that later versions of Mac OS X will break the workarounds. It is clear here that the NeXT-oriented command-and-control people at Apple still favor the Cocoa way even though some of the developers have written that only the Carbon way affords developers the desired facilities.
On a related issue, it is possible that the mysterious pauses in Word, the lack of directory/folder updates in the Finder, and other things that go bump in the night are due to residual garbage that Apple has failed to fix. It is hard for users to know who is responsible when apps fail to work properly, the developer of the app or the developer of the OS on top of which the app has to run. If the developer has a really high sense of duty and a desire to see the fit-and-finish on his/her app reach a high level, as the people at Barebones do and maybe even the MacBU at Microsoft, he/she is willing to do the extra work to make an app work right despite the underlying problems in the OS. I am sure that sometimes the developer is faced with a difficult decision about how hard to work on the little problems in the face of the cost of delaying the shipping of the app.
Lastly, the main thing that developers say about a preference for developing on the Windows platform (other than the market share of the platform’s audience) is that at least the Windows API is stable. New features are added, but at least the old ones stay in place and continue to work properly. The same cannot be said at this point about the Carbon API’s under Mac OS X. (But we love the platform anyway.)