Re: [NTG-context] counter reseting at every heading

2012-05-18 Thread Aditya Mahajan

On Fri, 18 May 2012, Hans Hagen wrote:


On 18-5-2012 15:00, Peter Schorsch wrote:

Hi,

I realized yesterday that my counter for the module does not reset
itself as before. What I need is a counter that resets after each
heading (chapter, section, subsection, subsubsection and so on).

This is what I know about counter reseting at the moment:

\definecounter[ParagraphNumber][prefix=no,way=bysection]
- way=bychapter: reseting counter at every chapter (default)
- way=bysection: reseting counter at every section (not at chapters)
- way={bychapter,bysection,bysubsection,bysubsubsection}: does not work

\setuphead[chapter,section,subsection,subsubsection][after={\resetcounter[ParagraphNumber]}]
does work but it messes with the distance between heading and normal
text.

What is the correct/best way to make the counter reseting every
heading without messing around?


we probably need something byheader or maybe indeed a comma separated list


Or perhaps a \c!setups key for \setuphead commands.

Another option is to add spacebefore and spaceafter keys to set distance, 
rather than the before and after keys. A few commands use spacebefore and 
spaceafter, and it will be nice if all commands used them.


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


[NTG-context] References to itemize items

2012-05-18 Thread Rogers, Michael K
Hi,

Under the beta version (ConTeXt  ver: 2012.05.14 16:00 MKIV  fmt: 2012.5.16), 
item numbers in references (with \in[..]) are not converted automatically in 
the way they used to be done under last year's "current" ConTeXt.  I have 
macros that do something like below that no longer work.  The level two items 
are converted to letters, but references to them appear as unconverted numbers. 
 Is there a way to convert them?

\setupitemgroup[itemize][1][n]
\setupitemgroup[itemize][2][a]
\starttext
\startitemize %level 1
\item One
\startitemize %level 2
\item AA \item[BB] BB
\stopitemize\stopitemize
In BB = \in[BB] (used to print b, not 2)
\stoptext


Thanks,

Michael



This e-mail message (including any attachments) is for the sole use of
the intended recipient(s) and may contain confidential and privileged
information. If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution
or copying of this message (including any attachments) is strictly
prohibited.

If you have received this message in error, please contact
the sender by reply e-mail message and destroy all copies of the
original message (including attachments).
___
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
___


Re: [NTG-context] Testing TeX Live 2012

2012-05-18 Thread Marco Pessotto
Mojca Miklavec  writes:

> You can try to checkout revision 26300 from TeX Live repository. That
> should give you a good reference.
> http://tug.org/svn/texlive?view=revision&revision=26301
> [...]
> If you could also try to build revision 26300 with debugging symbols
> (and possibly try to upload the binary somewhere, so that others could
> try as well), that might help. I either have or can try to install a
> virtual machine with i386-linux, but building TeX Live in virtual
> machine will take forever, so having a working binary with all
> debugging symbols could help. (I'm not 100% sure if the binary for mac
> has been compiled before or after poppler update.)

The crashy binary with debug symbols is here:

http://theanarchistlibrary.org/docs/luatex-crash-unstripped.tar.gz

Sha1sum (of the binary inside the tgz):

e092818935b3ea109380409b5fa9fc3ee8f58b71  luatex




 revision 26300 =

luatex --credits
This is LuaTeX, Version beta-0.70.1-2012051819 (TeX Live 2012)
[...]
Compiled with libpng 1.5.10; using libpng 1.5.10
Compiled with zlib 1.2.7; using zlib 1.2.7
Compiled with poppler version 0.18.4

Same crash. bt full at the end of this mail, but there's nothing new, I think.

Any revision other revision I can pick to pinpoint where the problem started?



> If you like debugging, you could set a few breakpoints in the
> following lines that work with poststruct:

I don't have the slightest idea of how to do it. I can do it if you
guide me.

> ./texk/web2c/luatexdir/lua/lpdflib.c:pdf_set_pos(static_pdf,
> static_pdf->posstruct->pos);
> ./texk/web2c/luatexdir/lua/lpdflib.c:(void)
> calc_pdfpos(static_pdf->pstruct, static_pdf->posstruct->pos);
> ./texk/web2c/luatexdir/lua/lpdflib.c:(void)
> calc_pdfpos(static_pdf->pstruct, static_pdf->posstruct->pos);
> ./texk/web2c/luatexdir/lua/lpdflib.c:lua_pushnumber(L,
> static_pdf->posstruct->pos.h);
> ./texk/web2c/luatexdir/lua/lpdflib.c:lua_pushnumber(L,
> static_pdf->posstruct->pos.v);
> ./texk/web2c/synctexdir/synctex-luatex.h:#define SYNCTEX_CURV
> (dimen_par(page_height_code)-static_pdf->posstruct->pos.v)
> ./texk/web2c/synctexdir/synctex-luatex.h:#define SYNCTEX_CURH
> static_pdf->posstruct->pos.h
>
> and compare behaviour of old & new luatex. But that's just a blind guess.
>
> Mojca

Backtrace:

