XeTeX and font-selection problems
Hello Hans, There's something weird going on during XeTeX's font selection: fonts : fails 1a: "lmroman12-regular:script=latn;language=dflt;+liga; +kern;mapping=tex-text;mapping=tex-text;" (nullfont) fonts : succeeds 1b: "[lmroman12-regular]:script=latn;language=dflt;+ liga;+kern;mapping=tex-text;mapping=tex-text;" ("[lmroman12-regular]:script=lat n;language=dflt;+liga;+kern;mapping=tex-text;mapping=tex-text;") fonts : fails 1a: "rm-lmr7" (nullfont) fonts : fails 1b: "[rm-lmr7]" (nullfont) fonts : fails 1a: "rm-lmr9" (nullfont) fonts : fails 1b: "[rm-lmr9]" (nullfont) which then results in systems : end file smalltest at line 13 ) stdin -> smalltest.pdf [1] ** WARNING ** Invalid CMap ** ERROR ** pdf_ref_obj(): passed invalid object. Output file removed. Output written on smalltest.pdf (1 page). Transcript written on smalltest.log. TeXExec | runtime: 10.645827 (Well, "errare humanum est: "I would understand that ConTeXt generates an error from time to time, but not that it's lying about it with "Output written on smalltest.pdf" :) It is possible, that the new version of XeTeX solves that problem (Jonathan promised to look into the problems you complained about some time ago), but I still use the version from TeX Live at the moment. It might make sense to try yet the third option without any quotes around, and generate the error if font doen't exist. Is there any chance to remove blank lines between font tests? (The log file looks really ugly now, but well ...) Mojca
(Well, "errare humanum est: "I would understand that ConTeXt generates an error from time to time, but not that it's lying about it with "Output written on smalltest.pdf" :)
It's actually XeTeX's fault: it doesn't take the return status of xdvipdfmx into account and says “Output written to ...” whatever the result of xdvipdfmx; you may remember Jonathan explained that to the XeTeX list. I have no idea if this is now fixed in XeTeX. As for the other problem you reported this afternoon (Metapost is not run when using \startMPcode in a XeTeX file), I'm now certain the general problem is the same: because ConTeXt tries hard to find some fonts (\xetextempfont), it generates errors in \batchmode, so the XeTeX run exits with a non-zero return code, and TeXExec thinks the compilation has failed, so it doesn't try to run Metapost as it should; I have made tests with a late July version on my computer where all this doesn't happen (2007.07.25 12:35). I guess it's time for the ConTeXt developers to start over that little discussion we had with the XeTeX developer(s) :-) Arthur
Arthur Reutenauer wrote:
(Well, "errare humanum est: "I would understand that ConTeXt generates an error from time to time, but not that it's lying about it with "Output written on smalltest.pdf" :)
It's actually XeTeX's fault: it doesn't take the return status of xdvipdfmx into account and says “Output written to ...” whatever the result of xdvipdfmx; you may remember Jonathan explained that to the XeTeX list.
I have no idea if this is now fixed in XeTeX.
As for the other problem you reported this afternoon (Metapost is not run when using \startMPcode in a XeTeX file), I'm now certain the general problem is the same: because ConTeXt tries hard to find some fonts (\xetextempfont), it generates errors in \batchmode, so the XeTeX run exits with a non-zero return code, and TeXExec thinks the compilation has failed, so it doesn't try to run Metapost as it should; I have made tests with a late July version on my computer where all this doesn't happen (2007.07.25 12:35).
I guess it's time for the ConTeXt developers to start over that little discussion we had with the XeTeX developer(s) :-)
hm, we use batchmode to catch an non found font so that we can look further; i would not expect xetex to quit then 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 -----------------------------------------------------------------
Hans Hagen wrote:
I guess it's time for the ConTeXt developers to start over that little discussion we had with the XeTeX developer(s) :-)
hm, we use batchmode to catch an non found font so that we can look further; i would not expect xetex to quit then
You misunderstand, it is texexec that does the quitting. I've seen this before, but forgot about it. The problem is that whenever tex sees an error, it's return value changes from zero to non-zero. It has been like that since (at least) the emtex days, with higher return value numbers indicating ever more serious issues that were encountered. The immediate problem is that the non-zero return makes texexec think that xetex has failed completely. That is not true, nor is it xetex-specific. We should probably see if we (the tex developers) can reach an agreement about how to decide if a font exists without raising an error, but in the mean time it is maybe best to ignore return values from engines as long as the expected output file is there (or forget about the nice font trick). Best wishes, Taco
Taco Hoekwater wrote:
Hans Hagen wrote:
I guess it's time for the ConTeXt developers to start over that little discussion we had with the XeTeX developer(s) :-)
hm, we use batchmode to catch an non found font so that we can look further; i would not expect xetex to quit then
You misunderstand, it is texexec that does the quitting.
I've seen this before, but forgot about it. The problem is that whenever tex sees an error, it's return value changes from zero to non-zero. It has been like that since (at least) the emtex days, with higher return value numbers indicating ever more serious issues that were encountered.
The immediate problem is that the non-zero return makes texexec think that xetex has failed completely. That is not true, nor is it xetex-specific.
We should probably see if we (the tex developers) can reach an agreement about how to decide if a font exists without raising an error, but in the mean time it is maybe best to ignore return values from engines as long as the expected output file is there (or forget about the nice font trick).
tex.rb line 1933 : ok = runtex(File.suffixed(if dummyfile || forcexml then rawbase else rawname end,jobsuffix)) if getvariable('engine') == "xetex" then ok = true end so, xetex runs are always valid now (at least till we have a solution) ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
participants (4)
-
Arthur Reutenauer -
Hans Hagen -
Mojca Miklavec -
Taco Hoekwater