## codesigning

Codesigning is one of the worst issues we had been having since we started working on the new Opera for Mac. How Apple managed to screw this up never ceased to amaze us.

Since yesterday morning our build servers started to get CSSMERR_TP_NOT_TRUSTED error while code signing the Mac builds. Well, we didn’t notice until trying to release the new Opera Next build in the afternoon, which is obviously a bad timing. When it happened, immediate reaction was search for it in Google, unfortunately, when it happened words haven’t been spread yet so all results we got were from early 2009 ~ 2011, about some intermediate certificates missing, which completely mislead us. We spent a couple of hours inspecting certificates on all 3 of our Mac buildbot servers, none of them seemed wrong. One of my colleagues tried to resign a package locally with certificates/keys installed, got the same error as well.

Fortunately our build server didn’t get the same error every time so we managed to get a build for release.

When I later did a search for the same keyword but limit the results in last 24 hours, we finally found the real answer to the problem this time. According to this discussion:

Apple timestamp server(s) after all that is the problem here. If I add the --timestamp=none option, codesign always succeeds.

I have exactly the same problem. Probably Apple got two timeservers, with one broken, and a 50% chance for us to reach the working one.

And it worked for us perfectly as well. The only thing I didn’t know was whether it’s safe to release a build without requesting a timestamp (or where can we find other trusted timestamp servers).

This morning I woke up and saw this summary about yesterday’s incident.

According to Allan Odgaard (the author of TextMate):

As long as the key hasn’t expired, there should be no issue with shipping an app without a date stamp, and quite sure I have shipped a few builds without the signed date stamp.

That at least give us some confidence that if such incident happen again, it shouldn’t be a big issue to turn timestamp off.

Update: More explanations from Apple:

The point of cryptographic timestamps is to assist with situations where your key is compromised. You recover from key compromise by asking Apple to revoke your certificate, which will invalidate (as far as code signing and Gatekeeper are concerned) every signature ever made with it unless it has a cryptographic timestamp that proves it was made before you lost control of your key. Every signature that does not have such a timestamp will become invalid upon revocation.

## 浏览器如何渲染文本

#### 解码

1. Web 服务器返回的 HTTP 头中的 Content-Type: text/html; charset= 信息，这一般有最高的优先级；
2. 网页本身 meta header 中的 Content-Type 信息的 charset 部分，对于 HTTP 头未指定编码或者本地文件，一般是这么判断；
3. 假如前两条都没有找到，浏览器菜单里一般允许用户强制指定编码；
4. 部分浏览器 (比如 Firefox) 可以选择编码自动检测功能，使用基于统计的方法判断未定编码。

#### 字体

p { font-family: Helvetica, Arial, sans-serif; }
strong { font-weight: bold; }


<p>A quick brown fox <strong>jumps</strong> over the lazy dog.</p>


<p>一只敏捷的狐狸...</p>


• 是否支持用字体的 PostScript name 选择：如 STHeiti 的 Light 版本又称作 STXihei，或者是否能用 full name 选择：有的浏览器不能正确地将 CSS 里对字体的 font-weight 或者 font-style 等要求映射到特定的字体上，尤其是在字体使用了非标准的 style 命名的情况下，考虑到很多厂商有自己的字体命名规则，这其实很容易出现，像 Helvetica Neue 的 UltraLight, Light, Regular, Medium, Bold 这些不同的 weight，是怎么对应到 CSS font-weight 的 100 到 900 数值上的？这就是特别容易出现 bug 的地方。
• 是否支持按 localized name 选择：比如能不能用 "宋体" 来代表 "SimSun"。以 Mac OS X 下的浏览器为例，Firefox 支持这样的写法，但基于 WebKit 的浏览器一般不支持，这样的问题 CSS 规范没有限定，所以无论哪种情况都是允许的。

CSS3 新增的 @font-face 规则则是对于现有规则的扩展，提供了 web fonts 功能，但字体匹配算法的逻辑并没有改变，详细的算法可以看 CSS 规范里的说明

#### 建议

