I file this bug because I see some improvement opportunity from bug 100324. We could do better than that if we take the unicode asian width database. we can take http://www.unicode.org/Public/3.1-Update1/EastAsianWidth-5.txt and cacular width depend on the unicode property ( half width for non CJK, full width for CJK , zero width for combining mark. read http://www.unicode.org/unicode/reports/tr11/ for details. jshin@pantheon.yale.edu and kataki, can you work on that ?

Wow, I am lost?????? What is the bug here? Unfuture if you want me to take a look again.

The issue is when we try to measure the width of string on PostScript code, we may not have enough information from the AFM because the AFM may not include those character. The current code do a estimation and make all character > Unicode U+0100 as a fix number 1056?? Somehow that number is good for Chinese/Korean/Japanese because they are usually double width as a ASCII character. However, that make Cyrillic/Greak pagek look funky since we reserved too many space here. Also, there are some character are ZERO-width such as vowel sign or combining mark for some language. So a better way to estimate it is to base on unicode character data base and estimate 1056 for those character in the CJK area, estimate about 600 to those character in Alphabatic writting ssytem. and estimate 0 for those character we know are control code or zero-width. I take this bug back since I don't think you should own it. I will put on the future list and wait for other contributor to pick it up.

Would this help with bug 40130?

push off for future project.

Mass-resolving some bugs related to the old unix printing system. The old code has been removed from the tree, and the bugs don't occur with the cairo-based printing code.