font-syn.lua error

Andreas Harder

21 Nov 2009 21 Nov '09

6:49 p.m.

Hi, if I try to run $ mtxrun --script fonts –reload it ends with: ...text/tex/texmf-context/tex/context/base/font-syn.lua:666: attempt to call field 'data_state' (a nil value) The same with \definefont[test][name:minionpro-regular] \starttext \test Hallo Welt, das ist ein Test \stoptext Greetings, Andreas

Show replies by date

Tim Wraight

21 Nov 21 Nov

10:02 p.m.

...

if I try to run $ mtxrun --script fonts –reload it ends with: ...text/tex/texmf-context/tex/context/base/font-syn.lua:666: attempt to call field 'data_state' (a nil value) Yes, I'm getting a similar error here too: $ mtxrun --script font --list --reload

On 21 Nov 2009, at 18:49, Andreas Harder wrote: produces: ‘.../tex/texmf-context/scripts/context/lua/mtx-fonts.lua:116: attempt to index global 'names' (a nil value)’ MTXrun | current version: 2009.11.21 11:45 Tim

Hans Hagen

22 Nov 22 Nov

12:16 p.m.

Andreas Harder wrote:

...

Hi,

if I try to run $ mtxrun --script fonts –reload it ends with: ....text/tex/texmf-context/tex/context/base/font-syn.lua:666: attempt to call field 'data_state' (a nil value)

that means that you run an old mtxrun (try mtxrun --selfupdate) 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 -----------------------------------------------------------------

Andreas Harder

12:19 p.m.

Am 22.11.2009 um 13:16 schrieb Hans Hagen:

...

Andreas Harder wrote:

...
Hi, if I try to run $ mtxrun --script fonts –reload it ends with: ....text/tex/texmf-context/tex/context/base/font-syn.lua:666: attempt to call field 'data_state' (a nil value)

that means that you run an old mtxrun (try mtxrun –selfupdate)

I've tried it already, the error is still the same … Andreas

Hans Hagen

1:14 p.m.

Andreas Harder wrote:

...

Am 22.11.2009 um 13:16 schrieb Hans Hagen:

...
...
Hi, if I try to run $ mtxrun --script fonts –reload it ends with: ....text/tex/texmf-context/tex/context/base/font-syn.lua:666: attempt to call field 'data_state' (a nil value)

Andreas Harder wrote: that means that you run an old mtxrun (try mtxrun –selfupdate)

I've tried it already, the error is still the same …

and what if you run mtxrun --script font --reload ----------------------------------------------------------------- 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 -----------------------------------------------------------------

Khaled Hosny

2 p.m.

On Sun, Nov 22, 2009 at 02:14:05PM +0100, Hans Hagen wrote:

...

Andreas Harder wrote:

...
Am 22.11.2009 um 13:16 schrieb Hans Hagen:

...
...
Hi, if I try to run $ mtxrun --script fonts –reload it ends with: ....text/tex/texmf-context/tex/context/base/font-syn.lua:666: attempt to call field 'data_state' (a nil value)

Andreas Harder wrote: that means that you run an old mtxrun (try mtxrun –selfupdate)

I've tried it already, the error is still the same …

and what if you run

mtxrun --script font --reload

$ mtxrun --script font --reload ...text/tex/texmf-context/tex/context/base/font-syn.lua:666: attempt to call field 'data_state' (a nil value) -- Khaled Hosny Arabic localiser and member of Arabeyes.org team Free font developer

Hans Hagen

9:19 p.m.

Khaled Hosny wrote:

...

On Sun, Nov 22, 2009 at 02:14:05PM +0100, Hans Hagen wrote:

...
Andreas Harder wrote:

...
Am 22.11.2009 um 13:16 schrieb Hans Hagen:

...
...
Hi, if I try to run $ mtxrun --script fonts –reload it ends with: ....text/tex/texmf-context/tex/context/base/font-syn.lua:666: attempt to call field 'data_state' (a nil value)

Andreas Harder wrote: that means that you run an old mtxrun (try mtxrun –selfupdate) I've tried it already, the error is still the same … and what if you run

mtxrun --script font --reload

$ mtxrun --script font --reload ...text/tex/texmf-context/tex/context/base/font-syn.lua:666: attempt to call field 'data_state' (a nil value)

that line says data_state = resolvers.data_state(), so resolvers has no data_state entry which in turn means that you run an old mtxrun, so maybe you need top copy mtxrun.lua manually to where it currently sits in yout path (as mtxrun) 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