1. 首先确定要选择字体的元素应该使用的字体风格，比如是衬线字体、非衬线字体还是 cursive、fantasy 之类的；
2. 确定了风格之后，先选择西文字体，优先把平台独特的、在该平台下效果更好的字体写上，比如 Mac OS X 下有 Helvetica 也有 Arial，但 Helvetica (可能) 效果更好，Windows 下则一般只有 Arial，那么写 Helvetica, Arial 就比 Arial, Helvetica 或者只有 Arial 更好；
3. 然后列出中文字体，原则相同，多个平台共有的字体应该尽量放在后边，独有的字体放在前面，还需要照顾到 Mac OS X/Linux 下一般用户习惯用(细)黑体作为默认字体，Windows 下习惯以宋体作为默认字体的情况，比如 STXihei, SimSun 这样的写法比较常见，如果写作 SimSun, STXihei，但 Mac OS X 上装了 SimSun 效果就不会太好看。
4. 最后还是应该放上对应的 generic family，比如 sans-serif 或者 serif
5. 尽量用字体的基本名称 (比如 English locale 下显示的)，而不要用本地化过的名称。除非特殊情况 (Windows 下“某些”浏览器在特定编码下只能支持本地化的字体名称)。Mac OS X 下字体名称可以用 Font Book 查到 (菜单 Preview -> Show Font Info)，Windows 下字体信息在微软的网站可以得到，Linux/X11 下可以使用 fc-list 命令查到。
6. 字体名称中包含空格时记住用引号扩起，比如 "American Typewritter""Myriad Pro"
7. 文档开头最好指明语言，比如 <html lang="zh-CN">，可以使用的语言标记参见 <a href="http://www.w3 pharmacie du viagra.org/International/articles/language-tags/”>W3C 的说明。

## 网页 CJK 竖排的最新进展

• horizontal-tb: 默认情况，从上到下，从左到右的横排书写形式。

• vertical-rl: 块按从右到左排列，文字则从上到下，这是典型的直排情况。

• vertical-lr: 虽然是竖排，但块则从左到右排列。这主要用于内蒙古使用的蒙古语满语

• vertical-right: 默认的情况，将非文本语言的字符 (比如汉字中间嵌入的拉丁字符) 顺时针旋转 90 度，其他字符不变。
• upright: 不旋转上述字符，保持和其他字符一样的方向。(这是目前 WebKit 实现的做法，等于什么都没处理)
• rotate-right: 把所有字符都顺时针旋转 90 度。
• rotate-left: 把所有字符都逆时针旋转 90 度。
• rotate-normal: 在 vertical-rl 书写模式中等于 rotate-right，在 vertical-lr 中等于 rotate-left
• auto: 除了对 SVG1 的 glyph orientation mode 支持以外，其他情况下等于 vertical-right

• none: 不做特殊处理。
• horizontal: 在竖排情况下，首先浏览器应该尝试用对应字体中提供的专门的合并后的字形替代，如果没有，则浏览器可以尝试缩小这些字符以适应宽度，或者放弃合并。效果如图：

## State of The Art Web Typography

We have reached the state that Web typography can be much better than it used to be. What kind of tools is in our hands?

• Hyphenator, with this JavaScript hyphenation support, reading justified text on your browser will no longer be a pain.
• Knuth and Plass Line Breaking in JavaScript, combining this and Hyphenator then you will get beautiful typesetting like this sample.
• optimizeLegibility, CSS rule text-rendering: optimizeLegibility; will turn on cross browser kerning-pairs & ligatures, which is also critical for good typography. It does have some drawbacks though.
• Web fonts solutions like TypeKit and high quality free web fonts from websites like Font Squirrel, provided much more vivid user experience than standard web fonts like Verdana and Georgia, but they should be chosen very carefully, otherwise the results can be much worse.
• -moz-font-feature-settings, this feature, although it’s Firefox 4 only, can be very fun to experiment with, since it opens an entire new world of rich OpenType typography to the web. Combining this with web fonts solutions can make it even more useful.
• -webkit-font-smoothing, when used in a clever way, can improve legibility (and some designers prefer grayscale antialiasing to subpixel antialiasing, that’s why it’s so popular nowadays). Unfortunately there are many existing websites abusing this CSS rule, including Apple and Twitter. In general, I suggest leaving it alone unless it’s absolutely necessary.
• SmartyPants will convert ugly quotes, dashes and consecutive dots into beautiful punctuations that you really meant to use. It saves a lot of editing efforts.
• MathJax, the only weakness of web typography comparing to TeX is math equations, MathJax is so good that it totally eliminated this weakness.

Think about it: what if we create an automatic web typesetting tool, combining all these efforts, how beautiful the result we will get? That’s what I am trying to do recently.

## Web 字体的出路在哪里？

David Berlow:

How important dynamically rendered type is to design and use on the web must now be clear. In addition, the only other option—that the type industry cede its intellectual property to the public without permission—is not going to happen.

There should be a new file extension for this. I propose “.wtf” – “WebType Font”.

… What he fails to mention is that every font-consuming application on every platform on every computer on Earth will need to be “upgraded” to “respect” this permissions table. Because otherwise they’re not really permissions, are they? They’re just useless bits taking valuable chunks out of my metered bandwidth plan. Like the bozo bit without the bozo.

All of the type designers I know desperately want to find a way to enable people to use fonts online, and not just because we’re capitalist stooges, but because we live our lives online.

Truth be told, I don’t know. I feel rather like the physicist who just explained relativity to a group of would-be interstellar travelers, only to be asked: ‘How do you expect us to get to the stars, then?’ I’m sorry, but I don’t know that, either.