Hi, Taco: After my testing the context/experimental with the trunk version of LuaTeX, the memory usage for loading CJK fonts are much lower than before (300MB vs. 850MB on Adobe Songti Std Light, Windows XP), and the loading time is also shorter, too. So thanks a lot for the work! I think many users on the list will be happy too (like Wolfgang, Yanrui Li, Dr. Kim, Longming Wang, etc...) Yue Wang
Yue Wang wrote:
Hi, Taco:
After my testing the context/experimental with the trunk version of LuaTeX, the memory usage for loading CJK fonts are much lower than before (300MB vs. 850MB on Adobe Songti Std Light, Windows XP), and the loading time is also shorter, too. So thanks a lot for the work! I think many users on the list will be happy too (like Wolfgang, Yanrui Li, Dr. Kim, Longming Wang, etc...)
This patch was coded at the KTS meeting in Seoul. As far as I know, it is faster only because there is less swapping involved and/or malloc() is more efficient. The exact same amount of work is done as before. In particular, the glyph boundingboxes are still correctly calculated. Best wishes, Taco
Hi, Taco:
This patch was coded at the KTS meeting in Seoul. As far as I know, it is faster only because there is less swapping involved and/or malloc() is more efficient. The exact same amount of work is done as before. In particular, the glyph boundingboxes are still correctly calculated.
Yes, I know. The bounding boxes are still calculated. Thanks a lot for the patched code and explanation. (and you are also right that less swapping is the real cause for less runtime on my machine,it is the first time that LuaTeX loads big CJK fonts without swapping on my machine). btw, I think the bounding boxes (or control boxes) are useful for CJK languages in some cases. Remember in MKIV Hans wrote a lot of code and set many constant parameters to handle the punctuation compression? These parameters should be font dependent (It will produce ugly result when the font is changed). But in fact we can use the boudningbox information for better calculation. For example, we can compress the "。" and """ by just gluing their bouding boxes. It was difficult to make punctuations like "。" at the end of the line close to the margin line. but now with bounding box information it is also possible. in short, I think we can handle "punctuation compression" and "margin kerning" using the bounding box information.What do you think of this idea, Wolfgang? Yue Wang
Yue Wang wrote:
in short, I think we can handle "punctuation compression" and "margin kerning" using the bounding box information.What do you think of this idea, Wolfgang?
best move that kind of discussions to the context list as it does not related to luatex dev Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
participants (3)
-
Hans Hagen
-
Taco Hoekwater
-
Yue Wang