9:26 p.m.

On Nov 22, 2009, at 10:19 PM, Hans Hagen wrote:

...

...
$ mtxrun --script font --reload ...text/tex/texmf-context/tex/context/base/font-syn.lua:666: attempt to call field 'data_state' (a nil value)

that line says

data_state = resolvers.data_state(),

so resolvers has no data_state entry which in turn means that you run an old mtxrun, so maybe you need top copy mtxrun.lua manually to where it currently sits in yout path (as mtxrun)

Hans

Hans, is it possible that you forgot to include the new version of mtxrun.lua in the zip? % diff ~/context/tex/texmf-context/scripts/context/lua/mtxrun.lua ~/context/tex/texmf-osx-intel/bin/mtxrun [no result ==> files are identical] % mtxrun --script fonts --reload ...text/tex/texmf-context/tex/context/base/font-syn.lua:666: attempt to call field 'data_state' (a nil value)

Hans Hagen

10:55 p.m.

Thomas A. Schmitz wrote:

...

On Nov 22, 2009, at 10:19 PM, Hans Hagen wrote:

...
...
$ mtxrun --script font --reload ...text/tex/texmf-context/tex/context/base/font-syn.lua:666: attempt to call field 'data_state' (a nil value) that line says

data_state = resolvers.data_state(),

so resolvers has no data_state entry which in turn means that you run an old mtxrun, so maybe you need top copy mtxrun.lua manually to where it currently sits in yout path (as mtxrun)

Hans

Hans, is it possible that you forgot to include the new version of mtxrun.lua in the zip?

% diff ~/context/tex/texmf-context/scripts/context/lua/mtxrun.lua ~/context/tex/texmf-osx-intel/bin/mtxrun [no result ==> files are identical]

% mtxrun --script fonts --reload ....text/tex/texmf-context/tex/context/base/font-syn.lua:666: attempt to call field 'data_state' (a nil value)

maybe. i'll check it tomorrow morning ----------------------------------------------------------------- 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

25 Nov 25 Nov

7:05 a.m.

On Nov 22, 2009, at 10:19 PM, Hans Hagen wrote:

...

that line says

data_state = resolvers.data_state(),

so resolvers has no data_state entry which in turn means that you run an old mtxrun, so maybe you need top copy mtxrun.lua manually to where it currently sits in yout path (as mtxrun)

Just an afterthought to this problem: I discovered yesterday that the same file behaved quite differently in different viewers. It was a file compiled with the latest beta under linux, luatex 0.44, and with my own fonts. 1. In evince under linux, the file looked fine, no problems were apparent. 2. In Preview under OS X, the file showed only blank pages. 3. In Adobe Reader 9, both under linux and OS X, the file refused to open with a dialogue saying it was damaged and couldn't be repaired. So unfortunately, this is something we have to keep in mind when we test something and say "works here." Best Thomas

luigi scarso

7:15 a.m.

On Wed, Nov 25, 2009 at 8:05 AM, Thomas A. Schmitz wrote:

...

On Nov 22, 2009, at 10:19 PM, Hans Hagen wrote:

...
that line says

data_state = resolvers.data_state(),

so resolvers has no data_state entry which in turn means that you run an old mtxrun, so maybe you need top copy mtxrun.lua manually to where it currently sits in yout path (as mtxrun)

Just an afterthought to this problem: I discovered yesterday that the same file behaved quite differently in different viewers. It was a file compiled with the latest beta under linux, luatex 0.44, and with my own fonts.

1. In evince under linux, the file looked fine, no problems were apparent.

what about xpdf and ghostscript? Can you also try with mupdf ? -- luigi

Thomas A. Schmitz

7:48 a.m.

On Nov 25, 2009, at 8:15 AM, luigi scarso wrote:

...

...
1. In evince under linux, the file looked fine, no problems were apparent. what about xpdf and ghostscript? Can you also try with mupdf ?

That wasn't the point, I was not trying to give a comparative table of pdf-viewers. luatex was buggy, but some viewers displayed the pdf nonetheless. Doesn't make sense to test a dozen viewers because next time around, the subset which does or does not work may be totally different. Thomas

Taco Hoekwater

8:40 a.m.

Thomas A. Schmitz wrote:

...

On Nov 25, 2009, at 8:15 AM, luigi scarso wrote:

...
...
1. In evince under linux, the file looked fine, no problems were apparent. what about xpdf and ghostscript? Can you also try with mupdf ?