/media/data/melmoth/progetti/texlive2012/bin/i386-linux/luatex 
--fmt="/media/data/melmoth/progetti/texlive2012/texmf-var/luatex-cache/context/2448223e6631addb83df348d74153606/formats/cont-en"
 
--lua="/media/data/melmoth/progetti/texlive2012/texmf-var/luatex-cache/context/2448223e6631addb83df348d74153606/formats/cont-en.lui"
 --backend="pdf" "./ciao.tex"

Program received signal SIGSEGV, Segmentation fault.
0x0813e713 in getpdf (L=0x88b8158) at 
../../../texk/web2c/luatexdir/lua/lpdflib.c:615
615 lua_pushnumber(L, static_pdf->posstruct->pos.h);
#0  0x0813e713 in getpdf (L=0x88b8158) at 
../../../texk/web2c/luatexdir/lua/lpdflib.c:615
#1  0x082c9a65 in luaD_precall (L=0x88b8158, func=0xaf453fc, nresults=1) at 
../../../texk/web2c/luatexdir/lua51/ldo.c:319
#2  0x082c9ca8 in luaD_call (L=0x88b8158, func=0xaf453fc, nResults=1) at 
../../../texk/web2c/luatexdir/lua51/ldo.c:376
#3  0x082da1b7 in callTMres (L=0x88b8158, res=0xaf45360, f=0x88d63e0, 
p1=0xaf45360, p2=0x8edfaec) at ../../../texk/web2c/luatexdir/lua51/lvm.c:88
#4  0x082da45d in luaV_gettable (L=0x88b8158, t=0xaf45360, key=0x8edfaec, 
val=0xaf45360) at ../../../texk/web2c/luatexdir/lua51/lvm.c:125
#5  0x082db4ec in luaV_execute (L=0x88b8158, nexeccalls=2) at 
../../../texk/web2c/luatexdir/lua51/lvm.c:437
#6  0x082c9cbf in luaD_call (L=0x88b8158, func=0xaf45318, nResults=0) at 
../../../texk/web2c/luatexdir/lua51/ldo.c:377
#7  0x082c25dd in f_call (L=0x88b8158, ud=0xbfffdc8c) at 
../../../texk/web2c/luatexdir/lua51/lapi.c:795
#8  0x082c8efd in luaD_rawrunprotected (L=0x88b8158, f=0x82c25b3 , 
ud=0xbfffdc8c) at ../../../texk/web2c/luatexdir/lua51/ldo.c:116
#9  0x082ca009 in luaD_pcall (L=0x88b8158, func=0x82c25b3 , 
u=0xbfffdc8c, old_top=288, ef=276) at 
../../../texk/web2c/luatexdir/lua51/ldo.c:457
#10 0x082c2677 in lua_pcall (L=0x88b8158, nargs=0, nresults=0, errfunc=23) at 
../../../texk/web2c/luatexdir/lua51/lapi.c:816
#11 0x080c3452 in luacall (p=195, nameptr=0, is_string=1) at 
../../../texk/web2c/luatexdir/lua/luastuff.w:397
#12 0x080c357d in late_lua (pdf=0x894b270, p=964) at 
../../../texk/web2c/luatexdir/lua/luastuff.w:419
#13 0x08193559 in out_what (pdf=0x894b270, p=964) at 
../../../texk/web2c/luatexdir/pdf/pdflistout.w:270
#14 0x081947c0 in hlist_out (pdf=0x894b270, this_box=2463) at 
../../../texk/web2c/luatexdir/pdf/pdflistout.w:567
#15 0x08193fbc in hlist_out (pdf=0x894b270, this_box=844) at 
../../../texk/web2c/luatexdir/pdf/pdflistout.w:459
#16 0x08193fbc in hlist_out (pdf=0x894b270, this_box=853) at 
../../../texk/web2c/luatexdir/pdf/pdflistout.w:459
#17 0x08195aa8 in vlist_out (pdf=0x894b270, this_box=879) a

Re: [NTG-context] imposition 2UP = empty pages

2012-05-18 Thread Henning Hraban Ramm

Am 2012-05-18 um 18:00 schrieb Hans Hagen:


quick hack that you can put in cont-new.mkiv



Works for me, too.
Thank you very much!


Greetlings, Hraban
---
http://www.fiee.net/texnique/
http://wiki.contextgarden.net
https://www.cacert.org (I'm an assurer)

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


Re: [NTG-context] Testing TeX Live 2012

2012-05-18 Thread Mojca Miklavec
On Fri, May 18, 2012 at 6:56 PM, Marco Pessotto wrote:
> Taco Hoekwater  writes:
>
>> I guessed as much. Unfortunately, as I cannot reproduce the bug, this is
>> where it ends for me. Perhaps Hartmut has a 32-bit system somewhere (CC).
>>
>> Best wishes,
>> Taco
>>
>> PS Hartmut: full thread is here:
>> http://archive.contextgarden.net/message/20120516.012657.49ebfe34.en.html
>
> Just for the sake of giving more (probably useless) information:
>
>  1. I updated the sources today and rebuild luatex (0.70.2). Same crash
>  (not that I thought it would be magically fixed by itself, but just to
>  be sure).
>
>  2. I diffed the luatex sources of texlive-2011 with the pretest one,
>  and are just a bunch of chunks. Now, I don't know anything about C, but
>  it doesn't seem a radical change.

