On 01/31/2015 09:37 PM, Rob Heusdens wrote:
When using \setuphead[section][alternative=text] I noticed two things:
1. There is an extra space (horizontally) directly after the section heading. I can't get a grip on how to get rid of it.
Hi Rob,
distance=1ex (or similar) should do the job.
I'll try that. Thanks!
2. A different type of section (define with \definehead[summary][section] seems to alter it's behaviour due to a \setuphead[section][..]. Shouldn't the summary behaviour be independend of what one sets for section?
If you define summary as a duplicate of section, the former will inherit properties from the latter.
All you have to do is refine the unwanted features in summary.
A very stupid example:
\definehead[summary][section] \setuphead[section][number=no,style=\bf] \setuphead[summary][number=yes, style=\it] \starttext \section{Section} \summary{Summary} \stoptext
BTW, "alternative=paragraph" puts the heading in a separate paragraph in latest beta.
Just in case it helps,
Are you sure that is the way it is supposed to work? My interpretation of it would be that: First, once you have defined summary with \define[summary][section], at that moment in time it has the properties set to whatever section has. But afterwards, the objects section and summary should lead "seperate lives" so to speak, and making adjustments to one, should not result in changes to the other. At least, that is how I understood it to be, and seems to me logical. If that is not the way it is implemented, I think Or, in ordinary programming languages syntax as metaphor. int y = 1; int x = y; y = 4; printf("y = %d, x = %d\n", y, x); will print y = 4, x = 1 Since changing y won't change the value of x. However, if we change the order of statements: int y = 1; y = 4; int x = y; printf("y = %d, x = %d\n", y, x); then of course, x will print as 4, because x got it's value AFTER we already changed y. But after assigning the value of y to x, any changes of y won't effect x. So that is how I understand statements in Context like this: \definehead[summary][section] \setuphead[section][alternative=text] \setuphead[summary][style=\bf] to be, namely that setting alternative to text for section, does NOT change the value of summary for section. \setuphead[section][alternative=text] \definehead[summary][section] \setuphead[summary][style=\bf] However in the above case, when we change the order of definitions, section is already changed BEFORE we assign it to summary, and THEN of course, also summary acquires those properties from section. At least such a behaviour would seem to me the most logical and intuitive behaviour. I didn't expect for summary to behave differently because I changed section. section and summary should behave like independend objects. But maybe that is NOT the way it works in Context? I think that would be unintuitive, since it would cause unwanted side effect. Who wants that? If you want to have summary inherit some properties from section, then you first set those properties to section and only THEN you define summary as to be some other section, inherting the properties from section as they exist at the moment you define summary. Anything that occurs later to section should not change the behaviour of summary. But maybe for good reasons I don't quite understand, Context implements this differently. At least I think such 'unexpected' behaviour (for me at least, coming from a programming background it is), should be cleary documented on the wiki. Greetings, Rob