mupdf quite often crashes on completely valid pdf documents, effectively making it useless in practice. What's worse: those bugs are hard to fix because some really bad implementation decisions were made. Best wishes, Taco

luigi scarso

8:58 a.m.

ah I've seen it just now On Wed, Nov 25, 2009 at 9:40 AM, Taco Hoekwater wrote:

...

mupdf quite often crashes on completely valid pdf documents, effectively making it useless in practice.

hm bad news,

...

What's worse: those bugs are hard to fix because some really bad implementation decisions were made. What are these decisions ?

-- luigi

Taco Hoekwater

9 a.m.

luigi scarso wrote:

...

ah I've seen it just now On Wed, Nov 25, 2009 at 9:40 AM, Taco Hoekwater wrote:

...
mupdf quite often crashes on completely valid pdf documents, effectively making it useless in practice. hm bad news,

...
What's worse: those bugs are hard to fix because some really bad implementation decisions were made. What are these decisions ?

Using the C stack for recursion is the main problem. Pdfs with a large number of objects (annots) are likely to exhaust the stack, resulting in a hard crash of mupdf. Best wishes, Taco

luigi scarso

9:04 a.m.

On Wed, Nov 25, 2009 at 10:00 AM, Taco Hoekwater wrote:

...

luigi scarso wrote:

Using the C stack for recursion is the main problem. Pdfs with a large number of objects (annots) are likely to exhaust the stack, resulting in a hard crash of mupdf. can we make a good pdf with luatex to check this ?

-- luigi

Taco Hoekwater

10:02 a.m.

luigi scarso wrote:

...

On Wed, Nov 25, 2009 at 10:00 AM, Taco Hoekwater wrote:

...
luigi scarso wrote:

Using the C stack for recursion is the main problem. Pdfs with a large number of objects (annots) are likely to exhaust the stack, resulting in a hard crash of mupdf. can we make a good pdf with luatex to check this ?

I don't see why not, but I'll pass. I have enough to do already. Best wishes, Taco

luigi scarso

5:26 p.m.

On Wed, Nov 25, 2009 at 11:02 AM, Taco Hoekwater wrote:

...

luigi scarso wrote:

...
can we make a good pdf with luatex to check this ?

I don't see why not, but I'll pass. I have enough to do already. Maybe something like this

%\pdfcompresslevel0 %\pdfobjcompresslevel0 \setupinteraction[state=start] \setupcolors[state=start] \starttext \noindent\dorecurse{100000}{% \pagereference[z\recurselevel]Foo\recurselevel\quad } \noindent\dorecurse{100000}{% (see \at{page}[z\recurselevel])\quad } \stoptext No problem with mupdf. -- luigi

luigi scarso

8:54 a.m.

On Wed, Nov 25, 2009 at 8:48 AM, Thomas A. Schmitz wrote:

...

On Nov 25, 2009, at 8:15 AM, luigi scarso wrote:

...
...
1. In evince under linux, the file looked fine, no problems were apparent. what about xpdf and ghostscript? Can you also try with mupdf ?

That wasn't the point, I was not trying to give a comparative table of pdf-viewers. luatex was buggy, but some viewers displayed the pdf nonetheless. Doesn't make sense to test a dozen viewers because next time around, the subset which does or does not work may be totally different.

Not dozen, only 2~3 but code independent .My choices are 1) xpdf (same codebase of luatex) 2)acroread (the most important viewer for pdf ) 3) ghostscript (also used by context ) They are all used / important for TeX community and printing house. mupdf comes from ghostscript team , it's quick but young, it comes with some interesting cmdline tools . Until now I was not able to use it as viewer in everyday use, so I don't know if it's good or not for checking pdf made by luatex I believe that Taco knows mupdf better than me. -- luigi

Alan BRASLAU

10:59 a.m.

On Wednesday 25 November 2009 09:54:36 luigi scarso wrote:

...

...
That wasn't the point, I was not trying to give a comparative table of pdf-viewers. luatex was buggy, but some viewers displayed the pdf nonetheless. Doesn't make sense to test a dozen viewers because next time around, the subset which does or does not work may be totally different.

Not dozen, only 2~3 but code independent .My choices are 1) xpdf (same codebase of luatex) 2)acroread (the most important viewer for pdf ) 3) ghostscript (also used by context ) They are all used / important for TeX community and printing house.

I understood that xpdf has been replaced by poppler, a rewritten PDF rendering library (based originally on xpdf, however I am no authority). This library is the motor behind the viewers evince (gnome) and okular (kde). If this is different from the codebase used by luatex, should luatex eventually be migrated to popplar? Alan