Taco didn't commit any update at all, except for version change (and
Khaled did some math-related updates recently).

> So I thought that maybe it's poppler
>  the culprit, and I tried to rebuild with the sistem poppler. But here
>  it fails miserably during compilation.

You can try to checkout revision 26300 from TeX Live repository. That
should give you a good reference.
http://tug.org/svn/texlive?view=revision&revision=26301

> Now, shooting in the dark: the sources of TeXlive ship poppler 0.20.
> I compiled and tested the svn trunk of luatex, and it works (no crash,
> as reported by Luigi), but it's linked against poppler 0.18, as far as I
> can see.

You are not shooting in the dark. This was my earlier guess as well.
It's crashing while dealing with pdf and basically the only relevant
change between TL 2011 & 12 is a different poppler version.

> Well, that was all I could do, please let me know if I can do anything
> else.

If you could also try to build revision 26300 with debugging symbols
(and possibly try to upload the binary somewhere, so that others could
try as well), that might help. I either have or can try to install a
virtual machine with i386-linux, but building TeX Live in virtual
machine will take forever, so having a working binary with all
debugging symbols could help. (I'm not 100% sure if the binary for mac
has been compiled before or after poppler update.)

If you like debugging, you could set a few breakpoints in the
following lines that work with poststruct:

./texk/web2c/luatexdir/lua/lpdflib.c:pdf_set_pos(static_pdf,
static_pdf->posstruct->pos);
./texk/web2c/luatexdir/lua/lpdflib.c:(void)
calc_pdfpos(static_pdf->pstruct, static_pdf->posstruct->pos);
./texk/web2c/luatexdir/lua/lpdflib.c:(void)
calc_pdfpos(static_pdf->pstruct, static_pdf->posstruct->pos);
./texk/web2c/luatexdir/lua/lpdflib.c:lua_pushnumber(L,
static_pdf->posstruct->pos.h);
./texk/web2c/luatexdir/lua/lpdflib.c:lua_pushnumber(L,
static_pdf->posstruct->pos.v);
./texk/web2c/synctexdir/synctex-luatex.h:#define SYNCTEX_CURV
(dimen_par(page_height_code)-static_pdf->posstruct->pos.v)
./texk/web2c/synctexdir/synctex-luatex.h:#define SYNCTEX_CURH
static_pdf->posstruct->pos.h

and compare behaviour of old & new luatex. But that's just a blind guess.

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

Re: [NTG-context] Testing TeX Live 2012

2012-05-18 Thread Marco Pessotto
Taco Hoekwater  writes:

> I guessed as much. Unfortunately, as I cannot reproduce the bug, this is
> where it ends for me. Perhaps Hartmut has a 32-bit system somewhere (CC).
>
> Best wishes,
> Taco
>
> PS Hartmut: full thread is here:
> http://archive.contextgarden.net/message/20120516.012657.49ebfe34.en.html

Just for the sake of giving more (probably useless) information:

 1. I updated the sources today and rebuild luatex (0.70.2). Same crash
 (not that I thought it would be magically fixed by itself, but just to
 be sure).

 2. I diffed the luatex sources of texlive-2011 with the pretest one,
 and are just a bunch of chunks. Now, I don't know anything about C, but
 it doesn't seem a radical change. So I thought that maybe it's poppler
 the culprit, and I tried to rebuild with the sistem poppler. But here
 it fails miserably during compilation.

g++ -DHAVE_CONFIG_H -I. -I../../../texk/web2c -I./w2c  
-I/home/melmoth/progetti/debug/sources/Work/texk 
-I/home/melmoth/progetti/debug/sources/texk  
-I/home/melmoth/progetti/debug/sources/Work/libs/libpng/include 
-DPOPPLER_VERSION=\"0.12.4\" -I/usr/include/poppler   
-I/home/melmoth/progetti/debug/sources/Work/libs/obsdcompat 
-I/home/melmoth/progetti/debug/sources/libs/obsdcompat 
-I../../../texk/web2c/libmd5 -I../../../texk/web2c/luatexdir 
-I../../../texk/web2c/luatexdir/lua51 -DpdfTeX -I../../../texk/web2c/synctexdir 
-DSYNCTEX_ENGINE_H=''   -g -MT libluatex_a-lepdflib.o -MD -MP 
-MF .deps/libluatex_a-lepdflib.Tpo -c -o libluatex_a-lepdflib.o `test -f 
'luatexdir/lua/lepdflib.cc' || echo 
'../../../texk/web2c/'`luatexdir/lua/lepdflib.cc
../../../texk/web2c/luatexdir/lua/lepdflib.cc: In function 'int 
m_Dict_hasKey(lua_State*)':
../../../texk/web2c/luatexdir/lua/lepdflib.cc:845: error: 'class Dict' has no 
member named 'hasKey'

Now, shooting in the dark: the sources of TeXlive ship poppler 0.20. 
I compiled and tested the svn trunk of luatex, and it works (no crash,
as reported by Luigi), but it's linked against poppler 0.18, as far as I
can see.

