On Tue, May 12, 2009 at 10:50 PM, Hans Hagen <pra...@wxs.nl> wrote: > Yue Wang wrote: >> >> On Tue, May 12, 2009 at 8:54 PM, Hans Hagen <pra...@wxs.nl> wrote: >>> >>> Yue Wang wrote: >>> >>> >>>> moreover, can you tell me why pdftex load these fonts so fast? (also 6 >>>> families * 3 sizes) >>> >>> i don't know; as the same code is used so it must be xetex itself then >> >> Then let me tell you why: ConTeXt tries to load lmmono10-regular at >> least 6 times, failed after two testing, then succeed in the end. >> However, try to testing whether a loaded font is \nullfont or not is >> quite slow in XeTeX (Jonathan already mentioned that in >> \testFontIsAvailable). we should definately avoid that. >> But why pdftex is so fast? because it does not involve font testing. >> >> So why XeTeX is spending 6 seconds aimlessly? since ConTeXt asked it >> to search for a non-existed font. > > well, even locating a font 6 times should be no big deal >
loading 6 fonts, each fonts will be scanned for 3 times. so there are 18 searching. 12 of them are fc searches, and these are quite slow. > btw, you can try to change the following into > > \def\defaultfontfile{file:lmmono10-regular} > After changing like this, XeTeX runs like a blink. (It wasted 6 seconds for each compile. now it won't) > but even then ... if that one is used then there is something else going on > so best find out what happens ... in context we can have 4 extra math > families and in most cases only two are used (MathAlpha and MathBeta) while > (just in onder to catch errors) MathGamma etc then automatically will > trigger the default font to be used (other approached would demand more > definitions at the user end and/or a more low level implementation); the > only optimization i can imagine is more clever sharing of the default font > but as in other cases one expects the default to be properly scaled it not > that simple; after all, users also expect proper error recovery (and in many > cases missing some specific fonts is no real problem until it's used); so, > you can hardly blame context for the fact that xetex has a certain logix on > locating fonts that happens to be not that good a match for context > > The fact that xetex uses this mixture of "" en [] does not help either as > context uses [] itself so parsing is somewhat complicated (the file/name > prefix was introduced to circumvent this problem); > > 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 > ----------------------------------------------------------------- > ___________________________________________________________________________________ > If your question is of interest to others as well, please add an entry to > the Wiki! > > maillist : ntg-context@ntg.nl / > http://www.ntg.nl/mailman/listinfo/ntg-context > webpage : http://www.pragma-ade.nl / http://tex.aanhet.net > archive : https://foundry.supelec.fr/projects/contextrev/ > wiki : http://contextgarden.net > ___________________________________________________________________________________ > ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : https://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________