Hans Hagen

11:06 a.m.

Alan BRASLAU wrote:
> On Wednesday 25 November 2009 09:54:36 luigi scarso wrote:
>>> That wasn't the point, I was not trying to give a comparative table of
>>> pdf-viewers. luatex was buggy, but some viewers displayed the pdf
>>> nonetheless. Doesn't make sense to test a dozen viewers because next time
>>> around, the subset which does or does not work may be totally different.
>> Not dozen, only   2~3 but code independent .My choices are
>> 1) xpdf (same codebase of luatex)
>> 2)acroread (the most important  viewer for pdf )
>> 3) ghostscript (also used by context )
>> They are all used / important for TeX community and printing house.
> 
> I understood that xpdf has been replaced by poppler, a rewritten PDF
> rendering library (based originally on xpdf, however I am no authority).
> This library is the motor behind the viewers evince (gnome) and okular (kde).
> 
> If this is different from the codebase used by luatex,
> should luatex eventually be migrated to popplar?

we only need a limited library, no rendering, only loading and 
inclusion, and the problems that were reported are related to rendering

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
-----------------------------------------------------------------

luigi scarso

11:35 a.m.

On Wed, Nov 25, 2009 at 11:59 AM, Alan BRASLAU wrote:

...

On Wednesday 25 November 2009 09:54:36 luigi scarso wrote:

...
Not dozen, only 2~3 but code independent .My choices are 1) xpdf (same codebase of luatex) I understood that xpdf has been replaced by poppler, a rewritten PDF rendering library (based originally on xpdf, however I am no authority). This library is the motor behind the viewers evince (gnome) and okular (kde).

If this is different from the codebase used by luatex, should luatex eventually be migrated to popplar?

Alan

If I understand it correctly, by default luatex is build with code taken from xpdf codebase but you can choose to use your system libpoppler . source/configure: --with-system-xpdf use installed poppler headers and library instead of xpdf (requires pkg-config) -- luigi

Martin Schröder

12:04 p.m.

2009/11/25 Alan BRASLAU :

...

If this is different from the codebase used by luatex, should luatex eventually be migrated to popplar?

Yes, and you can already compile luatex with poppler (texlive does that). For more see my talk at EuroTeX 2009: http://www.oneiros.de/tex/papers/eurotex2009-pdflibs.pdf Best Martin

Hans Hagen

9:34 a.m.

Thomas A. Schmitz wrote:

...

On Nov 25, 2009, at 8:15 AM, luigi scarso wrote:

...
...
1. In evince under linux, the file looked fine, no problems were apparent. what about xpdf and ghostscript? Can you also try with mupdf ?

That wasn't the point, I was not trying to give a comparative table of pdf-viewers. luatex was buggy, but some viewers displayed the pdf nonetheless. Doesn't make sense to test a dozen viewers because next time around, the subset which does or does not work may be totally different.

the bug is that the x scale is zero and acrobat does not like that too much and simply quits rendering (old versions crash); it might be that other viewers then take some default the zero bug is just a side effect of rewriting backend code of luatex and is solved in upcoming 0.46 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 -----------------------------------------------------------------

Alan BRASLAU

7:51 a.m.

On Wednesday 25 November 2009 08:15:48 luigi scarso wrote:

...

On Wed, Nov 25, 2009 at 8:05 AM, Thomas A. Schmitz

wrote:

...
On Nov 22, 2009, at 10:19 PM, Hans Hagen wrote:

Just an afterthought to this problem: I discovered yesterday that the same file behaved quite differently in different viewers. It was a file compiled with the latest beta under linux, luatex 0.44, and with my own fonts.

1. In evince under linux, the file looked fine, no problems were apparent.

what about xpdf and ghostscript? Can you also try with mupdf ?

Maybe unrelated, but maybe a luatex error as well: transparency seems to work correctly when viewed with okular (same library as evince) but not when view with acroread, (including the windows version). Alan

Taco Hoekwater

8:37 a.m.

Alan BRASLAU wrote:

...

Maybe unrelated, but maybe a luatex error as well: transparency seems to work correctly when viewed with okular (same library as evince) but not when view with acroread, (including the windows version).

What is 'not'? If you means that the rest of the page looks crappy, that is known Acrobat behavior. If you want all pages to look the same (crappy) in AR, use \TransparancyHack. If there is no transparancy at all, then there could be a problem within mkiv or luatex. Best wishes, Taco

Alan BRASLAU

11:09 a.m.

