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