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
Gr
On 21 Nov 2009, at 18:49, Andreas Harder wrote:
> 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
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
-
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 mtxr
Andreas Harder wrote:
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 o
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
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 'd
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:
>>
>>> 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.
Am 22.11.2009 um 14:14 schrieb Hans Hagen:
> Andreas Harder wrote:
>> 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 t
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 val
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
___
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 –selfu
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.
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:
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:66
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 dat
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
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
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 c
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 alre
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
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,
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 d
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, tha
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
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
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
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 implementa
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 t
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-view
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
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 lu
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 s
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
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
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 v
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 l
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
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 v
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 v
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=sta
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
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 un
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.
Al
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
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 sho
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 sa
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.4
47 matches
Mail list logo