On Wednesday 25 November 2009 09:37:11 Taco Hoekwater wrote:

...

Alan BRASLAU wrote:

...
Maybe unrelated, but maybe a luatex error as well: transparency seems to work correctly when viewed with okular (same library as evince) but not when view with acroread, (including the windows version).

What is 'not'? If you means that the rest of the page looks crappy, that is known Acrobat behavior. If you want all pages to look the same (crappy) in AR, use \TransparancyHack.

If there is no transparancy at all, then there could be a problem within mkiv or luatex.

No transparancy, or perhaps total transparancy, my test cannot tell as I am using transparancy in metafun to produce a gradient from .5white to black. Printing the page under acroread then hangs. Alan P.S. looks OK under xpdf.

Taco Hoekwater

11:19 a.m.

Alan BRASLAU wrote:

...

On Wednesday 25 November 2009 09:37:11 Taco Hoekwater wrote:

...
Alan BRASLAU wrote:

...
Maybe unrelated, but maybe a luatex error as well: transparency seems to work correctly when viewed with okular (same library as evince) but not when view with acroread, (including the windows version). What is 'not'? If you means that the rest of the page looks crappy, that is known Acrobat behavior. If you want all pages to look the same (crappy) in AR, use \TransparancyHack.

If there is no transparancy at all, then there could be a problem within mkiv or luatex.

No transparancy, or perhaps total transparancy, my test cannot tell as I am using transparancy in metafun to produce a gradient from .5white to black.

Printing the page under acroread then hangs.

Odd file. Can you send me the source? I would like to play with it

Hans Hagen

12:15 p.m.

Alan BRASLAU wrote:

...

On Wednesday 25 November 2009 09:37:11 Taco Hoekwater wrote:

...
Alan BRASLAU wrote:

...
Maybe unrelated, but maybe a luatex error as well: transparency seems to work correctly when viewed with okular (same library as evince) but not when view with acroread, (including the windows version). What is 'not'? If you means that the rest of the page looks crappy, that is known Acrobat behavior. If you want all pages to look the same (crappy) in AR, use \TransparancyHack.

If there is no transparancy at all, then there could be a problem within mkiv or luatex.

No transparancy, or perhaps total transparancy, my test cannot tell as I am using transparancy in metafun to produce a gradient from .5white to black.

Printing the page under acroread then hangs.

hard to see in a compressed file, next time use \nopdfcompression ----------------------------------------------------------------- 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 -----------------------------------------------------------------

luigi scarso

2:23 p.m.

On Wed, Nov 25, 2009 at 1:15 PM, Hans Hagen wrote:

...

hard to see in a compressed file, next time use \nopdfcompression

It looks a bit strange /opt/mupdf/pdfshow -x compass.pdf xref xref 0 21 0000000001 00255 f (ref=0, ofs=0) 0000000002 00255 f (ref=0, ofs=0) 0000000003 00255 f (ref=0, ofs=0) 0000000004 00255 f (ref=0, ofs=0) 0000000006 00255 f (ref=0, ofs=0) 0000000010 00003 o (ref=1, ofs=0) 0000000007 00255 f (ref=0, ofs=0) 0000000008 00255 f (ref=0, ofs=0) 0000000000 00255 f (ref=0, ofs=0) 0000000010 00000 o (ref=1, ofs=0) 0000013738 00000 n (ref=1, ofs=13829) 0000000010 00001 o (ref=1, ofs=0) 0000000015 00000 n (ref=0, ofs=0) 0000000010 00002 o (ref=1, ofs=0) 0000000010 00005 o (ref=1, ofs=0) 0000000010 00004 o (ref=1, ofs=0) 0000013060 00000 n (ref=0, ofs=0) 0000000010 00006 o (ref=1, ofs=0) 0000000010 00007 o (ref=2, ofs=0) 0000013199 00000 n (ref=2, ofs=0) 0000000000 00000 n (ref=1, ofs=14396) I have made a zip with all objs decompressed in attachment. -- luigi

Hans Hagen

12:19 p.m.

Alan BRASLAU wrote:

...

On Wednesday 25 November 2009 09:37:11 Taco Hoekwater wrote:

...
Alan BRASLAU wrote:

...
Maybe unrelated, but maybe a luatex error as well: transparency seems to work correctly when viewed with okular (same library as evince) but not when view with acroread, (including the windows version). What is 'not'? If you means that the rest of the page looks crappy, that is known Acrobat behavior. If you want all pages to look the same (crappy) in AR, use \TransparancyHack.

