hozuki

1. Layout！Layout！ 2. 边缘模式下绘制的字体和普通模式下的本体边界并不对齐。 3. 字体边缘像素透明度信息丢失。 关于第一点现在以`pt`为单位近似计算文字高度，效果还不错（中英文），应该是因为字体还算规整吧。 第二点和第三点……想办法ing。我现在的方案是canvas绘制文字后作为纹理绘制到上下文，因而有这两个问题。 唉，此issue出现各种高中大神……

大概遵照默认的“非零=true，0=false”？可能某些设置以后会引入级别（如阴影浓度）？这个设计倒是没问题，但是文档中最好给出 `bool` 的转换标准。

所以需要确定转换行为。 关于浓度这样可分级的参数，可能也需要考虑实现来确定接受的类型。text-shadow（实际不能调整浓度，只能调整距离，囧）、伪元素、GLSL shader 的允许值都不是[0,1]的。所以也要规定…… 其他的类似参数，`bold` 对应的 font-weight 可以做到可调，也可以统一用 `font-weight: bold`。借鉴过来，`textShadow` 如果设为 bool 也可以将 offset 值统一。

我认为用屏幕宽度作为单位是可以的，但是要基于这样的假设： 1. 视频大多是landscape的，无论是16:9还是4:3； 2. 压制成的视频统一被缩放到16:9； 3. 播放器设置为4:3时，弹幕仍然按照16:9的比例绘制（忽略播放器宽高比设置）。 用父对象的高度作为单位仍然没有解决portrait和landscape的问题。而且在portrait时还会造成视频很小而弹幕很大的问题。自然，一般用户不会将视频锁定为landscape的情况下，看着portrait的弹幕（示意图如下）。 

我查了一下（以前还真没注意相关的概念），如果是网页，实际获取的只能是viewport的宽度而不是屏幕物理宽度。你说的“带刘海”这样的特征，是针对物理宽度的。 一定要大小相近，那就只好都用物理长度了。 我想的是根据像素宽度等比缩放。这么做，如果viewport的尺寸映射是正确的话，手机上应该正常（比如小屏幕的iPhone），但在PC端大屏上可能会出问题。后一种情况我还没想好对策。

I created a Nemerle project and added a macro using macro wizard. However the generated code contains too much redundancy ("generated code contains code that obviously doesn't appear in the...

Well I got it. Since the tutorial didn't mention it, and Nemerle is known as a meta-programming language, I thought macros feature is included in the Nemerle runtime (i.e. `Nemerle.dll`)...

Sorry it still doesn't get fixed. (`using Nemerle.Macros;` is not necessary) The IntelliSense does not prompt anything in the macro definition now. (There used to be "unbound names" errors.) But...

Thanks for the reply. My point is not about IntelliSense, but a inconsistency between IntelliSense and the compiler, on the same piece of code. Reading the tutorial again, the assembly...

If you didn't reference `Nemerle.Compiler` or `Nemerle.Macros` (not suggested), IntelliSense will at least throw an error at the `macro` keyword ("unbound name 'IMacro'"). That's why I think whether IntelliSense prompts...