Well, that was all I could do, please let me know if I can do anything
else.

Best wishes

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


Re: [NTG-context] imposition 2UP = empty pages

2012-05-18 Thread Marco Pessotto
Hans Hagen  writes:

> quick hack that you can put in cont-new.mkiv
>
> \def\handlearrangedpageTWOUP
>   {\splitoffarrangedpagesTWO
>\ifconditional\arrangedswapstate
>  \global\setbox\arrangedpageA\hbox
>{\box\arrangedpageA
> \box\arrangedpageB}%
>  \setfalse\arrangedswapstate
>\else
>  \global\setbox\arrangedpageA\hbox
>{\box\arrangedpageB
> \box\arrangedpageA}%
>  \settrue\arrangedswapstate
>\fi
>\ht\arrangedpageA\paperheight
>\global\setbox\arrangedpageB\box\scratchbox}

Tested and works like a charm. Thanks!

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


Re: [NTG-context] imposition 2UP = empty pages

2012-05-18 Thread Hans Hagen

On 18-5-2012 16:59, Marco Pessotto wrote:

Hans Hagen  writes:


is there a simple test file



Sure:

%% start
\setuppapersize[A5][A4,landscape]
\setuparranging[2UP]
\setuppagenumbering[alternative=doublesided]

\starttext

\dorecurse{20}{
   \input knuth
}

\stoptext
% stop

This produces 6 white pages with the latest beta (while output correctly
with 2011.11.29 23:11).


quick hack that you can put in cont-new.mkiv

\def\handlearrangedpageTWOUP
  {\splitoffarrangedpagesTWO
   \ifconditional\arrangedswapstate
 \global\setbox\arrangedpageA\hbox
   {\box\arrangedpageA
\box\arrangedpageB}%
 \setfalse\arrangedswapstate
   \else
 \global\setbox\arrangedpageA\hbox
   {\box\arrangedpageB
\box\arrangedpageA}%
 \settrue\arrangedswapstate
   \fi
   \ht\arrangedpageA\paperheight
   \global\setbox\arrangedpageB\box\scratchbox}




-
  Hans Hagen | PRAGMA ADE
  Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | voip: 087 875 68 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  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___


Re: [NTG-context] counter reseting at every heading

2012-05-18 Thread Hans Hagen

On 18-5-2012 15:00, Peter Schorsch wrote:

Hi,

I realized yesterday that my counter for the module does not reset
itself as before. What I need is a counter that resets after each
heading (chapter, section, subsection, subsubsection and so on).

This is what I know about counter reseting at the moment:

\definecounter[ParagraphNumber][prefix=no,way=bysection]
- way=bychapter: reseting counter at every chapter (default)
- way=bysection: reseting counter at every section (not at chapters)
- way={bychapter,bysection,bysubsection,bysubsubsection}: does not work

\setuphead[chapter,section,subsection,subsubsection][after={\resetcounter[ParagraphNumber]}]
does work but it messes with the distance between heading and normal
text.

What is the correct/best way to make the counter reseting every
heading without messing around?


we probably need something byheader or maybe indeed a comma separated list

Hans


-
  Hans Hagen | PRAGMA ADE
  Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | voip: 087 875 68 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  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___


Re: [NTG-context] imposition 2UP = empty pages

2012-05-18 Thread Marco Pessotto
Hans Hagen  writes:

> is there a simple test file
>

Sure:

%% start
\setuppapersize[A5][A4,landscape]
\setuparranging[2UP]
\setuppagenumbering[alternative=doublesided]

\starttext

\dorecurse{20}{
  \input knuth
}

\stoptext
% stop

This produces 6 white pages with the latest beta (while output correctly 
with 2011.11.29 23:11).

Best wishes


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


Re: [NTG-context] imposition 2UP = empty pages

2012-05-18 Thread Hans Hagen

On 18-5-2012 15:06, Marco Pessotto wrote:

Henning Hraban Ramm  writes:


2012/5/18 Marco Pessotto:

Version 2011.11.29 23:11 works. I think you can get it on the git
repository. There was a thread recently about how to fetch it from
there.


Yes, e.g. "my" thread. I'm working with such an old version for the
project where I can’t live without 2UP imposition. But there are other
problems with that, and I really don’t like to switch ConTeXt versions
all the time.  The 2UP can’t be that hard to fix, can it? Other
imposition schemes still work.


Even if I think that the imposition schemas are a wonderful ConTeXt
feature, I don't believe that helps (actually, I'm pretty sure it
doesn't) repeating that you need the now-broken feature.


is there a simple test file

Hans


-
  Hans Hagen | PRAGMA ADE
  Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | voip: 087 875 68 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  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] Testing TeX Live 2012

2012-05-18 Thread Taco Hoekwater

On 05/18/2012 02:49 PM, Marco Pessotto wrote:

Taco Hoekwater  writes:


On 05/17/2012 07:31 PM, Marco Pessotto wrote:


Anyway, I think I got the backtrace:


Nice backtrace.

You could try to print these in the debugger

   (gdb) p static_pdf
   (gdb) p static_pdf->posstruct
   (gdb) p *static_pdf->posstruct