If there is no transparancy at all, then there could be a problem within mkiv or luatex.

No transparancy, or perhaps total transparancy, my test cannot tell as I am using transparancy in metafun to produce a gradient from .5white to black.

a ca of 0.0055 is not that much but hard to track without source ----------------------------------------------------------------- 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 -----------------------------------------------------------------

luigi scarso

5:30 p.m.

On Wed, Nov 25, 2009 at 12:09 PM, Alan BRASLAU wrote:

...

No transparancy, or perhaps total transparancy, my test cannot tell as I am using transparancy in metafun to produce a gradient from .5white to black.

Printing the page under acroread then hangs.

Alan

P.S. looks OK under xpdf.

mupdf shows it completely different -- luigi

Hans Hagen

5:44 p.m.

luigi scarso wrote:

...

On Wed, Nov 25, 2009 at 12:09 PM, Alan BRASLAU wrote:

...
No transparancy, or perhaps total transparancy, my test cannot tell as I am using transparancy in metafun to produce a gradient from .5white to black.

Printing the page under acroread then hangs.

Alan

P.S. looks OK under xpdf.

mupdf shows it completely different

my experience is that there are only a few viewers capable of dealing with transparencies (wrong clipping, wrong colors, etc) 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 -----------------------------------------------------------------

Taco Hoekwater

6:18 p.m.

Hans Hagen wrote:

...

luigi scarso wrote:

...
On Wed, Nov 25, 2009 at 12:09 PM, Alan BRASLAU wrote:

...
No transparancy, or perhaps total transparancy, my test cannot tell as I am using transparancy in metafun to produce a gradient from .5white to black.

Printing the page under acroread then hangs.

Alan

P.S. looks OK under xpdf.

mupdf shows it completely different

I believe it is safe to say that that rendering is quite wrong. ;)

...

my experience is that there are only a few viewers capable of dealing with transparencies (wrong clipping, wrong colors, etc)

Same here. And actually, xpdf often does a better job than acroread (I suspect that the implementation of the colormodel AR switches to in that case is less-than-perfect) Best wishes, Taco

Hans Hagen

6:22 p.m.

Taco Hoekwater wrote:

...

Same here. And actually, xpdf often does a better job than acroread (I suspect that the implementation of the colormodel AR switches to in that case is less-than-perfect)

also, acrobat has this 'simulate paper' mechanism that influences the rendering 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 -----------------------------------------------------------------

luigi scarso

7:27 p.m.

On Wed, Nov 25, 2009 at 7:18 PM, Taco Hoekwater wrote:

...

I believe it is safe to say that that rendering is quite wrong. ;)

The problem is that pratically this pdf is wrong because Acroread is not able to print. AR also shows something different from xpdf , gs shows the same of AR too mupdf show something completely different, and I believe from experience that xpdf is right, but at this point the only thing that I care is to understand what is wrong with AR given that xpdf is right. The only solution is to uncompress and study the pdf and the source -- which we don't have . mupdf tools, xpdf tools, and gs can help in this: it seems that xref is a bit messy, so it can be a problem of metapost too, or maybe not at all. In this situation I don't care about poppler, evince, okular, foxit etc -- all marvelous program, but they can't help more than the others. -- luigi

Hans Hagen

26 Nov 26 Nov

10:33 a.m.

luigi scarso wrote:

...

On Wed, Nov 25, 2009 at 7:18 PM, Taco Hoekwater wrote:

...
I believe it is safe to say that that rendering is quite wrong. ;)

The problem is that pratically this pdf is wrong because Acroread is not able to print.

AR also shows something different from xpdf , gs shows the same of AR too mupdf show something completely different, and I believe from experience that xpdf is right, but at this point the only thing that I care is to understand what is wrong with AR given that xpdf is right. The only solution is to uncompress and study the pdf and the source -- which we don't have . mupdf tools, xpdf tools, and gs can help in this: it seems that xref is a bit messy, so it can be a problem of metapost too, or maybe not at all.

as it concerns an older luatex ... it's probably the zero xscale ... 0 0 0 1 0 0 cm makes acrobat unhappy ----------------------------------------------------------------- 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 -----------------------------------------------------------------

luigi scarso

11:50 p.m.

On Wed, Nov 25, 2009 at 12:09 PM, Alan BRASLAU wrote:

...

No transparancy, or perhaps total transparancy, my test cannot tell as I am using transparancy in metafun to produce a gradient from .5white to black.

Printing the page under acroread then hangs.

