我也想让你看到，但是要给我发工资的人同意才行啊:-)
目前在处理网页上浮动窗口飘动的问题, 这个patch好像可以开放。但愿如此吧。
共创2005那边有什么问题，我不清楚。我的职责范围也仅限于Browser。
我可以负责的说。在我负责的范围内,没有因为我们自己的改动导致任何一个新的Mozilla的Bug.
到不知道是谁要上纲上线，把事情扯到公司上的。
不写或者少些代码就永远不会引起BUG。
玩笑:-D
改动引起BUG是必然的，我的态度恰恰跟你相反，我鼓励dirty hack。
Linux本身就是充满dirty hack的东西，你比较幸运，作的是mozilla，有机会去看看kde/gnome。你会发现太多让你无法理解的代码。
顺便说一句，上面的那一段dirty hack我认为很OK。
:-) 果然和我预想的是一样，wine在magic和红旗显示的效果近乎相同，这可能是首先归功于cjacker原来在X方面打的补丁吧，因为magic的X里的字体显示应该是经过修改的(也就是打过补丁的)，cjacker把这个带到了红旗去，所以显示效果是和magic一样的(1.1之前的版本，包括1.1)，并且从显示效果上看是有所美观，最主要的是kde桌面的阴影于字体的距离应该是有所修改，才会修改的如此美观，嗯，这个应该是和suse一样的吧 :-)
我也想让你看到，但是要给我发工资的人同意才行啊:-)
目前在处理网页上浮动窗口飘动的问题, 这个patch好像可以开放。但愿如此吧。
document.scrollTop
document.clientWidth
document.clientHeight
document.offsetHeigh
document.offsetWidth
Mozilla做的是对的，IE做的是错的，你如果改动的OK了，那么你就写了一堆错误的代码。
这是不是dirty hack?
呵呵，算了，不跟你吵了。有时间还是聊聊技术吧。
HFONT hFont = 0;
+ LOGFONTW tmp;
+ memcpy(&tmp,plf,sizeof(LOGFONTW));
+ plf=&tmp;
+ if(plf->lfHeight>=0 && plf->lfHeight<12)
+ plf->lfHeight=12;
+ else if(plf->lfHeight<0 && plf->lfHeight>-12)
+ plf->lfHeight=-12;
-
赎我驽钝，实在看不出这段代码有什么问题，也不知道这和对C/汇编的理解有什么关联，
要有人真认为有关联，可以把自认为更高效东西帖出来，
然后看看反汇编的代码，捭捭指头数数指令周期，给大家分析分析。
另外，本人是抱着求实的态度来的看看的，不想贬低任何人，只想就事论事。
1、注意参数，const。这导致某些编译器无法正常编译。plf=&tmp;
2、中间出现了Magic number，影响了系统的配置性(BTW: wine原来的代码也是如此，在wine里，应该倒也不算什么)
3、条件判断的算法还可以优化
4、直接使用试错法，没有仔细寻找发生问题的本质，不具有可重复性。
还有很多地方的条件判断等地方可以优化
HFONT hFont = 0;
+ LOGFONTW tmp;
+ memcpy(&tmp,plf,sizeof(LOGFONTW));
+ plf=&tmp;
+ if(plf->lfHeight>=0 && plf->lfHeight<12)
+ plf->lfHeight=12;
+ else if(plf->lfHeight<0 && plf->lfHeight>-12)
+ plf->lfHeight=-12;
-
赎我驽钝，实在看不出这段代码有什么问题，也不知道这和对C/汇编的理解有什么关联，
要有人真认为有关联，可以把自认为更高效东西帖出来，
然后看看反汇编的代码，捭捭指头数数指令周期，给大家分析分析。
另外，本人是抱着求实的态度来的看看的，不想贬低任何人，只想就事论事。
1、注意参数，const。这导致某些编译器无法正常编译。plf=&tmp;
2、中间出现了Magic number，影响了系统的配置性(BTW: wine原来的代码也是如此，在wine里，应该倒也不算什么)
3、条件判断的算法还可以优化
4、直接使用试错法，没有仔细寻找发生问题的本质，不具有可重复性。
还有很多地方的条件判断等地方可以优化
这段代码目标非常的明确，小于12号字体作12号处理，这么简单的任务，要根据实际情况配置资源，你有多少人，允许你在这么一个小的问题投入？
此外，如果将wine作为一个重点去做，这个方向本身就是错的。
:-) 果然和我预想的是一样，wine在magic和红旗显示的效果近乎相同，这可能是首先归功于cjacker原来在X方面打的补丁吧，因为magic的X里的字体显示应该是经过修改的(也就是打过补丁的)，cjacker把这个带到了红旗去，所以显示效果是和magic一样的(1.1之前的版本，包括1.1)，并且从显示效果上看是有所美观，最主要的是kde桌面的阴影于字体的距离应该是有所修改，才会修改的如此美观，嗯，这个应该是和suse一样的吧 :-)
显示补丁是firefly的。
至于wine的显示，其实是参数问题。
我们讨论的跟这些没有关系:-D
我也认为wine不是一个重点，但是看到运行一些多媒体程序不需要重起机器。我个人觉得很好玩而已。Just for fun ;-)
已经该了一年多Mozilla了，想换口气，看看别的开源项目。呵呵。
至于公司资源上的安排，那不好说。我只是觉得，软件是美的，任何改动都不应该破坏这种架构的美感。（当然这个case还谈不上架构）。
HFONT hFont = 0;
+ LOGFONTW tmp;
+ memcpy(&tmp,plf,sizeof(LOGFONTW));
+ plf=&tmp;
+ if(plf->lfHeight>=0 && plf->lfHeight<12)
+ plf->lfHeight=12;
+ else if(plf->lfHeight<0 && plf->lfHeight>-12)
+ plf->lfHeight=-12;
-
赎我驽钝，实在看不出这段代码有什么问题，也不知道这和对C/汇编的理解有什么关联，
要有人真认为有关联，可以把自认为更高效东西帖出来，
然后看看反汇编的代码，捭捭指头数数指令周期，给大家分析分析。
另外，本人是抱着求实的态度来的看看的，不想贬低任何人，只想就事论事。
1、注意参数，const。这导致某些编译器无法正常编译。plf=&tmp;
2、中间出现了Magic number，影响了系统的配置性(BTW: wine原来的代码也是如此，在wine里，应该倒也不算什么)
3、条件判断的算法还可以优化
4、直接使用试错法，没有仔细寻找发生问题的本质，不具有可重复性。
还有很多地方的条件判断等地方可以优化
1.晕啊，一个const T*的指针居然不能指向一个T*的对象？基本常识啊。
真是那样的话，C/C++库中那么多const char*参数的函数用起来岂不是都要先要强制转换了？
2.Magic Number在任何地方也不少见，非要先定义一个Macro，再写一大堆说明？
3. 不否认可以做一点点优化，但是不知道想破头皮，极尽hack之能事以后可以缩短几个CPU ticks? 反之，代码清晰程度上还有比这样写更能体现作者意图的吗？
4. 这就不争了，和windows用的字体不同，这就是本质。就是height 就是12效果最好，linux字体小了不好看，文档里一句话就完了。再者，呵呵，我认为可不可复用似乎看的不是一两行代码，多半取决于设计罢。
就说这些吧，代码或许谈不上优雅，不过也看不出ugly或者过多影响效率之处。
哦，关于第一点有点补充，
阁下是不是对const T*和T *const的概念有些不太清楚，
如果声明是LOGFONTW *const plf就是你说的情况了，不过那样的话，也不是某些编译器，不作强制转换是任何符合规范的编译器通不过的。
确实，上面的方法验证过。在VC和老版的gcc上都可以正常通过编译。是我这个地方记混了。
另再gcc-3.3.3上无法通过编译。对不起，实在是没有见过这么用的。这是我的失误。
这段代码在性能上没什么，不过其他一些代码慢着n倍，相信不是为了代码清晰而写的吧。
哥们，看来咱们两对C/C++,汇编的理解还是不够啊
我觉得这样不会慢， 要比较就用汇编级别的。
2、中间出现了Magic number，影响了系统的配置性(BTW: wine原来的代码也是如此，在wine里，应该倒也不算什么)
使我想起了一句话：在中国程序员考虑如何优化数据存储而绞尽脑汁的时候，印度程序员用一个多维数组解决了这个问题。有人问为什么不进行优化呢？回答原因很简单：现在的机器性能都比较高，根本没有必要节约这种成本。
哥们，看来咱们两对C/C++,汇编的理解还是不够啊
呵呵，难免的错误。谁又敢说自己精通C/C++啊。（不过有些丢人了:-(）
另，这个地方的代码没有必要用strlen。:-)
if (l_data.charset != NULL && strlen(l_data.charset) > 0) {
+ strcat(lang_string, ".");
+ strcat(lang_string, l_data.charset);
+ }
其实整个lang_string全是调试用的，可以不加。