关于Wine里显示清晰中文字体的方法

nzinfo

我也想让你看到，但是要给我发工资的人同意才行啊:-)

目前在处理网页上浮动窗口飘动的问题, 这个patch好像可以开放。但愿如此吧。

cjacker

[quote:3075fab1da="nzinfo"]共创2005那边有什么问题，我不清楚。我的职责范围也仅限于Browser。
我可以负责的说。在我负责的范围内,没有因为我们自己的改动导致任何一个新的Mozilla的Bug.

到不知道是谁要上纲上线，把事情扯到公司上的。[/quote]

不写或者少些代码就永远不会引起BUG。
玩笑

改动引起BUG是必然的，我的态度恰恰跟你相反，我鼓励dirty hack。

Linux本身就是充满dirty hack的东西，你比较幸运，作的是mozilla，有机会去看看kde/gnome。你会发现太多让你无法理解的代码。

顺便说一句，上面的那一段dirty hack我认为很OK。

caihua

:-) 果然和我预想的是一样，wine在magic和红旗显示的效果近乎相同，这可能是首先归功于cjacker原来在X方面打的补丁吧，因为magic的X里的字体显示应该是经过修改的(也就是打过补丁的)，cjacker把这个带到了红旗去，所以显示效果是和magic一样的(1.1之前的版本，包括1.1)，并且从显示效果上看是有所美观，最主要的是kde桌面的阴影于字体的距离应该是有所修改，才会修改的如此美观，嗯，这个应该是和suse一样的吧 :-)

cjacker

[quote:3f0162346a="nzinfo"]我也想让你看到，但是要给我发工资的人同意才行啊:-)

目前在处理网页上浮动窗口飘动的问题, 这个patch好像可以开放。但愿如此吧。[/quote]

document.scrollTop
document.clientWidth
document.clientHeight
document.offsetHeigh
document.offsetWidth

Mozilla做的是对的，IE做的是错的，你如果改动的OK了，那么你就写了一堆错误的代码。

这是不是dirty hack?

呵呵，算了，不跟你吵了。有时间还是聊聊技术吧。

nzinfo

[quote:db4c2fb6fd="Pentium8250"]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/汇编的理解有什么关联，
要有人真认为有关联，可以把自认为更高效东西帖出来，
然后看看反汇编的代码，捭捭指头数数指令周期，给大家分析分析。
另外，本人是抱着求实的态度来的看看的，不想贬低任何人，只想就事论事。[/quote]
1、注意参数，const。这导致某些编译器无法正常编译。plf=&tmp;
2、中间出现了Magic number，影响了系统的配置性(BTW: wine原来的代码也是如此，在wine里，应该倒也不算什么)
3、条件判断的算法还可以优化
4、直接使用试错法，没有仔细寻找发生问题的本质，不具有可重复性。
还有很多地方的条件判断等地方可以优化

cjacker

[quote:da7bba99c4="nzinfo"][quote:da7bba99c4="Pentium8250"]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/汇编的理解有什么关联，
要有人真认为有关联，可以把自认为更高效东西帖出来，
然后看看反汇编的代码，捭捭指头数数指令周期，给大家分析分析。
另外，本人是抱着求实的态度来的看看的，不想贬低任何人，只想就事论事。[/quote]
1、注意参数，const。这导致某些编译器无法正常编译。plf=&tmp;
2、中间出现了Magic number，影响了系统的配置性(BTW: wine原来的代码也是如此，在wine里，应该倒也不算什么)
3、条件判断的算法还可以优化
4、直接使用试错法，没有仔细寻找发生问题的本质，不具有可重复性。
还有很多地方的条件判断等地方可以优化[/quote]

这段代码目标非常的明确，小于12号字体作12号处理，这么简单的任务，要根据实际情况配置资源，你有多少人，允许你在这么一个小的问题投入？

此外，如果将wine作为一个重点去做，这个方向本身就是错的。

cjacker

[quote:2f923a9aa8="caihua"]:-) 果然和我预想的是一样，wine在magic和红旗显示的效果近乎相同，这可能是首先归功于cjacker原来在X方面打的补丁吧，因为magic的X里的字体显示应该是经过修改的(也就是打过补丁的)，cjacker把这个带到了红旗去，所以显示效果是和magic一样的(1.1之前的版本，包括1.1)，并且从显示效果上看是有所美观，最主要的是kde桌面的阴影于字体的距离应该是有所修改，才会修改的如此美观，嗯，这个应该是和suse一样的吧 :-)[/quote]

