Re: [NTG-context] XeConTeXt bug report I: strange benchmark
I can confirm that I am wrong.
2009/5/13 Yue Wang yuleo...@gmail.com:
Hi, Hans:
On Tue, May 12, 2009 at 11:22 PM, Hans Hagen pra...@wxs.nl wrote:
\setupbodyfont[myzhfont] \dorecurse{1}{{hello
{\switchtobodyfont[myzhfont] 你好}}\par}
so it's probably also an operating system issue (caching files in mem, disk
access etc)
After debugging for half an hour in the morning, finally I know why
this is so slow on both XeTeX and pdfTeX.
This problem is not an operating system issue, But a ConTeXt feature.
in font-mkii, you use the following to define a actual font
(\definefontlocal and \definefontglobal):
{\expandafter\xdef\csname#1\endcsname % ! ! ! ! not needed in luatex ! ! ! !
{\noexpand\csname#1:\endcsname
\noexpand\reactivatefont{\somefontname}{\fontfile}}%
For example, in the previous example, it will define a lot of fonts,
like \*myzhfont12ptmmexrm*: , is defined as
\reactivatefont{cmex10}{lmex10}. When define that font, a macro
\*myzhfont12ptmmexrm* is defined to select the \*myzhfont12ptmmexrm* :
font.
\*myzhfont12ptmmexrm* =\csname *myzhfont12ptmmexrm* :\endcsname
\reactivefont{cmex10}{lmex10}
TeX then expand your reactivatefont macros to lmex10 at 12.0pt. So the
\*myzhfont12ptmmexrm*: font will assigned to lmex10 at 12.0pt. This is
quite right for definition.
However, after switching the font, the problems occurs:
it tries to call \*myzhfont12ptmmexrm* macro. the macro then expands to
\csname *myzhfont12ptmmexrm* :\endcsname \reactivefont{cmex10}{lmex10}
then to
\*myzhfont12ptmmexrm* :\reactivefont{cmex10}{lmex10}
and here TeX tries to do the following thing:
TeX select the font \*myzhfont12ptmmexrm*:, which is lmex10 at 12pt,
then *changing* into that font environment in order to *typeset*
\reactivefont. it then expand the macro of reacitve font, but found
nothing to typeset...
what's worse, this will occur on every real fonts in the definition.
So in fact TeX will switching dozens of fonts into the *current* font
for a \switchtobodyfont call, in order to typeset nothing. And
that's why ConTeXt is so slow on typeface changing.
The solution to this bug (or feature?) is quite easy, just use \font
to define the \*myzhfont12ptmmexrm*: font, but pay attention not to
switch the current font to \*myzhfont12ptmmexrm*: . Since it is quite
slow to switch to dozens of font for one \switchtobodyfont call even
in Knuth TeX.
Yue Wang
so it's probably also an operating system issue (caching files in mem, disk
access etc)
-
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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
Yue Wang wrote:
After debugging for half an hour in the morning, finally I know why
this is so slow on both XeTeX and pdfTeX.
This problem is not an operating system issue, But a ConTeXt feature.
in font-mkii, you use the following to define a actual font
(\definefontlocal and \definefontglobal):
{\expandafter\xdef\csname#1\endcsname % ! ! ! ! not needed in luatex ! ! !
!
{\noexpand\csname#1:\endcsname
\noexpand\reactivatefont{\somefontname}{\fontfile}}%
For example, in the previous example, it will define a lot of fonts,
like \*myzhfont12ptmmexrm*: , is defined as
\reactivatefont{cmex10}{lmex10}. When define that font, a macro
\*myzhfont12ptmmexrm* is defined to select the \*myzhfont12ptmmexrm* :
font.
\*myzhfont12ptmmexrm* =\csname *myzhfont12ptmmexrm* :\endcsname
\reactivefont{cmex10}{lmex10}
TeX then expand your reactivatefont macros to lmex10 at 12.0pt. So the
\*myzhfont12ptmmexrm*: font will assigned to lmex10 at 12.0pt. This is
quite right for definition.
However, after switching the font, the problems occurs:
it tries to call \*myzhfont12ptmmexrm* macro. the macro then expands to
\csname *myzhfont12ptmmexrm* :\endcsname \reactivefont{cmex10}{lmex10}
then to
\*myzhfont12ptmmexrm* :\reactivefont{cmex10}{lmex10}
and here TeX tries to do the following thing:
TeX select the font \*myzhfont12ptmmexrm*:, which is lmex10 at 12pt,
then *changing* into that font environment in order to *typeset*
\reactivefont. it then expand the macro of reacitve font, but found
nothing to typeset...
some of that activation can involve things that set up the font (some
related properties) so the mechanism is kind of generic; at that point
it is not possible to determine what is relevant and what not
changing such things at frst sight might lead to unexpected side effects
later on (as the context history has proven)
although part of the activation code can be disables when defining a
sequence of fonts (as in a massive switch) it would complicate the font
code even more to do so; in mkiv we do need less of that as explained
below (hence the remark 'not needed in luatex')
for instance, we can redefine (for xetex)
\def\updatefontparameters
{\edef\@@fontfeatures{\truefontdata\fontfile\s!features}%
\edef\@@fontskewchar{\truefontdata\fontfile\s!skewchar}}
\def\setfontcharacteristics
{%\updatefontparameters % redundant, will go away, faster too
\the\everyfont
\synchronizepatternswithfont}
Which is faster, but then we also need to make absolutely sure that
xetex only uses opentype fonts (which in turn means that we need to
provide separate typescript files for xetex to make sure that this
happens); this can be significant on a 10 second job with 10K switches,
but less in a complex document that takes 2 minutes to process, or as we
sometimes had, 20 minute jobs
Another option is to make all sizes (\tf*) optional, which then would
force a typeface switch in heads which in turn slows down things at that
end, or you could disable bigmath (that follows the sizes) and then end
up with mails to this list why math does not scale in titles, etc etc
what's worse, this will occur on every real fonts in the definition.
So in fact TeX will switching dozens of fonts into the *current* font
for a \switchtobodyfont call, in order to typeset nothing. And
that's why ConTeXt is so slow on typeface changing.
The solution to this bug (or feature?) is quite easy, just use \font
to define the \*myzhfont12ptmmexrm*: font, but pay attention not to
switch the current font to \*myzhfont12ptmmexrm*: . Since it is quite
slow to switch to dozens of font for one \switchtobodyfont call even
in Knuth TeX.
You make it sound as all of the font system's features are kind of wrong
and contain oversights ... i'm not going to enter a discussion about the
how and why of the context way of doing things as it is a accumulation
of over 15 years of development and experients and realistic typesetting
situations. We're not that stupid.
In mkii (and to a lesser extent in mkiv) we have to deal with several
situations:
Fonts have 256 chars at most so they cannot cover each language. This
means that when one mixes languages, one also might need multiple fonts.
For instance using two complete different typefaces, one with ec
encoding, another with texnansi encoding and both with different math
fonts also in a different encoding is happing at our end.
As fonts encodings are related to hyphenation, there is a relationship
between a font switch and a language switch i.e. when we're typesetting
in czech it might be that a font switch also results in a patterns
switch due to the fact that patterns relate to fonts. The fact that CJK
does not hyphenate is no reason to remove that feature from the font
system. I know that the latex way of doing things is to replace and
redefine core code for specific purposes, but that's not the way we do
things in context. In my own usage i just accepted
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
2009/5/12 Yue Wang:
here is the xelatex result given by a chinese user:
\documentclass{minimal}
\usepackage{xeCJK}
\setCJKfamilyfont{song}{SimSun}
\begin{document}
{hello {\CJKfamily{song}你好}}\par % 1 lines
\end{document}
got 209 pages, three seconds to run.
note he is switching families 2 times. (\family{foo} in latex ==
\switchbodyfont[foo] in context)
I didn't test that, but I suspect that one thing could make an
enormous time difference if you switch the font 10.000 times.
I suspect that what LaTeX does is something similar to the following
(in ConTeXt slang):
\starttypescript[cjk] [zhfont]
\definefontsynonym [CJK] [file:SimSun]
\definefontsynonym [CJKBold] [file:SimSun] % you could
artificially embolden the font
\definefontsynonym [CJKItalic] [file:SimSun] % you could
artificially slant the font
\definefontsynonym [CJKBoldItalic] [file:SimSun]
\stoptypescript
\definetypeface [myzhfont] [rm] [serif] [latin-modern] [default]
\definetypeface [myzhfont] [ss] [sans] [latin-modern] [default]
\definetypeface [myzhfont] [tt] [mono] [latin-modern] [default]
\definetypeface [myzhfont] [cjk] [cjk] [zhfont] [default]
\dorecurse{1}{ hello {\cjk 你好 \it 你好}}
In a similar way ConTeXt supports handwriting/calligraphy families
(\hw, \cg I think; well, maybe you could even pretend that you are
defining the calligraphy font to start with, as that one is already
defined where it needs to be defined). If you manage to make the
proposal above to run, this will save you the need for switching the
whole typeface ten thousands of times and should become really fast
(hopefully).
Mojca
___
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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
On Wed, May 13, 2009 at 10:59, Mojca Miklavec wrote:
I suspect that what LaTeX does is something similar to the following
(in ConTeXt slang):
\starttypescript[cjk] [zhfont]
\definefontsynonym [CJK] [file:SimSun]
\definefontsynonym [CJKBold] [file:SimSun] % you could
artificially embolden the font
\definefontsynonym [CJKItalic] [file:SimSun] % you could
artificially slant the font
\definefontsynonym [CJKBoldItalic] [file:SimSun]
\stoptypescript
\definetypeface [myzhfont] [rm] [serif] [latin-modern] [default]
\definetypeface [myzhfont] [ss] [sans] [latin-modern] [default]
\definetypeface [myzhfont] [tt] [mono] [latin-modern] [default]
\definetypeface [myzhfont] [cjk] [cjk] [zhfont] [default]
\dorecurse{1}{ hello {\cjk 你好 \it 你好}}
In a similar way ConTeXt supports handwriting/calligraphy families
(\hw, \cg I think; well, maybe you could even pretend that you are
defining the calligraphy font to start with, as that one is already
defined where it needs to be defined). If you manage to make the
proposal above to run, this will save you the need for switching the
whole typeface ten thousands of times and should become really fast
(hopefully).
I tested the following, but you should compare the timing on your
machine (it's a different processor and a different font):
\starttypescript[calligraphy] [song]
\definefontsynonym [AdobeSong] [file:AdobeSongStd-Light]
\stoptypescript
\starttypescript[calligraphy] [song] [name]
\definefontsynonym [Calligraphy] [AdobeSong]
\stoptypescript
\starttypescript[zhfont]
\definetypeface [zhfont] [rm] [serif] [modern] [default]
\definetypeface [zhfont] [ss] [sans][modern] [default]
\definetypeface [zhfont] [tt] [mono][modern] [default]
\definetypeface [zhfont] [cg] [calligraphy] [song] [default]
\stoptypescript
\usetypescript[zhfont]
\setupbodyfont[zhfont,10pt]
\font\ccg=[AdobeSongStd-Light]
\starttext
% test 1: takes 12 seconds
\dorecurse{1}{ hello {\cg 你好}}
% test 2: takes 9 seconds
\dorecurse{1}{ hello {\ccg 你好}}
\stoptext
Switching the whole typescript (\def\ccg{\zhfont} and running the
second test) took 123 seconds eating 100% of processor time.
So maybe that's the way to go, just define a calligraphy-like constant
for cjk family that will enable switching to bold/italic as well (an
equivalent to rm/ss/tt)?
Mojca
___
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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
Am 13.05.2009 um 10:59 schrieb Mojca Miklavec:
\definetypeface [myzhfont] [rm] [serif] [latin-modern] [default]
\definetypeface [myzhfont] [ss] [sans] [latin-modern] [default]
\definetypeface [myzhfont] [tt] [mono] [latin-modern] [default]
\definetypeface [myzhfont] [cjk] [cjk] [zhfont] [default]
\dorecurse{1}{ hello {\cjk 你好 \it 你好}}
How should this work when you switch from serif to sans, e.g.:
\rm hello {\cjk 你好 \it 你好} \ss hello {\cjk 你好 \it 你好}
Wolfgang
___
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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
On Wed, May 13, 2009 at 12:02, Wolfgang Schuster wrote:
Am 13.05.2009 um 10:59 schrieb Mojca Miklavec:
\definetypeface [myzhfont] [rm] [serif] [latin-modern] [default]
\definetypeface [myzhfont] [ss] [sans] [latin-modern] [default]
\definetypeface [myzhfont] [tt] [mono] [latin-modern] [default]
\definetypeface [myzhfont] [cjk] [cjk] [zhfont] [default]
\dorecurse{1}{ hello {\cjk 你好 \it 你好}}
How should this work when you switch from serif to sans, e.g.:
\rm hello {\cjk 你好 \it 你好} \ss hello {\cjk 你好 \it 你好}
In the same way as
\rm hello {\tt 你好 \it 你好} \ss hello {\tt 你好 \it 你好}
if tt was a family containing those Chinese characters, so:
\rm roman {\cjk Chinese \it Italic Chinese} \ss sans {\cjk (same)
Chinese (as before) \it Italic Chinese}
Or do you want to suggest that one would possibly need both serif
and sans variants of some Chinese font, often switching between
families inside a document?
Mojca
___
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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
Am 13.05.2009 um 12:17 schrieb Mojca Miklavec: Or do you want to suggest that one would possibly need both serif and sans variants of some Chinese font, often switching between families inside a document? That's what I mean, also in chinese you use different fonts for serif, sans and mono. Wolfgang ___ 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 ___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
Mojca Miklavec wrote:
\starttext
% test 1: takes 12 seconds
\dorecurse{1}{ hello {\cg 你好}}
% test 2: takes 9 seconds
\dorecurse{1}{ hello {\ccg 你好}}
\stoptext
Switching the whole typescript (\def\ccg{\zhfont} and running the
second test) took 123 seconds eating 100% of processor time.
% test 1: takes 12 seconds
\dorecurse{1}{ hello {\cg 你好}}
8 sec on my machine
% test 2: takes 9 seconds
% \dorecurse{1}{ hello {\ccg 你好}}
6 sec on my machine
now, say that 10K switches represent 250 pages (some 40 per page which
is already quite a lot for *full switches*) then we're talking of 0.01
sec per page for this, which is kind of neglectable compared to the rest
of the typesetting
also, mkiv takes less than 6 sec for the test and there we can use
fallbacks and as such less switches (of the runtime, 3 sec is font
loading which is due to the fact that for some reason my machine/vista
does 300K page faults per big font, something that will not happen on
more modern machines or on linux)
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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
On Wed, May 13, 2009 at 12:41, Wolfgang Schuster wrote: Am 13.05.2009 um 12:17 schrieb Mojca Miklavec: Or do you want to suggest that one would possibly need both serif and sans variants of some Chinese font, often switching between families inside a document? That's what I mean, also in chinese you use different fonts for serif, sans and mono. Wait a minute ... why do they need mono/typewriter? Aren't all the Chinese glyphs fixed width anyway? Also, if one has a well-designed font that includes all the latin glyphs and all the bold/italic variants then one should in principle not need an extra latin family, but those are probably just nice dreams ... I always had the impression that there are not many high-quality Chinese fonts and that having bold and italic alone is a problem, not to speak about frequent mixing of several different families. (Just thinking alound: aren't there plenty of books around that also mix lots of greek and latin, possibly using different fonts for them? How do they deal with the problem, or is the problem just neglectable?) Mojca ___ 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 ___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
Hi Mojca
let me show you a neat trick ... just as distraction of your thesis work
...
\starttypescript[serif] [modern]
\definefontsynonym [Whatever] [file:AdobeSongStd-Light]
\stoptypescript
\starttypescript[zhfont]
\definetypeface [zhfont] [rm] [serif] [modern] [default]
\stoptypescript
\definebodyfont [default] [rm] [wh=Whatever sa 1]
\edef\fontalternativetextlist{\fontalternativetextlist,wh}
% no chinese in math anyway
%
% \let\whfam\nnfam
%
% \appendtoks
% \dosettextfamily\c!wh
% \to \textstrategies
\usetypescript[zhfont] \setupbodyfont[zhfont,10pt]
\starttext
\dorecurse{1}{ hello {\wh 你好}}
\tfd \dorecurse{1}{ hello {\wh 你好}}
\stoptext
this works because the low level system is not frozen but extensible by
design (or a feature); of course, the more such extra alternatives we
define by default (which we therefore don't) the slower slovenian
typesetting becomes when again we do a full bodyfont switch -)
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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
Am 13.05.2009 um 13:12 schrieb Mojca Miklavec: On Wed, May 13, 2009 at 12:41, Wolfgang Schuster wrote: Am 13.05.2009 um 12:17 schrieb Mojca Miklavec: Or do you want to suggest that one would possibly need both serif and sans variants of some Chinese font, often switching between families inside a document? That's what I mean, also in chinese you use different fonts for serif, sans and mono. Wait a minute ... why do they need mono/typewriter? Aren't all the Chinese glyphs fixed width anyway? Do you want code sample in the same font as the result? With certain features in OT fonts you can enable proportional chars for punctuation, kana etc. Also, if one has a well-designed font that includes all the latin glyphs and all the bold/italic variants then one should in principle not need an extra latin family, but those are probably just nice dreams ... I always had the impression that there are not many high-quality Chinese fonts and that having bold and italic alone is a problem, not to speak about frequent mixing of several different families. The latin glyphs in many free fonts are even worse than Comic Sans :( Adobe fills the latin ranges with glyphs from other fonts with different quality but they have lots of features, e.g. ital to enable italics :) (Just thinking alound: aren't there plenty of books around that also mix lots of greek and latin, possibly using different fonts for them? How do they deal with the problem, or is the problem just neglectable?) Dunno, AFAIR Thomas use switch to a different font in his greek module, in mkiv this is trivia with font fallbacks. Wolfgang ___ 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 ___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
On Wed, May 13, 2009 at 7:12 PM, Mojca Miklavec
mojca.miklavec.li...@gmail.com wrote:
On Wed, May 13, 2009 at 12:41, Wolfgang Schuster wrote:
Am 13.05.2009 um 12:17 schrieb Mojca Miklavec:
Or do you want to suggest that one would possibly need both serif
and sans variants of some Chinese font, often switching between
families inside a document?
That's what I mean, also in chinese you use different fonts for
serif, sans and mono.
Wait a minute ... why do they need mono/typewriter? Aren't all the
Chinese glyphs fixed width anyway?
We do not need mono. We do not even need italic, bold italic, and small caps.
ConTeXt/LaTeX's naming scheme just follow traditional latin way, and
that's pretty different compared to Asian scripts.
(of course, some of them are similar. for example, Song is like roman
regular, CuSong is like roman bold. LiShu is like calligraphy,
Dengxian is like Sans. CuDengXian (Hei) is like Sans bold).
But why do we define them all as latin typefaces? that's just because
we should follow traditional ConTeXt or LaTeX way, since the whole
ConTeXt or LaTeX system is heavily based on their own font naming
mechanism. You can grep the ConTeXt source code, and find font
switching like \it, \rm, \ss appears on almost every file. If we
insist on our own naming mechanism (like \song, \hei, \cusong), then
ConTeXt will become unusable in the end.
Moreover, the only way to write consist document in both latin and cjk
language is to fall cjk fonts into latin system. Suppose you want to
define a document chapter title font, neither \heid nor \bfd will
suffice. The only way is to map all chinese font names (hei, song, for
example) to latin names(bold italic, for example) [since latin names
can be treat as a super set of asian names], or design a more
comprehensive naming system, and later mapping both into that.
Then return to your question. what happens if mono is not defined?
well. when you want to write a web link or source code that contains
Chinese like
\type{http://zh.wikipedia.org/wiki/字体}
or
\starttyping
if (filename == NIL){
printf(文件%s未找到\n, filename);
return -1;
}
\stoptyping
you will run into problems since mono for Chinese are not defined.
Also, if one has a well-designed font that includes all the latin
glyphs and all the bold/italic variants then one should in principle
not need an extra latin family, but those are probably just nice
dreams ... I always had the impression that there are not many
high-quality Chinese fonts and that having bold and italic alone is a
problem, not to speak about frequent mixing of several different
families.
Chinese fonts released in recent years have better latin glyphs
design. But as I said before, the Chinese script system is quite
different from the Latin one. Chinese companies are not obliged to
include italic or small caps glyphs in their Chinese fonts, just
like we cannot ask Adobe to include kai and song styles in their
Minion Pro fonts.
(Just thinking alound: aren't there plenty of books around that also
mix lots of greek and latin, possibly using different fonts for them?
How do they deal with the problem, or is the problem just
neglectable?)
Compound typeface is a very basic feature required for all typesetting
software.
Quark and InDesign have options to enable this feature.
This is even possible in no-production-purpose software like Microsoft Word.
But as far as I know, most typographic software programs are WYSIWYG
systems, and rendering a page in computer is much faster than typing a
word by human beings. So we will not notice the performance problem in
these systems. But for TeX this is different, in order to see the
result after positioning something to the right place, or changing a
few words, several compile-view-adjust-compile-view-adjust
procedures will be involved. So the long compilation time will make
the software unusable (Imagine that you want to correct a minor error
in a document and see the result, you press the typeset button in
TeXWorks, leave the lualatex program running, and during the 5 minutes
compilation time, you can have a cup of tea and enjoy the sunshine...
Anyway, t-zhspacing is much faster than lualatex. but 1 minutes to
compile a 100 pages document is still too long)
But one thing is always puzzling me: When open MS Word, it consumes
16MB memory, then I typeset Chinese text in 10 different Chinese fonts
(all are 10M+ each), word only consumes 30MB memory. If I do that in
LuaTeX it will consume almost 1G memory... why MS Word parses fonts
and renders text so fast while consumes such less memory? Can TeX do
that too?
Mojca
___
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 :
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
On May 13, 2009, at 1:28 PM, Wolfgang Schuster wrote: (Just thinking alound: aren't there plenty of books around that also mix lots of greek and latin, possibly using different fonts for them? How do they deal with the problem, or is the problem just neglectable?) Dunno, AFAIR Thomas use switch to a different font in his greek module, in mkiv this is trivia with font fallbacks. Wolfgang Just FYI: yes, I do use switchtobodyfont in my Greek module, but I have more or less given up on XeTeX, so I've never encountered the problem. The font fallback is great for filling in some glyphs, but I haven't yet used it for entire Greek passages; haven't yet seen the advantage over switching the bodyfont. All best Thomas ___ 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 ___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
Yue Wang wrote: the software unusable (Imagine that you want to correct a minor error in a document and see the result, you press the typeset button in TeXWorks, leave the lualatex program running, and during the 5 minutes it depends on usage: if you want wysiwyg you should use a desk top publishing program or a word processor if you type an occasional letter or whatever small document, use a word processor if you do automated typesetting, you can use tex if you make very large and complex docs, you can use tex if you focus on writing and occasionally need to see the output (simply because you trust the system to be able to deal with it) you can also use tex compilation time, you can have a cup of tea and enjoy the sunshine... Anyway, t-zhspacing is much faster than lualatex. but 1 minutes to compile a 100 pages document is still too long) it all depends on what you use and want to achieve; also lualatex is not relevant when we discuss for instance context mkiv which follows different routes (btw, mk.pdf takes some 55 seconds for a 300+ page document and that's 10 seconds for page faulting so on another machine it runs faster; and mk uses a lot of large fonts + some demanding typesetting like arabic) But one thing is always puzzling me: When open MS Word, it consumes 16MB memory, then I typeset Chinese text in 10 different Chinese fonts (all are 10M+ each), word only consumes 30MB memory. If I do that in LuaTeX it will consume almost 1G memory... why MS Word parses fonts and renders text so fast while consumes such less memory? Can TeX do that too? word will use shared libs so you don't see all mem used; if a file on disk is 10 meg and you use several of them, i'm pretty sure that such a font unpacked takes some mem somewhere; also, the renderer is embedded in the operating system; in mkiv we maintain a table representation and since fonts hame many subtables it takes mem also, if word renders fast and efficient and does the job right, you don't need tex at all -) 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 ___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
Am 13.05.2009 um 14:59 schrieb Hans Hagen: Yue Wang wrote: compilation time, you can have a cup of tea and enjoy the sunshine... Anyway, t-zhspacing is much faster than lualatex. but 1 minutes to compile a 100 pages document is still too long) it all depends on what you use and want to achieve; also lualatex is not relevant when we discuss for instance context mkiv which follows different routes (btw, mk.pdf takes some 55 seconds for a 300+ page document and that's 10 seconds for page faulting so on another machine it runs faster; and mk uses a lot of large fonts + some demanding typesetting like arabic) 1 min for 100 pages is very slow, I have a japanese/german book which takes about 1 min for 600 pages, the slowest part is a very huge natural table (over 700 cells) where ConTeXt needs about 1 second. Wolfgang ___ 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 ___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
Hi:
update: change the second example, remove the .otf suffix , and
texexec --xtx gives:
TeXExec | runtime: 5.766
Obviously, this is a parsing bug in ConTeXt.
I doubt the reason to the third one is the same.
Yue Wang
2009/5/12 Yue Wang yuleo...@gmail.com:
Hi, Hans and Jonathan:
I made some testing samples in ConTeXt to test XeTeX. but the result
is quite strange. All benchmark are get from the second run:
Sample 1:
\definefont[a][file:SimSun]
\starttext
\dorecurse{1}{ hello {\a 你好}}
\stoptext
And here is the result:
XeTeX: TeXExec | runtime: 7.25
LuaTeX: MTXrun | total runtime: 6.719
This is considerablly ok. So we can say that the font switching is pretty
fast.
Sample 2:
\definefont[a][file:AdobeSongStd-Light.otf]
\starttext
\dorecurse{1}{ hello {\a 你好}}
\stoptext
XeTeX: TeXExec | runtime: 63.65
LuaTeX: MTXrun | total runtime: 8.156
Here I only change the font from SimSun to Adobe Song (the two fonts
are almost at the same sice [~10M]).
But the xetex result is very differt from the previous run. it
consumes one minute to compile the file.
Sample 3:
\starttypescript[serif] [myzhfont]
\definefontsynonym [Serif] [file:SimSun]
\definefontsynonym [SerifBold] [file:SimSun]
\definefontsynonym [SerifItalic] [file:SimSun]
\definefontsynonym [SerifBoldItalic] [file:SimSun]
\stoptypescript
\starttypescript[sans] [myzhfont]
\definefontsynonym [Sans] [file:SimSun]
\definefontsynonym [SansBold] [file:SimSun]
\definefontsynonym [SansItalic] [file:SimSun]
\definefontsynonym [SansBoldItalic] [file:SimSun]
\stoptypescript
\starttypescript[mono] [myzhfont]
\definefontsynonym [Mono] [file:SimSun]
\definefontsynonym [MonoBold] [file:SimSun]
\definefontsynonym [MonoItalic] [file:SimSun]
\definefontsynonym [MonoBoldItalic] [file:SimSun]
\stoptypescript
\definetypeface [myzhfont] [rm] [serif][myzhfont] [default]
\definetypeface [myzhfont] [ss] [sans] [myzhfont] [default]
\definetypeface [myzhfont] [tt] [mono] [myzhfont] [default]
\def\a{\myzhfont}
\starttext
\dorecurse{1}{ hello {\a 你好}}
\stoptext
XeTeX: TeXExec | runtime: 64.797
LuaTeX: MTXrun | total runtime: 10.797
Here we use SimSun since in the first sample xetex can load simsun quite fast.
However, in this time we define a typescript, and make all the styles
fall into SimSun.
Now xetex behaves quite strangely: it uses one minutes to compile this
single document...
So my question is
- why loading otf is so slow?
- is this a bug in context or in xetex? can it be fixed?
- how can we make sample 3 (using typescript) run faster?
Thanks.
Yue Wang
___
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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
Hi,
Sum up:
define a font usng typescripts takes 64.797 seconds.
define a font like \definefont[a][file:SimSun.ttf] takes 55.548 seconds
define a font like \definefont[a][file:SimSun] takes 4.329 seconds
define a font like \font\a=[simsun] takes 1.812 seconds
Jonathan and Jin-Hwan, sorry for the noise. I am now sure that it is a
context bug, not xetex's.
Yue Wang
2009/5/12 Yue Wang yuleo...@gmail.com:
Hi, Hans and Jonathan:
I made some testing samples in ConTeXt to test XeTeX. but the result
is quite strange. All benchmark are get from the second run:
Sample 1:
\definefont[a][file:SimSun]
\starttext
\dorecurse{1}{ hello {\a 你好}}
\stoptext
And here is the result:
XeTeX: TeXExec | runtime: 7.25
LuaTeX: MTXrun | total runtime: 6.719
This is considerablly ok. So we can say that the font switching is pretty
fast.
Sample 2:
\definefont[a][file:AdobeSongStd-Light.otf]
\starttext
\dorecurse{1}{ hello {\a 你好}}
\stoptext
XeTeX: TeXExec | runtime: 63.65
LuaTeX: MTXrun | total runtime: 8.156
Here I only change the font from SimSun to Adobe Song (the two fonts
are almost at the same sice [~10M]).
But the xetex result is very differt from the previous run. it
consumes one minute to compile the file.
Sample 3:
\starttypescript[serif] [myzhfont]
\definefontsynonym [Serif] [file:SimSun]
\definefontsynonym [SerifBold] [file:SimSun]
\definefontsynonym [SerifItalic] [file:SimSun]
\definefontsynonym [SerifBoldItalic] [file:SimSun]
\stoptypescript
\starttypescript[sans] [myzhfont]
\definefontsynonym [Sans] [file:SimSun]
\definefontsynonym [SansBold] [file:SimSun]
\definefontsynonym [SansItalic] [file:SimSun]
\definefontsynonym [SansBoldItalic] [file:SimSun]
\stoptypescript
\starttypescript[mono] [myzhfont]
\definefontsynonym [Mono] [file:SimSun]
\definefontsynonym [MonoBold] [file:SimSun]
\definefontsynonym [MonoItalic] [file:SimSun]
\definefontsynonym [MonoBoldItalic] [file:SimSun]
\stoptypescript
\definetypeface [myzhfont] [rm] [serif][myzhfont] [default]
\definetypeface [myzhfont] [ss] [sans] [myzhfont] [default]
\definetypeface [myzhfont] [tt] [mono] [myzhfont] [default]
\def\a{\myzhfont}
\starttext
\dorecurse{1}{ hello {\a 你好}}
\stoptext
XeTeX: TeXExec | runtime: 64.797
LuaTeX: MTXrun | total runtime: 10.797
Here we use SimSun since in the first sample xetex can load simsun quite fast.
However, in this time we define a typescript, and make all the styles
fall into SimSun.
Now xetex behaves quite strangely: it uses one minutes to compile this
single document...
So my question is
- why loading otf is so slow?
- is this a bug in context or in xetex? can it be fixed?
- how can we make sample 3 (using typescript) run faster?
Thanks.
Yue Wang
___
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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
here is the xelatex result given by a chinese user:
\documentclass{minimal}
\usepackage{xeCJK}
\setCJKfamilyfont{song}{SimSun}
\begin{document}
{hello {\CJKfamily{song}你好}}\par % 1 lines
\end{document}
got 209 pages, three seconds to run.
note he is switching families 2 times. (\family{foo} in latex ==
\switchbodyfont[foo] in context)
On Tue, May 12, 2009 at 5:30 PM, Hans Hagen pra...@wxs.nl wrote:
Yue Wang wrote:
Hi,
Sum up:
define a font usng typescripts takes 64.797 seconds.
define a font like \definefont[a][file:SimSun.ttf] takes 55.548 seconds
define a font like \definefont[a][file:SimSun] takes 4.329 seconds
define a font like \font\a=[simsun] takes 1.812 seconds
Jonathan and Jin-Hwan, sorry for the noise. I am now sure that it is a
context bug, not xetex's.
and
update: change the second example, remove the .otf suffix , and
texexec --xtx gives:
TeXExec | runtime: 5.766
Obviously, this is a parsing bug in ConTeXt.
context is not parsing for .otf or .ttf and has no reason for it either
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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
sorry the the context sample and latex sample are not equivalent
(note the \par).
So I test again:
\starttypescript[serif] [myzhfont]
\definefontsynonym [Serif] [file:SimSun]
\definefontsynonym [SerifBold] [file:SimSun]
\definefontsynonym [SerifItalic] [file:SimSun]
\definefontsynonym [SerifBoldItalic] [file:SimSun]
\stoptypescript
\starttypescript[sans] [myzhfont]
\definefontsynonym [Sans] [file:SimSun]
\definefontsynonym [SansBold] [file:SimSun]
\definefontsynonym [SansItalic] [file:SimSun]
\definefontsynonym [SansBoldItalic] [file:SimSun]
\stoptypescript
\starttypescript[mono] [myzhfont]
\definefontsynonym [Mono] [file:SimSun]
\definefontsynonym [MonoBold] [file:SimSun]
\definefontsynonym [MonoItalic] [file:SimSun]
\definefontsynonym [MonoBoldItalic] [file:SimSun]
\stoptypescript
\definetypeface [myzhfont] [rm] [serif][myzhfont] [default]
\definetypeface [myzhfont] [ss] [sans] [myzhfont] [default]
\definetypeface [myzhfont] [tt] [mono] [myzhfont] [default]
\def\a{\myzhfont}
\dorecurse{1}{{hello {\a 你好}}\par}
\bye
XeConTeXt uses 45.502 seconds, while XeLaTeX uses 3 seconds.
2009/5/12 Yue Wang yuleo...@gmail.com:
here is the xelatex result given by a chinese user:
\documentclass{minimal}
\usepackage{xeCJK}
\setCJKfamilyfont{song}{SimSun}
\begin{document}
{hello {\CJKfamily{song}你好}}\par % 1 lines
\end{document}
got 209 pages, three seconds to run.
note he is switching families 2 times. (\family{foo} in latex ==
\switchbodyfont[foo] in context)
On Tue, May 12, 2009 at 5:30 PM, Hans Hagen pra...@wxs.nl wrote:
Yue Wang wrote:
Hi,
Sum up:
define a font usng typescripts takes 64.797 seconds.
define a font like \definefont[a][file:SimSun.ttf] takes 55.548 seconds
define a font like \definefont[a][file:SimSun] takes 4.329 seconds
define a font like \font\a=[simsun] takes 1.812 seconds
Jonathan and Jin-Hwan, sorry for the noise. I am now sure that it is a
context bug, not xetex's.
and
update: change the second example, remove the .otf suffix , and
texexec --xtx gives:
TeXExec | runtime: 5.766
Obviously, this is a parsing bug in ConTeXt.
context is not parsing for .otf or .ttf and has no reason for it either
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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
Yue Wang wrote:
here is the xelatex result given by a chinese user:
\documentclass{minimal}
\usepackage{xeCJK}
\setCJKfamilyfont{song}{SimSun}
\begin{document}
{hello {\CJKfamily{song}你好}}\par % 1 lines
\end{document}
got 209 pages, three seconds to run.
note he is switching families 2 times. (\family{foo} in latex ==
\switchbodyfont[foo] in context)
hard to say ... it all depends on how a bodyfont (or typeface) is
defined, how many real fontsa re involved etc; normally, when using a
typeface definition a bodyfont switch is rather efficient as it only
involves one namespace switch + one font switch but when extensive math
definitions are also involved it might take a few more cycles
anyway .. i cannot comment on runtimes as xetex on my windows box runs
too slow (caching issue) and all examples are slow, no matter how i
specify fonts so i will not look into the code till that gets fixed first
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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
Hans Hagen wrote: anyway .. i cannot comment on runtimes as xetex on my windows box runs too slow (caching issue) and all examples are slow, no matter how i specify fonts so i will not look into the code till that gets fixed first The example with the typescript seems logical to me: a typescript does much work beforehand, so I assume SimSum is loaded multiple times. I am trying the AdobeSong example as we speak, there surely seems something wrong there. Best wishes, Taco ___ 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 ___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
Am 12.05.2009 um 11:09 schrieb Yue Wang:
Hi,
Sum up:
define a font usng typescripts takes 64.797 seconds.
You can speed it up when you replace \definetypeface (...) with
\definefont:
\unprotect
\definefontsynonym [ZhSerif] [name:AdobeSongStd-Light]
\definefont [ZhSerifRegular][ZhSerif]
\definefontsynonym [ZhSerifBold] [name:AdobeHeitiStd-Regular]
\definefont [ZhSerifBold] [ZhSerifBold]
\definefontsynonym [ZhSerifItalic] [name:AdobeKaitiStd-Regular]
\definefont [ZhSerifItalic] [ZhSerifItalic]
\definefontsynonym [ZhSerifBoldItalic] [name:AdobeHeitiStd-Regular]
\definefont [ZhSerifBoldItalic] [ZhSerifBoldItalic]
\definefontsynonym [ZhSans][name:AdobeKaitiStd-Regular]
\definefont [ZhSansRegular] [ZhSans]
\definefontsynonym [ZhSansBold][name:AdobeHeitiStd-Regular]
\definefont [ZhSansBold][ZhSansBold]
\definefontsynonym [ZhSansItalic] [name:AdobeKaitiStd-Regular]
\definefont [ZhSansItalic] [ZhSansItalic]
\definefontsynonym [ZhSansBoldItalic] [name:AdobeHeitiStd-Regular]
\definefont [ZhSansBoldItalic] [ZhSansBoldItalic]
\definefontsynonym [ZhMono][name:AdobeFangsongStd-Regular]
\definefont [ZhMonoRegular] [ZhMono]
\definefontsynonym [ZhMonoBold][name:AdobeHeitiStd-Regular]
\definefont [ZhMonoBold][ZhMonoBold]
\definefontsynonym [ZhMonoItalic] [name:AdobeFangsongStd-Regular]
\definefont [ZhMonoItalic] [ZhMonoItalic]
\definefontsynonym [ZhMonoBoldItalic] [name:AdobeHeitiStd-Regular]
\definefont [ZhMonoBoldItalic] [ZhMonoBoldItalic]
\def\domyzhfont{\getvalue{Zh\fontstringA\fontstylesuffix}}
%\def\myzhfont{\groupedcommand{\pushcurrentfont\domyzhfont}
{\popcurrentfont}}
\def\myzhfont{\domyzhfont}
\protect
\starttext
\rm\tf hello {\myzhfont 你好} world\par
\rm\it hello {\myzhfont 你好} world\par
\rm\bf hello {\myzhfont 你好} world\par
\rm\bi hello {\myzhfont 你好} world\par
\blank
\ss\tf hello {\myzhfont 你好} world\par
\ss\it hello {\myzhfont 你好} world\par
\ss\bf hello {\myzhfont 你好} world\par
\ss\bi hello {\myzhfont 你好} world\par
\blank
\tt\tf hello {\myzhfont 你好} world\par
\tt\it hello {\myzhfont 你好} world\par
\tt\bf hello {\myzhfont 你好} world\par
\tt\bi hello {\myzhfont 你好} world\par
\page
\dorecurse{1000}{\dorecurse{10}{ hello {\myzhfont 你好}}\par}
\stoptext
Wolfgang
___
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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
Taco Hoekwater wrote:
Hans Hagen wrote:
anyway .. i cannot comment on runtimes as xetex on my windows box runs
too slow (caching issue) and all examples are slow, no matter how i
specify fonts so i will not look into the code till that gets fixed first
The example with the typescript seems logical to me: a typescript does
much work beforehand, so I assume SimSum is loaded multiple times.
I am trying the AdobeSong example as we speak, there surely seems
something wrong there.
let's start with saying that I have no intention to optimize mkii for
xetex as we decided some time ago (at the context meeting) that we would
freeze mkii; so, if things run acceptable that's ok for me; we're also
not going to optimize any further for pdftex any more unless i need it
in a high performance project -)
when i delete my font.conf file (i.e. forget about names but only allow
files) i can run xetex with reasonable performance
some timing:
% 64 sec xetex, 11 sec luatex (56 sec xetex when \nobigmath)
\setupbodyfont[myzhfont]
\dorecurse{1}{{hello {\switchtobodyfont[myzhfont] 你好}}\par}
% 67 sec xetex, 11.5 sec luatex
\dorecurse{1}{{hello {\switchtobodyfont[myzhfont] 你好}}\par}
% 5 sec xetex, 7 sec luatex
\setupbodyfont[myzhfont] \dorecurse{1}{{hello {你好}}\par}
now, in practice one will not switch complete bodyfonts so often, so
something like
\setupbodyfont[myzhfont] \dorecurse{1}{{\bf hello {你好}}\par}
is more realistic (taks .5 sec more in xetex)
as taco mentioned, switchtobidyfont does way more than just switching a
font like checking current state which involves checking fontclass,
size, style etc and setting up font parameters for each case, as well as
setting up math; fonts, when not yet set, will be loaded but that
happens only once so that can be kind of neglected
the differences between mkii and mkiv have several reasons:
= mkiv has a more efficient font system as no encodings, mappings, one
math family etc are involved and as such is much faster (less comma list
processing, less checking, less mapping and encoding switches)
= in mkii there is a relationship between fonts, languages etc an dall
need to be (re)synced since anything can have changed; i'm pretty sure
that context does much more here than latex because we cater for mixed
typefaces, mixed languages, encodings, etc and all combinations that can
occur
= mkiv code has been optimized in the process so that might also count a
bit (but not that much in real situations)
= mkiv can use traditional traditional fonts but does that in a special
way by turning then into wide fonts which is also more efficient
now, since xetex runs on top of mkii it caries some overhead from
traditional fonts
if we accept some limitations (i.e. stupify context mkii a bit) we can
gain some speed (we can probably also load some less code then), for example
\def\updatefontparameters
{\edef\@@fontfeatures{\truefontdata\fontfile\s!features}%
\edef\@@fontskewchar{\truefontdata\fontfile\s!skewchar}}
\def\setfontcharacteristics
{\updatefontparameters
\the\everyfont}
\let\synchronizepatternswithfont\relax
saves 20 sec on the 10K (irrealistic anyway) run but then we definitely
need to make typescripts xetex specific and make sure that no encoded
font files are used any longer
The question is ... does it pay off for me (as i have to do it in order
to make sure we don't mess up things for pdftex) to spend time on this?
Probably not.
(Concerning timing: forget about comparing to latex as in practice much
more is involved like page building etc. There are subsystems in context
where i could squeeze out yet another .1 second just to see it become
noise on real runs.)
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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
Thank you, Taco.
currently I found one way to speed up font loading:
\synchronizemathfontsfalse
\let\synchronizetext\relax
\starttypescript[serif] [myzhfont]
\definefontsynonym [Serif] [file:SimSun]
\stoptypescript
\definetypeface [myzhfont] [rm] [serif][myzhfont] [default]
\def\a{\myzhfont}
\dorecurse{1}{{hello {\a 你好}}\par}
\bye
TeXExec | runtime: 10.172
much faster, but still far slower than \definefont.
this reminds me another possible bug in ConTeXt:
Test1:
\definetypeface[iwona][ss][sans] [iwona] [default]
\definetypeface[iwona][mm][math] [iwona] [default][text=ss]
\setupbodyfont[iwona]
\starttext
foobar
\stoptext
runtime= 6.625. There is a 5 seconds pause after loading
(c:/context/tex/texmf-context/tex/context/base/spec-xet.tex)
But I don't know what xetex is loading.
Test 2:
\definetypeface[iwona][ss][sans] [iwona] [default]
%\definetypeface[iwona][mm][math] [iwona] [default][text=ss]
\setupbodyfont[iwona]
\starttext
foobar
\stoptext
I only comment the math defination line. now
runetime = 0.969
Test 3:
move the three lines to context.rme,
\definetypeface[iwona][ss][sans] [iwona] [default]
\definetypeface[iwona][mm][math] [iwona] [default][text=ss]
\setupbodyfont[iwona]
then rebuild the format.
note we also load the math font. but one thing is clear: Hans said
unlike plain TeX and LaTeX, font tfm is not dumped into ConTeXt
format.
However, at this time we compile
\starttext
foobar
\stoptext
runtime =0.875
I don't know the reason for this problem too
I think XeTeX load math tfms quite fast. (it should be even faster
than otf loading, but in xecontext, this is not true).
Yue Wang
On Tue, May 12, 2009 at 6:16 PM, Taco Hoekwater t...@elvenkind.com wrote:
Hans Hagen wrote:
anyway .. i cannot comment on runtimes as xetex on my windows box runs
too slow (caching issue) and all examples are slow, no matter how i
specify fonts so i will not look into the code till that gets fixed first
The example with the typescript seems logical to me: a typescript does
much work beforehand, so I assume SimSum is loaded multiple times.
I am trying the AdobeSong example as we speak, there surely seems
something wrong there.
Best wishes,
Taco
___
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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
Hans Hagen wrote: Taco Hoekwater wrote: Hans Hagen wrote: anyway .. i cannot comment on runtimes as xetex on my windows box runs too slow (caching issue) and all examples are slow, no matter how i specify fonts so i will not look into the code till that gets fixed first The example with the typescript seems logical to me: a typescript does much work beforehand, so I assume SimSum is loaded multiple times. I am trying the AdobeSong example as we speak, there surely seems something wrong there. let's start with saying that I have no intention to optimize mkii for xetex as we decided some time ago (at the context meeting) that we would For educational purposes: whether you have \definefont[a][file:AdobeSongLight-Std] or \definefont[a][file:AdobeSongLight-Std.otf] makes no difference to context at all. The first makes \a expand into (simplified) \font\internala=[AdobeSongLight-Std] at 12pt\internala the second into \font\internala=[AdobeSongLight-Std.otf] at 12pt\internala but there are no other macro expansion changes at all. You can test this yourself by making two alternative files an adding \loggingall to them, then compare the two logs using diff. As to the reason why one of the two is much slower than the other: I do not know for sure, but I suspect that XeTeX does not cache the (some of) the internals results of font file assignments with explicit extensions. The speed difference is most certainly *not* caused by anything the context macros do. Best wishes, Taco PS As to why \definefont is itself slower than \font: it does not actually define a font \a at a specific size. Instead it defines a macro \a that defines and then selects a font with an internal, temporary name, using the local font size etc. ___ 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 ___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
On Tue, May 12, 2009 at 7:26 PM, Taco Hoekwater t...@elvenkind.com wrote:
Hans Hagen wrote:
Taco Hoekwater wrote:
Hans Hagen wrote:
anyway .. i cannot comment on runtimes as xetex on my windows box runs
too slow (caching issue) and all examples are slow, no matter how i
specify fonts so i will not look into the code till that gets fixed
first
The example with the typescript seems logical to me: a typescript does
much work beforehand, so I assume SimSum is loaded multiple times.
I am trying the AdobeSong example as we speak, there surely seems
something wrong there.
let's start with saying that I have no intention to optimize mkii for
xetex as we decided some time ago (at the context meeting) that we would
For educational purposes: whether you have
\definefont[a][file:AdobeSongLight-Std]
or
\definefont[a][file:AdobeSongLight-Std.otf]
makes no difference to context at all.
The first makes \a expand into (simplified)
\font\internala=[AdobeSongLight-Std] at 12pt\internala
the second into
\font\internala=[AdobeSongLight-Std.otf] at 12pt\internala
but there are no other macro expansion changes at all. You can test
this yourself by making two alternative files an adding \loggingall
to them, then compare the two logs using diff.
As to the reason why one of the two is much slower than the other:
I do not know for sure, but I suspect that XeTeX does not cache
the (some of) the internals results of font file assignments with
explicit extensions. The speed difference is most certainly *not*
caused by anything the context macros do.
disagreed: you can test by yourself that
\font\a=[simsun]
\starttext
\dorecurse{1}{ hello {\a 你好}\par}
\stoptext
runtime: TeXExec | runtime: 2.922
\font\a=[simsun.ttf]
\starttext
\dorecurse{1}{ hello {\a 你好}\par}
\stoptext
runtime: TeXExec | runtime: 2.938
Best wishes,
Taco
PS As to why \definefont is itself slower than \font: it does not
actually define a font \a at a specific size. Instead it defines a
macro \a that defines and then selects a font with an internal,
temporary name, using the local font size etc.
___
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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
Yue Wang wrote:
Thank you, Taco.
currently I found one way to speed up font loading:
\synchronizemathfontsfalse
\let\synchronizetext\relax
\starttypescript[serif] [myzhfont]
\definefontsynonym [Serif] [file:SimSun]
\stoptypescript
\definetypeface [myzhfont] [rm] [serif][myzhfont] [default]
\def\a{\myzhfont}
\dorecurse{1}{{hello {\a 你好}}\par}
\bye
as wolfgang already pointed out, if you want fast fonts you should
define them directly using \definefont
if you disable bits and pieces of the setupbodyfont mechanism you will
eventually run into problems, for instance because \tfd etc are not
defined and your chapter titles etc will behave unexpected (sizes as
well as when mixed with math)
in a regular document you only set up the bodyfont once (not 1
times) and then use \bf, \sl, \itc etc which are pretty fast
TeXExec | runtime: 10.172
much faster, but still far slower than \definefont.
this reminds me another possible bug in ConTeXt:
as mentioned ... we're no talking bugs here but 'features' and side
effects of them
Test1:
\definetypeface[iwona][ss][sans] [iwona] [default]
\definetypeface[iwona][mm][math] [iwona] [default][text=ss]
\setupbodyfont[iwona]
\starttext
foobar
\stoptext
runtime= 6.625. There is a 5 seconds pause after loading
(c:/context/tex/texmf-context/tex/context/base/spec-xet.tex)
But I don't know what xetex is loading.
fonts (like the sans and more noticeably math (6 families * 3 sizes = 18
fonts at least)
Test 2:
\definetypeface[iwona][ss][sans] [iwona] [default]
%\definetypeface[iwona][mm][math] [iwona] [default][text=ss]
\setupbodyfont[iwona]
\starttext
foobar
\stoptext
I only comment the math defination line. now
runetime = 0.969
right .. and as context is supposed to do math (keep in mind that some
symbols come from math anyway) this is expected
Test 3:
move the three lines to context.rme,
\definetypeface[iwona][ss][sans] [iwona] [default]
\definetypeface[iwona][mm][math] [iwona] [default][text=ss]
\setupbodyfont[iwona]
then rebuild the format.
note we also load the math font. but one thing is clear: Hans said
unlike plain TeX and LaTeX, font tfm is not dumped into ConTeXt
format.
well, in this case you probably *did* force them in format; the normal
default font (lm) is not in the format and loading is delayed
However, at this time we compile
\starttext
foobar
\stoptext
runtime =0.875
I don't know the reason for this problem too
I think XeTeX load math tfms quite fast. (it should be even faster
than otf loading, but in xecontext, this is not true).
more needs to be set up ... not only fonts, + some testing + ...
just do a \tracingall before setupbodyfont and you will see
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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
Yue Wang wrote:
\font\a=[simsun]
\starttext
\dorecurse{1}{ hello {\a 你好}\par}
\stoptext
runtime: TeXExec | runtime: 2.922
\font\a=[simsun.ttf]
\starttext
\dorecurse{1}{ hello {\a 你好}\par}
\stoptext
runtime: TeXExec | runtime: 2.938
Please try an otf font and/or actually compare the log files,
as I said.
Best wishes,
Taco
___
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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
Taco Hoekwater wrote:
Yue Wang wrote:
\font\a=[simsun]
\starttext
\dorecurse{1}{ hello {\a 你好}\par}
\stoptext
runtime: TeXExec | runtime: 2.922
\font\a=[simsun.ttf]
\starttext
\dorecurse{1}{ hello {\a 你好}\par}
\stoptext
runtime: TeXExec | runtime: 2.938
Please try an otf font and/or actually compare the log files,
as I said.
also, make sure that the *same* font is used as on my machine there is
no ttf but a simsun.ttc file so it can well be that th efirst call loads
a different font than the suffix call
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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
Hi,
\font\a=[AdobeSongStd-Light.otf]
\starttext
\dorecurse{1}{ hello {\a 你好}\par}
\stoptext
runtime = 3.25
\font\a=[AdobeSongStd-Light]
\starttext
\dorecurse{1}{ hello {\a 你好}\par}
\stoptext
runtime=3.234
Yue Wang
2009/5/12 Taco Hoekwater t...@elvenkind.com:
Yue Wang wrote:
\font\a=[simsun]
\starttext
\dorecurse{1}{ hello {\a 你好}\par}
\stoptext
runtime: TeXExec | runtime: 2.922
\font\a=[simsun.ttf]
\starttext
\dorecurse{1}{ hello {\a 你好}\par}
\stoptext
runtime: TeXExec | runtime: 2.938
Please try an otf font and/or actually compare the log files,
as I said.
Best wishes,
Taco
___
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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
Yue Wang wrote:
\font\a=[simsun]
\starttext
\dorecurse{1}{ hello {\a 你好}\par}
\stoptext
runtime: TeXExec | runtime: 2.922
\font\a=[simsun.ttf]
\starttext
\dorecurse{1}{ hello {\a 你好}\par}
\stoptext
as taco already mentioned there's a problem with xetex caching fonts
in a traditional tex engine (pdftex, xetex) one can say
\font\xxx=blabla
many times but blabla is loaded only once; however, it looks like in the
following case
\font\xxx=blabla.suffix
no caching takes place and as a result you load the font 1 times
(can be seen when you enable a file tracer)
however, memory consumption does grow only in small steps so some
caching takes place (maybe only new id's)
if you define a font grouped {\a ...} the font gets defined each time
(as context has delayed font loading and supports local redefinitions
which is quite handy when using SymbolicNames for fonts) and normally
xetex's internal caching should make that efficient
i would not be surprised if the (forced) name-lookup problems are kind
of related to this
so ... this suffix problem is not related to context at all
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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
Yue Wang wrote: \font\a=[AdobeSongStd-Light] Why? I asked to use \definefont. ___ 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 ___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
2009/5/12 Hans Hagen pra...@wxs.nl:
Yue Wang wrote:
Thank you, Taco.
currently I found one way to speed up font loading:
\synchronizemathfontsfalse
\let\synchronizetext\relax
\starttypescript[serif] [myzhfont]
\definefontsynonym [Serif] [file:SimSun]
\stoptypescript
\definetypeface [myzhfont] [rm] [serif][myzhfont] [default]
\def\a{\myzhfont}
\dorecurse{1}{{hello {\a 你好}}\par}
\bye
as wolfgang already pointed out, if you want fast fonts you should
define them directly using \definefont
I have no speed gain while testing his example.
if you disable bits and pieces of the setupbodyfont mechanism you will
eventually run into problems, for instance because \tfd etc are not
defined and your chapter titles etc will behave unexpected (sizes as
well as when mixed with math)
You are right.
in a regular document you only set up the bodyfont once (not 1
times) and then use \bf, \sl, \itc etc which are pretty fast
for multilingual typesetting this is different.
different fonts will be used for full-width punctuations,
cjk-characters (maybe also splict to ruby, kanji, hangul and hanzi),
cjk-exta, cjk-extb, and latin. for a not-so-long document (100 pages),
switching more than 100times/page is ordinary case.
Especially for educational documents (For example, English text book
for Chinese students)
TeXExec | runtime: 10.172
much faster, but still far slower than \definefont.
this reminds me another possible bug in ConTeXt:
as mentioned ... we're no talking bugs here but 'features' and side
effects of them
ok. this is a feature that I don't like so much...
Test1:
\definetypeface[iwona][ss][sans] [iwona] [default]
\definetypeface[iwona][mm][math] [iwona] [default][text=ss]
\setupbodyfont[iwona]
\starttext
foobar
\stoptext
runtime= 6.625. There is a 5 seconds pause after loading
(c:/context/tex/texmf-context/tex/context/base/spec-xet.tex)
But I don't know what xetex is loading.
fonts (like the sans and more noticeably math (6 families * 3 sizes = 18
fonts at least)
but it's pretty fast on mac (only 1 second delay) on the same machine.
[mac do not use fontconfig for searching system fonts]
Strange uh? Well, I call it Windows features:)
moreover, can you tell me why pdftex load these fonts so fast? (also 6
families * 3 sizes)
Test 2:
\definetypeface[iwona][ss][sans] [iwona] [default]
%\definetypeface[iwona][mm][math] [iwona] [default][text=ss]
\setupbodyfont[iwona]
\starttext
foobar
\stoptext
I only comment the math defination line. now
runetime = 0.969
right .. and as context is supposed to do math (keep in mind that some
symbols come from math anyway) this is expected
ok.
Test 3:
move the three lines to context.rme,
\definetypeface[iwona][ss][sans] [iwona] [default]
\definetypeface[iwona][mm][math] [iwona] [default][text=ss]
\setupbodyfont[iwona]
then rebuild the format.
note we also load the math font. but one thing is clear: Hans said
unlike plain TeX and LaTeX, font tfm is not dumped into ConTeXt
format.
well, in this case you probably *did* force them in format; the normal
default font (lm) is not in the format and loading is delayed
no. I did exactly the same as the default settings do.
you also use :
\setupencoding[default=ec]
\usetypescript[fallback][\defaultencoding] \setupbodyfont[rm,12pt]
in cont-en.tex. also in context.tex:
\setupencoding[default=ec]
\usetypescript[fallback][\defaultencoding]
\setupbodyfont[rm,12pt]
So I am not forcing them into the format. actually the loading of
iwona is delayed to runtime.
However, at this time we compile
\starttext
foobar
\stoptext
runtime =0.875
I don't know the reason for this problem too
I think XeTeX load math tfms quite fast. (it should be even faster
than otf loading, but in xecontext, this is not true).
more needs to be set up ... not only fonts, + some testing + ...
just do a \tracingall before setupbodyfont and you will see
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
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
Hi,
On Tue, May 12, 2009 at 8:26 PM, Taco Hoekwater t...@elvenkind.com wrote:
Yue Wang wrote:
\font\a=[AdobeSongStd-Light]
Why? I asked to use \definefont.
After reading Hans' explanation, I understand what you said now.
\dorecurse{1}{ hello {\font\a=[AdobeSongStd-Light]\a 你好}\par}
is fast while
\dorecurse{1}{ hello {\font\a=[AdobeSongStd-Light.otf]\a 你好}\par}
is slow
Thank you. Will report that to Jonathan Kew.
Yue Wang
___
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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
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 - 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 ___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
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. Yue Wang - 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 ___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
Hi, Hans:
here is the solution to your great feature:
change
\def\defaultfontfile{lmmono10-regular}
in font-ini.mkii to
\def\defaultfontfile{[lmmono10-regular]}
to disable that feature.
Yue Wang
On Tue, May 12, 2009 at 9:59 PM, Yue Wang yuleo...@gmail.com 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.
Yue Wang
-
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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
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
btw, you can try to change the following into
\def\defaultfontfile{file:lmmono10-regular}
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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
Yue Wang wrote:
Hi, Hans:
here is the solution to your great feature:
huh? what great features? what's wrong with the features anyway? you
want a special version that instead prints hundreds of error messages
each and every run because some font is missing which in practice is
harmless?
change
\def\defaultfontfile{lmmono10-regular}
in font-ini.mkii to
\def\defaultfontfile{[lmmono10-regular]}
to disable that feature.
it should be \defaultfontfile{file:lmmono10-regular} (when i played
with that this morning it made not much difference on the test runs here
but the file: prefix does not hurt)
don't use the [ ] syntax which is rather engine specific
i moved all xetex code to a separate file font-xtx now (not sure if that
has side effects due to definition order but don't want to mess up the
mkii code)
but it cannot solve the suffix problem nor the name lookup problems due
to caching
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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
On Tue, May 12, 2009 at 11:02 PM, Hans Hagen pra...@wxs.nl wrote:
Yue Wang wrote:
Hi, Hans:
here is the solution to your great feature:
huh? what great features? what's wrong with the features anyway? you want a
special version that instead prints hundreds of error messages each and
every run because some font is missing which in practice is harmless?
change
\def\defaultfontfile{lmmono10-regular}
in font-ini.mkii to
\def\defaultfontfile{[lmmono10-regular]}
to disable that feature.
it should be \defaultfontfile{file:lmmono10-regular} (when i played with
that this morning it made not much difference on the test runs here but the
file: prefix does not hurt)
There is great difference here (8 sec compare to 1.2 seconds per run)
don't use the [ ] syntax which is rather engine specific
But that line is enclosed in
\ifXeTeX and \endif...
So it will be fine.
i moved all xetex code to a separate file font-xtx now (not sure if that
has side effects due to definition order but don't want to mess up the mkii
code)
I see.
but it cannot solve the suffix problem nor the name lookup problems due to
caching
I already reported that feature/bug to Jonathan Kew
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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
Yue Wang wrote:
\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)
Does that mean that the near-endless font issues with xetex are
now finally fixed?
Cheers,
Taco
___
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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
Yue Wang wrote: 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. if so, then this fc mechanism is pretty messed up as it's just a hash lookup which cna be fast also, it does not explain why simple plain definitions also have a suffix and/or name lookup problem so you'd better make sure that that is fixed too (if only because we cannot be sure of users always using filenames) in the meantime i'll add some lookup caching in the xetex specific context code (costs a bit of extra hash mem but lets not bother about that) 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 ___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
Yue Wang wrote:
On Tue, May 12, 2009 at 11:02 PM, Hans Hagen pra...@wxs.nl wrote:
Yue Wang wrote:
Hi, Hans:
here is the solution to your great feature:
huh? what great features? what's wrong with the features anyway? you want a
special version that instead prints hundreds of error messages each and
every run because some font is missing which in practice is harmless?
change
\def\defaultfontfile{lmmono10-regular}
in font-ini.mkii to
\def\defaultfontfile{[lmmono10-regular]}
to disable that feature.
it should be \defaultfontfile{file:lmmono10-regular} (when i played with
that this morning it made not much difference on the test runs here but the
file: prefix does not hurt)
There is great difference here (8 sec compare to 1.2 seconds per run)
makes no difference here for the big test
\setupbodyfont[myzhfont] \dorecurse{1}{{hello
{\switchtobodyfont[myzhfont] 你好}}\par}
so it's probably also an operating system issue (caching files in mem,
disk access etc)
-
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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
Taco Hoekwater wrote:
Yue Wang wrote:
\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)
Does that mean that the near-endless font issues with xetex are
now finally fixed?
no ... suffix and name lookup remain (but the file: before the fallback
font saves such name lookups so we disguised the 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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
On Tue, May 12, 2009 at 11:22 PM, Hans Hagen pra...@wxs.nl wrote:
Yue Wang wrote:
On Tue, May 12, 2009 at 11:02 PM, Hans Hagen pra...@wxs.nl wrote:
Yue Wang wrote:
Hi, Hans:
here is the solution to your great feature:
huh? what great features? what's wrong with the features anyway? you want
a
special version that instead prints hundreds of error messages each and
every run because some font is missing which in practice is harmless?
change
\def\defaultfontfile{lmmono10-regular}
in font-ini.mkii to
\def\defaultfontfile{[lmmono10-regular]}
to disable that feature.
it should be \defaultfontfile{file:lmmono10-regular} (when i played with
that this morning it made not much difference on the test runs here but
the
file: prefix does not hurt)
There is great difference here (8 sec compare to 1.2 seconds per run)
makes no difference here for the big test
Well, I always split my projects into small pieces so... it really counts.
\setupbodyfont[myzhfont] \dorecurse{1}{{hello
{\switchtobodyfont[myzhfont] 你好}}\par}
so it's probably also an operating system issue (caching files in mem, disk
access etc)
Well, that is possible. But in fact no new font is defined during the
font switching, which is paradoxical.
I will look into that tomorrow.
Please fix the
- lmmono defination
- unicode-letters charclass definations
- mpgraphics displacement bug (or feature...)
- dvipdfmx focus=standard feature
that I reported today.
Thank you. Good night and good luck!
Yue Wang
-
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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
Yue Wang wrote:
On Tue, May 12, 2009 at 11:02 PM, Hans Hagen pra...@wxs.nl wrote:
Yue Wang wrote:
Hi, Hans:
here is the solution to your great feature:
huh? what great features? what's wrong with the features anyway? you want a
special version that instead prints hundreds of error messages each and
every run because some font is missing which in practice is harmless?
change
\def\defaultfontfile{lmmono10-regular}
in font-ini.mkii to
\def\defaultfontfile{[lmmono10-regular]}
to disable that feature.
it should be \defaultfontfile{file:lmmono10-regular} (when i played with
that this morning it made not much difference on the test runs here but the
file: prefix does not hurt)
There is great difference here (8 sec compare to 1.2 seconds per run)
i uploaded a new zip to the website
you can say:
\settrue\tracexetexfonts
as you will see, not that much fonts are loaded; once a font (in
typefaces) is found, it is remembered; for xetex i now added an extra
layer of remembering (the checks) so that misses in lookups might happen
less (it might speed up the MathGamma cases a bit but i didn't notice
much performance gain so it probably depends on other factors as well)
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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
On Tue, May 12, 2009 at 11:41 PM, Hans Hagen pra...@wxs.nl wrote:
Taco Hoekwater wrote:
Yue Wang wrote:
\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)
Does that mean that the near-endless font issues with xetex are
now finally fixed?
no ... suffix and name lookup remain (but the file: before the fallback font
saves such name lookups so we disguised the problem)
no. \definetypeface[foobar][blablabla] \dorecurse{1}{{hello
{\foobar 你好}}\par}
is still very slow. I will look into that tomorrow.
Other problems are solved (why \setupbodyfont[iwona] is slow, why
\definefont[simsun.ttf] is slow, etc.)
Concerning the suffix problem, I already reported that to Jonathan
Kew. I think he will fix that very soon.
Yue Wang
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
___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
Yue Wang wrote: So why XeTeX is spending 6 seconds aimlessly? since ConTeXt asked it to search for a non-existed font. keep in mind that the font (lmmono10-regular) *is* existing, it's ust that xetex cannot find it as it favors names instead of files (and praise yourself happy that it's not looking for lmtypewriter10-regular as some older tex distributions ship that font). 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 ___
Re: [NTG-context] XeConTeXt bug report I: strange benchmark
Hi, Hans:
On Tue, May 12, 2009 at 11:22 PM, Hans Hagen pra...@wxs.nl wrote:
\setupbodyfont[myzhfont] \dorecurse{1}{{hello
{\switchtobodyfont[myzhfont] 你好}}\par}
so it's probably also an operating system issue (caching files in mem, disk
access etc)
After debugging for half an hour in the morning, finally I know why
this is so slow on both XeTeX and pdfTeX.
This problem is not an operating system issue, But a ConTeXt feature.
in font-mkii, you use the following to define a actual font
(\definefontlocal and \definefontglobal):
{\expandafter\xdef\csname#1\endcsname % ! ! ! ! not needed in luatex ! ! ! !
{\noexpand\csname#1:\endcsname
\noexpand\reactivatefont{\somefontname}{\fontfile}}%
For example, in the previous example, it will define a lot of fonts,
like \*myzhfont12ptmmexrm*: , is defined as
\reactivatefont{cmex10}{lmex10}. When define that font, a macro
\*myzhfont12ptmmexrm* is defined to select the \*myzhfont12ptmmexrm* :
font.
\*myzhfont12ptmmexrm* =\csname *myzhfont12ptmmexrm* :\endcsname
\reactivefont{cmex10}{lmex10}
TeX then expand your reactivatefont macros to lmex10 at 12.0pt. So the
\*myzhfont12ptmmexrm*: font will assigned to lmex10 at 12.0pt. This is
quite right for definition.
However, after switching the font, the problems occurs:
it tries to call \*myzhfont12ptmmexrm* macro. the macro then expands to
\csname *myzhfont12ptmmexrm* :\endcsname \reactivefont{cmex10}{lmex10}
then to
\*myzhfont12ptmmexrm* :\reactivefont{cmex10}{lmex10}
and here TeX tries to do the following thing:
TeX select the font \*myzhfont12ptmmexrm*:, which is lmex10 at 12pt,
then *changing* into that font environment in order to *typeset*
\reactivefont. it then expand the macro of reacitve font, but found
nothing to typeset...
what's worse, this will occur on every real fonts in the definition.
So in fact TeX will switching dozens of fonts into the *current* font
for a \switchtobodyfont call, in order to typeset nothing. And
that's why ConTeXt is so slow on typeface changing.
The solution to this bug (or feature?) is quite easy, just use \font
to define the \*myzhfont12ptmmexrm*: font, but pay attention not to
switch the current font to \*myzhfont12ptmmexrm*: . Since it is quite
slow to switch to dozens of font for one \switchtobodyfont call even
in Knuth TeX.
Yue Wang
so it's probably also an operating system issue (caching files in mem, disk
access etc)
-
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
___
