Taco Hoekwater wrote:

Mkiv has an interface for virtual math, but I am not sure whether that also works for text fonts (not do I know how, if so). If it does not yet but could be made to do so, then that would be a very useful extension to the font fallbacks...

the general font fallbacks mechanism (definefontfallback cum suis) can be used as one can remap ranges as well as individual characters 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 -----------------------------------------------------------------

Thomas A. Schmitz wrote:

On Oct 1, 2009, at 7:55 PM, Hans Hagen wrote:

...

...

Mkiv has an interface for virtual math, but I am not sure whether that also works for text fonts (not do I know how, if so). If it does not yet but could be made to do so, then that would be a very useful extension to the font fallbacks...

the general font fallbacks mechanism (definefontfallback cum suis) can be used as one can remap ranges as well as individual characters

Hans

Well, my problem is: want to remap ! to dotbelowcomb, AND I want this taken from a fallback font when the font doesn't have it. This doesn't work; I get errors about "invalid glyph index."

hm, weird ... example ... ----------------------------------------------------------------- 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 -----------------------------------------------------------------

Hi,

luatex: ../../../source/texk/web2c/luatexdir/tex/printing.c:266: print: Assertion `c < 256' failed. [329.327MTXrun | fatal error, no return code, message: luatex: execution interrupted

A quick glance at the code, shows it's in the following part: /* An entire string is output by calling |print|. Note that if we are outputting the single standard ASCII character \.c, we could call |print("c")|, since |"c"=99| is the number of a single-character string, as explained above. But |print_char("c")| is quicker, so \TeX\ goes directly to the |print_char| routine when it knows that this is safe. (The present implementation assumes that it is always safe to print a visible ASCII character.) @^system dependencies@> The first 256 entries above the 17th unicode plane are used for a special trick: when \TeX\ has to print items in that range, it will instead print the character that results from substracting 0x110000 from that value. This allows byte-oriented output to things like \.{\\specials} and \.{\\pdfliterals}. Todo: Perhaps it would be useful to do the same substraction while typesetting. */ void print(integer s) { /* prints string |s| */ ... } else if (s >= 0x110000) { int c = s - 0x110000; assert(c < 256); print_char(c); } else { ... } It seems the second comment block talks about the code in which the error occurs. It also seems that this is either caused by some very high unicode character that's printed, or some invalid (uninitialized?) value is passed to print(). Do you think you could compile luatex with CFLAGS=-g, and run it in gdb to get a backtrace? That might help to see where this comes from... Gr. Matthijs

On Thu, Oct 15, 2009 at 4:09 PM, Matthijs Kooijman wrote:

Hi,

...

luatex: ../../../source/texk/web2c/luatexdir/tex/printing.c:266: print: Assertion `c < 256' failed. [329.327MTXrun | fatal error, no return code, message: luatex: execution interrupted

A quick glance at the code, shows it's in the following part:

 /*  An entire string is output by calling |print|. Note that if we are outputting  the single standard ASCII character \.c, we could call |print("c")|, since  |"c"=99| is the number of a single-character string, as explained above. But  |print_char("c")| is quicker, so \TeX\ goes directly to the |print_char|  routine when it knows that this is safe. (The present implementation  assumes that it is always safe to print a visible ASCII character.)  @^system dependencies@>

 The first 256 entries above the 17th unicode plane are used for a  special trick: when \TeX\ has to print items in that range, it will  instead print the character that results from substracting 0x110000  from that value. This allows byte-oriented output to things like  \.{\\specials} and \.{\\pdfliterals}. Todo: Perhaps it would be useful  to do the same substraction while typesetting.  */

 void print(integer s)  {                               /* prints string |s| */  ...              } else if (s >= 0x110000) {                  int c = s - 0x110000;                  assert(c < 256);                  print_char(c);              } else {  ...  }

It seems the second comment block talks about the code in which the error occurs. It also seems that this is either caused by some very high unicode character that's printed, or some invalid (uninitialized?) value is passed to print().

Do you think you could compile luatex with CFLAGS=-g, and run it in gdb to get a backtrace? That might help to see where this comes from...

changing STRIP_LUATEX=TRUE in STRIP_LUATEX=FALSE in build.sh isn't enough ? -- luigi

Hi luigi,

...

Do you think you could compile luatex with CFLAGS=-g, and run it in gdb to get a backtrace? That might help to see where this comes from...

changing STRIP_LUATEX=TRUE in STRIP_LUATEX=FALSE in build.sh isn't enough ?

I don't know the luatex build system, I just posted general instructions :-) Gr. Matthijs

On Thursday 15 October 2009 16:36:01 luigi scarso wrote:

On Thu, Oct 15, 2009 at 4:32 PM, Matthijs Kooijman wrote:

...

Hi luigi,

...

...

Do you think you could compile luatex with CFLAGS=-g, and run it in gdb to get a backtrace? That might help to see where this comes from...

changing STRIP_LUATEX=TRUE in STRIP_LUATEX=FALSE in build.sh isn't enough ?

I don't know the luatex build system, I just posted general instructions :-)

pretty simple, on linux: download source,uncompress and $>./build.sh

Not so easy: I have never compiled luatex before! $ svn checkout http://foundry.supelec.fr/svn/luatex (downloads 3.9G, including all beta versions in tag/) $ cd trunk $ ./build.sh --nostrip ... libtool: link: gcc lib/lib.a /home/local/src/luatex/trunk/build/texk/kpathsea/.libs/libkpathsea.a -lm lib/lib.a(main.o): In function `main': /home/local/src/luatex/trunk/build/texk/web2c/lib/../../../../source/texk/web2c/lib/main.c:26: undefined reference to `mainbody' collect2: ld returned 1 exit status make[5]: *** [tangleboot] Error 1 make[5]: Leaving directory `/home/local/src/luatex/trunk/build/texk/web2c' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/local/src/luatex/trunk/build/texk/web2c' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/local/src/luatex/trunk/build/texk/web2c' make[2]: *** [subtexk] Error 1 make[2]: Leaving directory `/home/local/src/luatex/trunk/build/texk' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/local/src/luatex/trunk/build/texk' make: *** [all-recursive] Error 1 luatex binary not stripped ls: cannot access build/texk/web2c/luatex: No such file or directory $ So I do not yet have a compiled, unstripped version of luatex. Alan