Recently I’m looking for a way to make [Safari AdBlock](http://burgersoftware.com/en/safariadblock) support Safari in 64-bit.
64-bit apps stopped loading [Input Manager](http://www.cocoadev.com/index.pl?InputManager) bundles, so it is impossible to use [SIMBL](http://www.culater.net/software/SIMBL/SIMBL.php) in 64-bit apps either. Neither does [PlugSuit](http://infinite-labs.net/plugsuit/) (which is using [mach_inject](http://rentzsch.com/mach_inject/)). The [web plugin solution](http://www.switchersblog.com/2007/08/the-end-of-th-2.html) suggested by 1Password team stopped working too. Frankly, I think it’s time to start looking for a better code injection technique for 64-bit Snow Leopard apps seriously.
What still works?
1. [Scripting Additions](http://developer.apple.com/technotes/tn/tn1164.html), it’s what 1Password using for all its plugins (for Safari, WebKit, Camino, NetNewsWire, etc.), basically it works for all apps that support Apple Scripts, but the problem is you’ll need to run a daemon to watch the launch of these apps, then send a custom Apple event to trigger the initialization of the code you inject.
2. Use a DYLD constructor as initialization point, then use `DYLD_INSERT_LIBRARIES` or techniques described [in this faq](http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html) to trigger the load of this bundle or dynamic library. The problem is you will need all the users to modify their environment variables, which is cumbersome.
Is there any other solution? I’ll be glad to hear.
**Update**: CWS provided a solution in comment: opening Terminal and entering `defaults -currentHost write -globalDomain AppleFontSmoothing -int 2`, after re-login, everything is back to normal again!
**Update**: Turns out the problem is not just from Dell, various 3rd party display manufactures including Samsung, LG, HP and EIZO also have the same issue.
—
A very tricky issue has been bothering me for a few months: in Snow Leopard, whenever I connected my [Dell 2408WFP](http://is.gd/2lYr1) monitor, every app launched after that will have [sub-pixel antialiasing](http://en.wikipedia.org/wiki/Subpixel_rendering) (aka. LCD Font Smoothing) **disabled**.
For a typography freak like me, it is a huge disaster.
The full story comes in two parts:
1. Prior versions of Mac OS X used to have this “Font smoothing style” option in System Preferences -> Appearances, it is not as complete as [fontconfig](http://www.fontconfig.org). But good enough for general public. A very unfortunate thing [I covered about a few months ago](/2009/03/17/snow-leopard-font-related-changes/) is, they simplified that option to a checkbox: Use LCD font smoothing when available.
in Leopardin Snow Leopard
2. But how did Snow Leopard determine whether it is “available”? It relies from information retrieved from the driver of the display. Let’s say if you have ten displays connected, and one of them is a CRT display instead of LCD, then all the applications in your system will **not** be able to use LCD font smoothing. Here comes the epic fail: Dell 2408WFP (and Dell 3008WFP, AFAIK), a perfectly fine LCD display, is **not** recognized as one by Mac OS X (both Leopard and Snow Leopard have this issue, I haven’t check earlier versions).
(Though my Dell 2408WFP is not recorgnized as a LCD display in Leopard, I can force sub-pixel rendering with the “Font smoothing style” option.)
With the combination of these two problems, I’m stucked. Either I can give up Snow Leopard or get a new display. But I simply don’t have enough space on my desk for another display. (And I really happy with the Dell 2408WFP, it works with all other devices: Xbox 360, Wii, PS2, etc., so I won’t abandon it for an [Apple LED Cinema Display](http://www.apple.com/displays/) for apparent reasons.)
This morning I just got a reply for my bug report from Apple Developer Connection, it said:
Thank you for contacting us regarding Bug ID# 6975903. The report you have submitted has been determined by engineering to be an issue with LDC Display. Please know that we are doing our best to inform Dell of the issue with the hope that they can implement the necessary changes. Please feel free to contact them regarding this issue to help alert them of its importance.
I felt even more desperate after receiving this. Because it seemed too rare that Apple (and Dell) won’t even care to fix. And since I have little knowledge about why and what need to be fixed from Dell, it will be really hard for me to push Dell on this issue.
To be honest, what I’m asking is pretty simple: if we cannot get back the original font smoothing level option, **at least give us a hidden preference item to turn on LCD font smoothing**, that won’t hurt the usability of Snow Leopard, right?
I’m pleased to announce vim-cocoa 0.3 is released. The main update is it now have full Mac OS X 10.6 support.
### What’s New?
#### 0.3.2
* Fix frame height calculation when GUI tabline is enabled
* Add back missing helptags
#### 0.3.1
* Fix crashing on loading non-UTF-8 menu translations (reported by ducksteven and dyroro)
* Fix delayed refreshing (reported by fishy)
#### 0.3
* Update vim to 7.2.245
* **Rewrote** part of the rendering process to increase performance, especially on Mac OS X 10.6
* Add clipboard support for console mode (running without `-g`)
* Use cmake to support out-of-directory build, see [BuildInstructions](http://code.google.com/p/vim-cocoa/wiki/BuildInstructions) for detail
* Build with `+ruby` and `+cscope` by default
A few months ago, I’ve covered font related changes in Snow Leopard in [this post](http://blog.jjgod.org/2009/03/17/snow-leopard-font-related-changes/), that was perceived from developer preview build 10A286, after I got build 10A335 and 10A354, several changes can be observed.
1. Heiti SC and Heiti TC we covered earlier are now used as the default fallback fonts for Simplified Chinese and Traditional Chinese, respectively. We can see this via the content of the default font fallback configuration file of [Core Text](http://en.wikipedia.org/wiki/Core_Text):
2. “**Menlo**”, the monospaced font we mentioned previously, are apparently used as the default coding font for Xcode 3.2 now. Apple even filed a couple of trademark registrations in [US](http://tarr.uspto.gov/tarr?regser=serial&entry=77-745991+&action=Request+Status) and [EU](http://www.macnn.com/blogs/2009/06/01/823.html) for that name.
Menlo Regular in Xcode 3.2
Personally, I still prefer the good-old-Monaco.
3. A pair of new Chinese OpenType fonts called **Hiragino Sans GB** and **Hiragino Sans CNS** have been added into recent builds, for Simplified Chinese and Traditional Chinese, respectively. Both fonts have two widths: W3 and W6.
Hiragino Sans GB W3Hiragino Sans GB W6Hiragino Sans GB W3
These fonts were [announced](http://www.screen.co.jp/ga_product/sento/press/MP_NL081118E.pdf) by Dainippon Screen Mfg. Co., Ltd., they are specifically designed for Chinese users, but in a traditional Japanese Kanji style. These fonts can be seen as “sans-serif” fonts (hence the name) or “Gothic” fonts in Japanese term, or “heiti” in Chinese term.
However, Hiragino Sans CNS, the font family for traditional Chinese appeared in 10A335 is removed suspiciously in 10A354. I wonder if Apple will added it back in the official release.
For comparision, Microsoft licensed a pair of Chinese fonts called “[Microsoft Yahei](http://en.wikipedia.org/wiki/Microsoft_YaHei)” and “[Microsoft Jhenghei](http://www.microsoft.com/typography/fonts/family.aspx?FID=368)” in Windows Vista, which are somewhat similar to Hiragino Sans fonts, at least to my eyes.
3. iPhone OS 中使用的混合简繁中日韩语言版本的 (华文) 黑体出现在 Snow Leopard 中，一个 `/System/Library/Fonts/STHeiti Light.ttc` 文件对应了 Heiti SC, Heiti TC, Heiti J 和 Heiti K 这四套字体。
4. 新增修改自 [Bitstream Vera Sans Mono](http://www.bitstream.com/font_rendering/products/dev_fonts/vera.html) 的新等宽字体 Menlo (这个名字大概是来自 [Menlo Park](http://is.gd/nDN8))，提供 Regular, Italic, Bold, Bold Italic 四种风格。