Try it again with latest luatex (0.46) , and then # acroread -toPostScript -size 108x108 -expand compass.pdf # ps2pdf14 compass.ps b.pdf Now you should be able to print the "AR version" of compass.pdf (which is not what you actually see with xpdf) Warning: compass.ps ~ 25M For a rough version of compass.pdf # pstopdf -paper match compass.pdf # ps2pdf14 compass.ps c.pdf and now AR should be display it ok -- luigi

Taco Hoekwater

25 Nov 25 Nov

7:20 a.m.

Thomas A. Schmitz wrote:

...

Just an afterthought to this problem: I discovered yesterday that the same file behaved quite differently in different viewers. It was a file compiled with the latest beta under linux, luatex 0.44, and with my own fonts.

Sounds like this bug in 0.44 that was fixed already: Bug fixes in 0.45: .... * Remove spurious newlines in the output pdf that could be the result of using \pdfximage for an included pdf figure too early. Best wishes, Taco

Thomas A. Schmitz

7:46 a.m.

On Nov 25, 2009, at 8:20 AM, Taco Hoekwater wrote:

...

Sounds like this bug in 0.44 that was fixed already:

Bug fixes in 0.45:

Yes, the bug has been fixed, and I should have mentioned that; I just wanted to point out that tests may be sometimes deceptive: when I see an empty pdf in preview and someone else runs the test file with evince, his first reaction will probably be "runs OK here, must be a misconfiguration in your installtion." Thomas

Hans Hagen

9:36 a.m.

Thomas A. Schmitz wrote:

...

On Nov 22, 2009, at 10:19 PM, Hans Hagen wrote:

...
that line says

data_state = resolvers.data_state(),

so resolvers has no data_state entry which in turn means that you run an old mtxrun, so maybe you need top copy mtxrun.lua manually to where it currently sits in yout path (as mtxrun)

Just an afterthought to this problem: I discovered yesterday that the same file behaved quite differently in different viewers. It was a file compiled with the latest beta under linux, luatex 0.44, and with my own fonts.

1. In evince under linux, the file looked fine, no problems were apparent.

2. In Preview under OS X, the file showed only blank pages.

3. In Adobe Reader 9, both under linux and OS X, the file refused to open with a dialogue saying it was damaged and couldn't be repaired.

So unfortunately, this is something we have to keep in mind when we test something and say "works here."

yes, it would be nice to have a document that includes all such bug triggers, but we need a volunteer for that (not context bugs, but graphical rendering issues) 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 -----------------------------------------------------------------

Andreas Harder

22 Nov 22 Nov

2:04 p.m.

Am 22.11.2009 um 14:14 schrieb Hans Hagen:

...

Andreas Harder wrote:

...
Am 22.11.2009 um 13:16 schrieb Hans Hagen:

...
...
Hi, if I try to run $ mtxrun --script fonts –reload it ends with: ....text/tex/texmf-context/tex/context/base/font-syn.lua:666: attempt to call field 'data_state' (a nil value)

Andreas Harder wrote: that means that you run an old mtxrun (try mtxrun –selfupdate) I've tried it already, the error is still the same …

and what if you run

mtxrun --script font –reload

Sorry, still there! Andreas

Mojca Miklavec

1:41 p.m.

On Sat, Nov 21, 2009 at 19:49, Andreas Harder wrote:

...

Hi,

if I try to run $ mtxrun --script fonts –reload it ends with: ...text/tex/texmf-context/tex/context/base/font-syn.lua:666: attempt to call field 'data_state' (a nil value)

What operating system? I don't know if that can be a problem, but some platforms don't have LuaTeX beta-0.45.0 yet (freebsd, linux and linux-ppc; if you are on Mac, you can try to update once again). Mojca

Khaled Hosny

1:59 p.m.

On Sun, Nov 22, 2009 at 02:41:08PM +0100, Mojca Miklavec wrote:

...

On Sat, Nov 21, 2009 at 19:49, Andreas Harder wrote:

...
Hi,

if I try to run $ mtxrun --script fonts –reload it ends with: ...text/tex/texmf-context/tex/context/base/font-syn.lua:666: attempt to call field 'data_state' (a nil value)

What operating system?

I don't know if that can be a problem, but some platforms don't have LuaTeX beta-0.45.0 yet (freebsd, linux and linux-ppc; if you are on Mac, you can try to update once again).

I get the same error with both 0.44 and 0.45 on Linux. -- Khaled Hosny Arabic localiser and member of Arabeyes.org team Free font developer

Andreas Harder