you should get something like this:

   $1 = (PDF) 0x174de00
   $2 = (posstructure *) 0x175e1c0
   $3 = {pos = {h = 0, v = 0}, dir = 0}

but I cannot help much further as the crash does not happen on my
architecture: Ubuntu 12.04, x86_64.

Best wishes,
Taco


$1 = (PDF) 0x89a9270
$2 = (posstructure *) 0x1
Cannot access memory at address 0x1


I guessed as much. Unfortunately, as I cannot reproduce the bug, this is
where it ends for me. Perhaps Hartmut has a 32-bit system somewhere (CC).

Best wishes,
Taco

PS Hartmut: full thread is here: 
http://archive.contextgarden.net/message/20120516.012657.49ebfe34.en.html


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


Re: [NTG-context] imposition 2UP = empty pages

2012-05-18 Thread Marco Pessotto
Henning Hraban Ramm  writes:

> 2012/5/18 Marco Pessotto :
>> Version 2011.11.29 23:11 works. I think you can get it on the git
>> repository. There was a thread recently about how to fetch it from
>> there.
>
> Yes, e.g. "my" thread. I'm working with such an old version for the
> project where I can’t live without 2UP imposition. But there are other
> problems with that, and I really don’t like to switch ConTeXt versions
> all the time.  The 2UP can’t be that hard to fix, can it? Other
> imposition schemes still work.

Even if I think that the imposition schemas are a wonderful ConTeXt
feature, I don't believe that helps (actually, I'm pretty sure it
doesn't) repeating that you need the now-broken feature.

Anyway, for simple 2UP scheme, if you need it badly and urgently, you
may want to try pdfjam (which uses LaTeX under the hood, I used it for a
while) or the psutils, with a pdf -> ps -> pdf trip (psbook), (both are
shipped with ConTeXt, I used them for a while and were really fine) or
even write your own imposer which uses ConTeXt under the hood. I wrote
and rewrote mine a couple of times (because I need a dinamically
determinated signature) and it's not that difficult. [1]

Best wishes

[1] 
https://gitorious.org/amuse-wiki/amuse-wiki/blobs/master/Text-Muse/lib/Text/Muse/Compile.pm

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

[NTG-context] counter reseting at every heading

2012-05-18 Thread Peter Schorsch
Hi,

I realized yesterday that my counter for the module does not reset
itself as before. What I need is a counter that resets after each
heading (chapter, section, subsection, subsubsection and so on).

This is what I know about counter reseting at the moment:

\definecounter[ParagraphNumber][prefix=no,way=bysection]
- way=bychapter: reseting counter at every chapter (default)
- way=bysection: reseting counter at every section (not at chapters)
- way={bychapter,bysection,bysubsection,bysubsubsection}: does not work

\setuphead[chapter,section,subsection,subsubsection][after={\resetcounter[ParagraphNumber]}]
does work but it messes with the distance between heading and normal
text.

What is the correct/best way to make the counter reseting every
heading without messing around?

Thanks
P.
___
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
___


Re: [NTG-context] Testing TeX Live 2012

2012-05-18 Thread Marco Pessotto
Taco Hoekwater  writes:

> On 05/17/2012 07:31 PM, Marco Pessotto wrote:
>>
>> Anyway, I think I got the backtrace:
>
> Nice backtrace.
>
> You could try to print these in the debugger
>
>   (gdb) p static_pdf
>   (gdb) p static_pdf->posstruct
>   (gdb) p *static_pdf->posstruct
>
> you should get something like this:
>
>   $1 = (PDF) 0x174de00
>   $2 = (posstructure *) 0x175e1c0
>   $3 = {pos = {h = 0, v = 0}, dir = 0}
>
> but I cannot help much further as the crash does not happen on my
> architecture: Ubuntu 12.04, x86_64.
>
> Best wishes,
> Taco

$1 = (PDF) 0x89a9270
$2 = (posstructure *) 0x1
Cannot access memory at address 0x1

Best wishes

Full backtrace:

Starting program: 
/media/data/melmoth/progetti/texlive2012/bin/i386-linux/luatex 
--fmt="/media/data/melmoth/progetti/texlive2012/texmf-var/luatex-cache/context/2448223e6631addb83df348d74153606/formats/cont-en"
 
--lua="/media/data/melmoth/progetti/texlive2012/texmf-var/luatex-cache/context/2448223e6631addb83df348d74153606/formats/cont-en.lui"
 --backend="pdf" "./ciao.tex"

