marking in columnset
Dear ConTeXters, several kind of marking variants (first, last, both, ...) works perfectly in standard one-column layout: ---------------------------------------------------- \definemarking[M] \startsetups S default=(\getmarking[M])~ first=(\getmarking[M][first])~ last=(\getmarking[M][last])~ previous=(\getmarking[M][previous])~ both=(\getmarking[M][both])~ all=(\getmarking[M][all])~ current=(\getmarking[M][current]) \stopsetups \setupheadertexts[text] [\setups{S}][] [\setups{S}][] \setuppagenumbering[location=footer] \starttext \startbuffer \section{Knuth} \marking[M]{k1}\marking[M]{k2} \input knuth \section{Zapf} \marking[M]{z} \input zapf \stopbuffer \dorecurse{10}{\getbuffer} \stoptext ------------------------------------------------------- If I try the same example in columnset layout, only last variant works as expected: ------------------------------------------------------- \definemarking[M] \startsetups S default=(\getmarking[M])~ first=(\getmarking[M][first])~ last=(\getmarking[M][last])~ previous=(\getmarking[M][previous])~ both=(\getmarking[M][both])~ all=(\getmarking[M][all])~ current=(\getmarking[M][current]) \stopsetups \setupheadertexts[text] [\setups{S}][] [\setups{S}][] \setuppagenumbering[location=none] \definecolumnset[C][n=3] \starttext \startbuffer \section{Knuth} \marking[M]{k1}\marking[M]{k2} \input knuth \section{Zapf} \marking[M]{z} \input zapf \stopbuffer \startcolumnset[C] \dorecurse{10}{\getbuffer} \stopcolumnset \stoptext --------------------------------------------------------------- (Focus on page 1 and 4) Is there any idea how to fix this? Vit
Hans Hagen wrote:
Vit Zyka wrote:
(Focus on page 1 and 4)
Is there any idea how to fix this?
afaiks, what you get is the markings of the last column
so, it looks like i have to fix something
Hans
Yes, you are right. I check it on a real doc. And if no mark sign is in the last col, then marks from previous col(s) is taken. It would be a great news if you succeed to fix it. I cross my fingers. Vit
Vit Zyka wrote:
It would be a great news if you succeed to fix it. I cross my fingers.
well, it's actually relatively easy to make that (works on my machine now) but as always .. how to interface best -) and ... of course it takes some time to find all points where synchronization has to take place Hans
Hans Hagen wrote:
Vit Zyka wrote:
It would be a great news if you succeed to fix it. I cross my fingers.
well, it's actually relatively easy to make that (works on my machine now) but as always .. how to interface best -)
and ... of course it takes some time to find all points where synchronization has to take place
Hans
Understand. I appreciate if upgrading the whole context distro will not be needed. I am afraid of something works differently - and there is no time to fix it. So some patches/file exchanges are feasible? Vit
Vit Zyka wrote:
Hans Hagen wrote:
Vit Zyka wrote:
It would be a great news if you succeed to fix it. I cross my fingers.
well, it's actually relatively easy to make that (works on my machine now) but as always .. how to interface best -)
and ... of course it takes some time to find all points where synchronization has to take place
Hans
Understand. I appreciate if upgrading the whole context distro will not be needed. I am afraid of something works differently - and there is no time to fix it. So some patches/file exchanges are feasible?
actually, the patch i sent you off-list is not that dangerous because (1) it is written on top of the untouched low level mark handler (2) it leaves the normal marks untouched so it will end up in the distribution if you find no flaws as usual the problem is in documenting it (i.e. when adding new things for you others may complain that the manual is way behind -) Hans
Hans Hagen wrote:
Vit Zyka wrote:
Hans Hagen wrote:
Vit Zyka wrote:
It would be a great news if you succeed to fix it. I cross my fingers.
well, it's actually relatively easy to make that (works on my machine now) but as always .. how to interface best -)
and ... of course it takes some time to find all points where synchronization has to take place
Hans
Understand. I appreciate if upgrading the whole context distro will not be needed. I am afraid of something works differently - and there is no time to fix it. So some patches/file exchanges are feasible?
actually, the patch i sent you off-list is not that dangerous because
(1) it is written on top of the untouched low level mark handler (2) it leaves the normal marks untouched
not at all: \getmarking[A][all] does not swallow [A]
so it will end up in the distribution if you find no flaws
as usual the problem is in documenting it (i.e. when adding new things for you others may complain that the manual is way behind -)
What does it mean \global\mofcolumns\plusone inside of setups in your test example? Is it really needed? I put the info to tex-show (getmarking). I reminds me there are many items missing in the tex-show, the list is on the wiky - columnsets are among them. vit
Hans Hagen wrote:
Vit Zyka wrote:
It would be a great news if you succeed to fix it. I cross my fingers.
ok, you can uncross them; see separate mail
Hans
All right, I read this parallel message just now... Perhaps due to I was working with crossing fingers all the time ;-) vit
Vit Zyka wrote:
Hans Hagen wrote:
Vit Zyka wrote:
It would be a great news if you succeed to fix it. I cross my fingers.
ok, you can uncross them; see separate mail
Hans
All right, I read this parallel message just now... Perhaps due to I was working with crossing fingers all the time ;-)
well, keep 'm crossed because i'm shutting down now -) remind me to fix this (or add an item to the collector) Hans
participants (2)
-
Hans Hagen -
Vit Zyka