显示补丁是firefly的。
至于wine的显示，其实是参数问题。
我们讨论的跟这些没有关系

nzinfo

我也认为wine不是一个重点，但是看到运行一些多媒体程序不需要重起机器。我个人觉得很好玩而已。Just for fun ;-)

已经该了一年多Mozilla了，想换口气，看看别的开源项目。呵呵。

至于公司资源上的安排，那不好说。我只是觉得，软件是美的，任何改动都不应该破坏这种架构的美感。（当然这个case还谈不上架构）。

Pentium8250

[quote:7a6de5a02a="nzinfo"][quote:7a6de5a02a="Pentium8250"]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/汇编的理解有什么关联，
要有人真认为有关联，可以把自认为更高效东西帖出来，
然后看看反汇编的代码，捭捭指头数数指令周期，给大家分析分析。
另外，本人是抱着求实的态度来的看看的，不想贬低任何人，只想就事论事。[/quote]
1、注意参数，const。这导致某些编译器无法正常编译。plf=&tmp;

2、中间出现了Magic number，影响了系统的配置性(BTW: wine原来的代码也是如此，在wine里，应该倒也不算什么)

3、条件判断的算法还可以优化

4、直接使用试错法，没有仔细寻找发生问题的本质，不具有可重复性。
还有很多地方的条件判断等地方可以优化[/quote]

1.晕啊，一个const T*的指针居然不能指向一个T*的对象？基本常识啊。
真是那样的话，C/C++库中那么多const char*参数的函数用起来岂不是都要先要强制转换了？

2.Magic Number在任何地方也不少见，非要先定义一个Macro，再写一大堆说明？

3. 不否认可以做一点点优化，但是不知道想破头皮，极尽hack之能事以后可以缩短几个CPU ticks? 反之，代码清晰程度上还有比这样写更能体现作者意图的吗？

4. 这就不争了，和windows用的字体不同，这就是本质。就是height 就是12效果最好，linux字体小了不好看，文档里一句话就完了。再者，呵呵，我认为可不可复用似乎看的不是一两行代码，多半取决于设计罢。

就说这些吧，代码或许谈不上优雅，不过也看不出ugly或者过多影响效率之处。

Pentium8250

哦，关于第一点有点补充，
阁下是不是对const T*和T *const的概念有些不太清楚，
如果声明是LOGFONTW *const plf就是你说的情况了，不过那样的话，也不是某些编译器，不作强制转换是任何符合规范的编译器通不过的。

nzinfo

确实，上面的方法验证过。在VC和老版的gcc上都可以正常通过编译。是我这个地方记混了。
另再gcc-3.3.3上无法通过编译。对不起，实在是没有见过这么用的。这是我的失误。

这段代码在性能上没什么，不过其他一些代码慢着n倍，相信不是为了代码清晰而写的吧。

cjacker

哥们，看来咱们两对C/C++,汇编的理解还是不够啊

sunmoon1997

我觉得这样不会慢， 要比较就用汇编级别的。

jiangtao9999

2、中间出现了Magic number，影响了系统的配置性(BTW: wine原来的代码也是如此，在wine里，应该倒也不算什么)

使我想起了一句话：在中国程序员考虑如何优化数据存储而绞尽脑汁的时候，印度程序员用一个多维数组解决了这个问题。有人问为什么不进行优化呢？回答原因很简单：现在的机器性能都比较高，根本没有必要节约这种成本。

nzinfo

[quote:c5bfb50e52="cjacker"]哥们，看来咱们两对C/C++,汇编的理解还是不够啊[/quote]
呵呵，难免的错误。谁又敢说自己精通C/C++啊。（不过有些丢人了:-(）
另，这个地方的代码没有必要用strlen。:-)

if (l_data.charset != NULL && strlen(l_data.charset) > 0) {
+           strcat(lang_string, ".");
+           strcat(lang_string, l_data.charset);
+   }

其实整个lang_string全是调试用的，可以不加。