Program received signal SIGSEGV, Segmentation fault.
0x08148923 in getpdf (L=0x8916158)
at ../../../texk/web2c/luatexdir/lua/lpdflib.c:615
615 lua_pushnumber(L, static_pdf->posstruct->pos.h);
#0  0x08148923 in getpdf (L=0x8916158)
at ../../../texk/web2c/luatexdir/lua/lpdflib.c:615
#1  0x082d3c75 in luaD_precall (L=0x8916158, func=0xafa36c4, nresults=1)
at ../../../texk/web2c/luatexdir/lua51/ldo.c:319
#2  0x082d3eb8 in luaD_call (L=0x8916158, func=0xafa36c4, nResults=1)
at ../../../texk/web2c/luatexdir/lua51/ldo.c:376
#3  0x082e43c7 in callTMres (L=0x8916158, res=0xafa3628, f=0x89343e0, 
p1=0xafa3628, p2=0x8f3daec) at ../../../texk/web2c/luatexdir/lua51/lvm.c:88
#4  0x082e466d in luaV_gettable (L=0x8916158, t=0xafa3628, key=0x8f3daec, 
val=0xafa3628) at ../../../texk/web2c/luatexdir/lua51/lvm.c:125
#5  0x082e56fc in luaV_execute (L=0x8916158, nexeccalls=2)
at ../../../texk/web2c/luatexdir/lua51/lvm.c:437
#6  0x082d3ecf in luaD_call (L=0x8916158, func=0xafa35e0, nResults=0)
at ../../../texk/web2c/luatexdir/lua51/ldo.c:377
#7  0x082cc7ed in f_call (L=0x8916158, ud=0xbfffdc8c)
at ../../../texk/web2c/luatexdir/lua51/lapi.c:795
#8  0x082d310d in luaD_rawrunprotected (L=0x8916158, f=0x82cc7c3 , 
ud=0xbfffdc8c) at ../../../texk/web2c/luatexdir/lua51/ldo.c:116
#9  0x082d4219 in luaD_pcall (L=0x8916158, func=0x82cc7c3 , 
u=0xbfffdc8c, old_top=288, ef=276)
at ../../../texk/web2c/luatexdir/lua51/ldo.c:457
#10 0x082cc887 in lua_pcall (L=0x8916158, nargs=0, nresults=0, errfunc=23)
at ../../../texk/web2c/luatexdir/lua51/lapi.c:816
#11 0x080cd562 in luacall (p=195, nameptr=0, is_string=1)
at ../../../texk/web2c/luatexdir/lua/luastuff.w:397
#12 0x080cd68d in late_lua (pdf=0x89a9270, p=964)
at ../../../texk/web2c/luatexdir/lua/luastuff.w:419
#13 0x0819d769 in out_what (pdf=0x89a9270, p=964)
at ../../../texk/web2c/luatexdir/pdf/pdflistout.w:270
#14 0x0819e9d0 in hlist_out (pdf=0x89a9270, this_box=2463)
at ../../../texk/web2c/luatexdir/pdf/pdflistout.w:567
#15 0x0819e1cc in hlist_out (pdf=0x89a9270, this_box=844)
at ../../../texk/web2c/luatexdir/pdf/pdflistout.w:459
#16 0x0819e1cc in hlist_out (pdf=0x89a9270, this_box=853)
at ../../../texk/web2c/luatexdir/pdf/pdflistout.w:459
#17 0x0819fcb8 in vlist_out (pdf=0x89a9270, this_box=879)
at ../../../texk/web2c/luatexdir/pdf/pdflistout.w:911
#18 0x0819e1b8 in hlist_out (pdf=0x89a9270, this_box=2236)
at ../../../texk/web2c/luatexdir/pdf/pdflistout.w:457
#19 0x0819fcb8 in vlist_out (pdf=0x89a9270, this_box=2245)
at ../../../texk/web2c/luatexdir/pdf/pdflistout.w:911
#20 0x0819e1b8 in hlist_out (pdf=0x89a9270, this_box=2258)
at ../../../texk/web2c/luatexdir/pdf/pdflistout.w:457
#21 0x0819e1cc in hlist_out (pdf=0x89a9270, this_box=2267)
at ../../../texk/web2c/luatexdir/pdf/pdflistout.w:459
#22 0x0819e1cc in hlist_out (pdf=0x89a9270, this_box=2318)
at ../../../texk/web2c/luatexdir/pdf/pdflistout.w:459
#23 0x0819e1cc in hlist_out (pdf=0x89a9270, this_box=2350)
at ../../../texk/web2c/luatexdir/pdf/pdflistout.w:459
#24 0x0819fcb8 in vlist_out (pdf=0x89a9270, this_box=2359)
at ../../../texk/web2c/luatexdir/pdf/pdflistout.w:911
#25 0x0819fca4 in vlist_out (pdf=0x89a9270, this_box=2372)
at ../../../texk/web2c/luatexdir/pdf/pdflistout.w:909
#26 0x0819e1b8 in hlist_out (pdf=0x89a9270, this_box=2421)
at ../../../texk/web2c/luatexdir/pdf/pdflistout.w:457
#27 0x0819fcb8 in vlist_out (pdf=0x89a9270, this_box=2430)
at ../../../texk/web2c/luatexdir/pdf/pdflistout.w:911
#28 0x0819fca4 in vlist_out (pdf=0x89a9270, this_box=2445)
at ../../../texk/web2c/luatexdir/pdf/pdflistout.w:909
#29 0x0819fca4 in vlist_out (pdf=0x89a9270, this_box=968)
at ../../../texk/web2c/luatexdir/pdf/pdflistout.w:909
#30 0x0819e1b8 in hlist_out (pdf=0x89a9270, this_box=2454)
at ../../../texk/web2c/luatexdir/pdf/pdflistout.w:457
#31 0x0819e1cc in hlist_