2:09 p.m.

Am 22.11.2009 um 14:41 schrieb Mojca Miklavec:

...

On Sat, Nov 21, 2009 at 19:49, Andreas Harder wrote:

...
Hi,

if I try to run $ mtxrun --script fonts –reload it ends with: ...text/tex/texmf-context/tex/context/base/font-syn.lua:666: attempt to call field 'data_state' (a nil value)

What operating system?

I'm on OS-X 10.6 and using the newest beta.

...

I don't know if that can be a problem, but some platforms don't have LuaTeX beta-0.45.0 yet (freebsd, linux and linux-ppc; if you are on Mac, you can try to update once again).

I tired again, the result is the same error. If I run the test file from my initial post: \definefont[test][name:minionpro-regular] % font is not in TeX-tree \starttext \test Hallo Welt, das ist ein Test \stoptext the error message is more verbose, perhaps it can help. ! LuaTeX error ...text/tex/texmf-context/tex/context/base/font-syn.lua:666: attempt to call field 'data_state' (a nil value) stack traceback: ...text/tex/texmf-context/tex/context/base/font-syn.lua:666: in function 'resetdata' ...text/tex/texmf-context/tex/context/base/font-syn.lua:671: in function 'identify' ...text/tex/texmf-context/tex/context/base/font-syn.lua:696: in function 'load' ...text/tex/texmf-context/tex/context/base/font-syn.lua:707: in function 'load' ...text/tex/texmf-context/tex/context/base/font-syn.lua:844: in function 'resolve' ...text/tex/texmf-context/tex/context/base/font-def.lua:243: in function 'r' ...text/tex/texmf-context/tex/context/base/font-def.lua:270: in function 'resolve' ...text/tex/texmf-context/tex/context/base/font-def.lua:574: in function 'read' ...text/tex/texmf-context/tex/context/base/font-ctx.lua:359: in function 'command_2' <main ctx instance>:1: in main chunk. \lowleveldefinefont ...dimexpr \textface \relax )} \edef \somefontspec {at \s... \dododefinefont ...inefont {#2}\rawfontidentifier \csname \rawfontidentifier... l.5 \test Hallo Welt, das ist ein Test Greetings Andreas

Wolfgang Schuster

2:15 p.m.

Am 22.11.2009 um 15:09 schrieb Andreas Harder:

...

Am 22.11.2009 um 14:41 schrieb Mojca Miklavec:

...
What operating system?

I'm on OS-X 10.6 and using the newest beta.

had you done luatools --selfupdate mtxrun --selfupdate Wolfgang

Andreas Harder

2:26 p.m.

Am 22.11.2009 um 15:15 schrieb Wolfgang Schuster:

...

Am 22.11.2009 um 15:09 schrieb Andreas Harder:

...
Am 22.11.2009 um 14:41 schrieb Mojca Miklavec:

...
What operating system?

I'm on OS-X 10.6 and using the newest beta.

had you done

luatools --selfupdate mtxrun –selfupdate

Yes! And I tried to delete the cache, the binaries, etc. and updated again. It works fine with Latin Modern and TeX Gyre fonts or if I put the font in the directory of the source file and define it without 'name:'. Andreas

Bernhard Rosensteiner

2:51 p.m.

Hello, same problem here exactly as described by Andreas (and reported in: http://archive.contextgarden.net/message/20091122.111218.3b9a921f.en.html). best regards Bernhard Am 22.11.2009 um 15:26 schrieb Andreas Harder:

...

Am 22.11.2009 um 15:15 schrieb Wolfgang Schuster:

...
Am 22.11.2009 um 15:09 schrieb Andreas Harder:

...
Am 22.11.2009 um 14:41 schrieb Mojca Miklavec:

...
What operating system?

I'm on OS-X 10.6 and using the newest beta.

had you done

luatools --selfupdate mtxrun –selfupdate

Yes! And I tried to delete the cache, the binaries, etc. and updated again. It works fine with Latin Modern and TeX Gyre fonts or if I put the font in the directory of the source file and define it without 'name:'.

Andreas ___________________________________________________________________________________ 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________

5505

Age (days ago)

5510

Last active (days ago)

List overview

Download

47 comments

12 participants

participants (12)

Alan BRASLAU
Andreas Harder
Bernhard Rosensteiner
Hans Hagen
Khaled Hosny
luigi scarso
Martin Schröder
Mojca Miklavec
Taco Hoekwater
Thomas A. Schmitz
Tim Wraight
Wolfgang Schuster