Re: [NTG-context] ConTeXt colours in TikZ

2012-05-18 Thread Marco
On 2012-05-18 "Philipp A."  wrote:

> also check this:
> http://tex.stackexchange.com/questions/27952/cmyk-context-colors-in-tikz

The colour conversion code is already included in the tikz module.
But it works only for cmyk colours, for rgb it fails:

\definecolor [c] [c=1] % works
\definecolor [b] [b=1] % fails

I submitted a bug report including Hans' patch which, at least for
me, doesn't seem to break anything. We'll see how long it will take
to include the fix.

Marco


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


Re: [NTG-context] Luatex crash on \endinput \end

2012-05-18 Thread Taco Hoekwater

On 05/18/2012 11:44 AM, Hans Hagen wrote:


A weird problem ... just a side note: I didn't change anything in the
\stoptext code for a while. Can you see what gets freed? Some node?


It was free-ing the resulting virtual file from tex.sprint('\stoptext'),
and it crashed because that line was not finished yet. Normally that
does not matter, but \end processing is a bit extra special.

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


Re: [NTG-context] Luatex crash on \endinput \end

2012-05-18 Thread Hans Hagen

On 18-5-2012 10:58, Taco Hoekwater wrote:

On 05/17/2012 04:30 PM, Aditya Mahajan wrote:


with the same crash. Can someone else using context minimals with
archlinux check if they get a crash or not?


I get a crash (double free) with:

echo '\endinput \end ' | context --pipe

and I get a 'normal' Fatal error occurred with:

echo '\\endinput \\end' | context --pipe

and I think that solves that bit of the mystery.

Now for that double-free:

echo '\tracingall \endinput \end ' | context --pipe

ends with:


{\endinput}

\end ->\ctxcommand {forceendjob()}

\ctxcommand #1->\directlua \zerocount {commands.#1}
#1<-forceendjob()
{\directlua}
system > don't use \end to finish a document
*** glibc detected *** luatex: double free or corruption (fasttop):
0x04c21340 ***



It probably crashes because in context the \end code and the \endinput
code interfere with eachother. You get the same crash if you create a
simple input file with just that same line, and the crash goes away if
you put \endinput and \end on separate lines, and as far as I can tell,
context always crashes if \endinput and \end/\stoptext are on the same
line.


A weird problem ... just a side note: I didn't change anything in the 
\stoptext code for a while. Can you see what gets freed? Some node?


Hans

-
  Hans Hagen | PRAGMA ADE
  Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | voip: 087 875 68 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  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___


Re: [NTG-context] Most portable font name

2012-05-18 Thread Hans Hagen

On 18-5-2012 08:20, Philipp Gesang wrote:

On 2012-05-18 00:00, Hans Hagen wrote:

On 17-5-2012 16:11, Philipp Gesang wrote:


So I judged that my preferred choice might not be as good as I
think. I got cold feet and am about to remove the slide where I
recommend the PS name (I can do that later anyways). Is there --
apart from personal opinions -- some valid reason to prefer one
name over the other *in general*?


For a project that has to run for a long time, I prefer filenames
(file:). When fonts are stable names can be used too and the name
resolved will check several names in the font. Spaces are ignored
and names are lowercases. There's also some fallback name
construction going on. Anyhow, the biggest problem is with fonts
that have the same names (but different files).


I see. But even the filename can be treacherous: afair there is a
times.ttf among the MS core fonts but it’s different from the one
shipped with their office tools. The font name guessing, otoh,
seems pretty elaborate, though I have not had the opportunity to
look at it in detail.


I always put such fonts in tex/texmf-fonts/fonts/data so that I'm sure 
what gets used.


Hans




-
  Hans Hagen | PRAGMA ADE
  Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | voip: 087 875 68 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  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___


Re: [NTG-context] Luatex crash on \endinput \end

2012-05-18 Thread Aditya Mahajan

On Fri, 18 May 2012, Taco Hoekwater wrote:


On 05/17/2012 04:30 PM, Aditya Mahajan wrote:


with the same crash. Can someone else using context minimals with
archlinux check if they get a crash or not?


I get a crash (double free) with:

  echo '\endinput \end ' | context --pipe

and I get a 'normal' Fatal error occurred with:

 echo '\\endinput \\end' | context --pipe

and I think that solves that bit of the mystery.


Of all the differences in the systems, the most relevant was how the shell 
espace in string works. Apparently I have some weird option set in my 
.zshrc due to which echo always enable escape characters.



Now for that double-free:

 echo '\tracingall \endinput \end ' | context --pipe

ends with:


{\endinput}

\end ->\ctxcommand {forceendjob()}

\ctxcommand #1->\directlua \zerocount {commands.#1}
#1<-forceendjob()
{\directlua}
system  > don't use \end to finish a document
*** glibc detected *** luatex: double free or corruption (fasttop): 
0x04c21340 ***



It probably crashes because in context the \end code and the \endinput 
code interfere with eachother. You get the same crash if you create a 
simple input file with just that same line, and the crash goes away if 
you put \endinput and \end on separate lines, and as far as I can tell, 
context always crashes if \endinput and \end/\stoptext are on the same 
line.


Thanks for the diagnosis.

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


Re: [NTG-context] Testing TeX Live 2012

2012-05-18 Thread Taco Hoekwater

On 05/17/2012 07:31 PM, Marco Pessotto wrote:


Anyway, I think I got the backtrace:


Nice backtrace.


Starting program: /media/data/melmoth/progetti/texlive2012/bin/i386-linux/luatex 
--fmt="/media/data/melmoth/progetti/texlive2012/texmf-var/luatex-cache/context/2448223e6631addb83df348d74153606/formats/cont-en"
 
--lua="/media/data/melmoth/progetti/texlive2012/texmf-var/luatex-cache/context/2448223e6631addb83df348d74153606/formats/cont-en.lui"
 --backend="pdf" "./ciao.tex"

Program received signal SIGSEGV, Segmentation fault.
0x08148923 in getpdf (L=0x8916158) at 
../../../texk/web2c/luatexdir/lua/lpdflib.c:615
615 lua_pushnumber(L, static_pdf->posstruct->pos.h);


Somewhere in that line is a reference to a non-valid pointer. I assume 
static_pdf itself is fine, so the problem is likely the posstruct entry.


You could try to print these in the debugger

  (gdb) p static_pdf
  (gdb) p static_pdf->posstruct
  (gdb) p *static_pdf->posstruct

you should get something like this:

  $1 = (PDF) 0x174de00
  $2 = (posstructure *) 0x175e1c0
  $3 = {pos = {h = 0, v = 0}, dir = 0}

but I cannot help much further as the crash does not happen on my
architecture: Ubuntu 12.04, x86_64.

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


Re: [NTG-context] Luatex crash on \endinput \end

2012-05-18 Thread luigi scarso
On Fri, May 18, 2012 at 10:58 AM, Taco Hoekwater  wrote:
> On 05/17/2012 04:30 PM, Aditya Mahajan wrote:
>>
>>
>> with the same crash. Can someone else using context minimals with
>> archlinux check if they get a crash or not?
>
>
> I get a crash (double free) with:
>
>
>   echo '\endinput \end ' | context --pipe
confirmed
-- 
luigi
___
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
___

Re: [NTG-context] Luatex crash on \endinput \end

2012-05-18 Thread Taco Hoekwater

On 05/17/2012 04:30 PM, Aditya Mahajan wrote:


with the same crash. Can someone else using context minimals with
archlinux check if they get a crash or not?


I get a crash (double free) with:

   echo '\endinput \end ' | context --pipe

and I get a 'normal' Fatal error occurred with:

  echo '\\endinput \\end' | context --pipe

and I think that solves that bit of the mystery.

Now for that double-free:

  echo '\tracingall \endinput \end ' | context --pipe

ends with:


{\endinput}

\end ->\ctxcommand {forceendjob()}

\ctxcommand #1->\directlua \zerocount {commands.#1}
#1<-forceendjob()
{\directlua}
system  > don't use \end to finish a document
*** glibc detected *** luatex: double free or corruption (fasttop): 
0x04c21340 ***



It probably crashes because in context the \end code and the \endinput
code interfere with eachother. You get the same crash if you create a
simple input file with just that same line, and the crash goes away if
you put \endinput and \end on separate lines, and as far as I can tell,
context always crashes if \endinput and \end/\stoptext are on the same
line.

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


Re: [NTG-context] ConTeXt colours in TikZ

2012-05-18 Thread Philipp A.
also check this:
http://tex.stackexchange.com/questions/27952/cmyk-context-colors-in-tikz
___
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
___

Re: [NTG-context] imposition 2UP = empty pages

2012-05-18 Thread Henning Hraban Ramm
2012/5/18 Marco Pessotto :
> Version 2011.11.29 23:11 works. I think you can get it on the git
> repository. There was a thread recently about how to fetch it from
> there.

Yes, e.g. "my" thread. I'm working with such an old version for the
project where I can’t live without 2UP imposition. But there are other
problems with that, and I really don’t like to switch ConTeXt versions
all the time.
The 2UP can’t be that hard to fix, can it? Other imposition schemes still work.

Greetlings, Hraban
___
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
___

Re: [NTG-context] imposition 2UP = empty pages

2012-05-18 Thread Marco Pessotto
Henning Hraban Ramm  writes:

> Am 2012-04-23 um 20:10 schrieb Henning Hraban Ramm:
>
>> Am 2012-04-20 um 17:58 schrieb Henning Hraban Ramm:
>>
>>> Hi there,
>>>
>>> like in January (see mail by Mari), the latest beta produces only
>>> empty pages with 2UP imposition schema; others work (tested 2SIDE
>>> and 2DOWN).
>>>
>>
>> PING
>> Any news on that? Today's beta still is buggy.
>> Unfortunately I need 2UP imposition urgently.
>>
>> Greetlings, Hraban
>
> PING
> still the same with latest beta.


Version 2011.11.29 23:11 works. I think you can get it on the git
repository. There was a thread recently about how to fetch it from
there.


-- 
Marco

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