[NTG-context] section with \sethupead[section][alternative=text]; other type of section misbehaves..

Pablo Rodriguez oinos at gmx.es
Sun Feb 1 07:28:33 CET 2015

On 01/31/2015 11:10 PM, Rob Heusdens wrote:
>> [...]
>> 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
>> [...]
> Are you sure that is the way it is supposed to work?

Hi Rob,

well, I think this is the way it seems to work in the sample at least (I
compiled it myself ;-)).

> 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

I might be wrong, but think of it as an XML element and the same element
with a class.

I know the sample would be stupid:

    <h1 class="part">Part Heading</h1>

In CSS, h1.part would inherit every attribution made to h1 (either after
or before).

If you wanted to have italics and bold for each heading, this would lead to:

    <style type="text/css">
        h1 {font-style: italic; font-weight: normal;}
        h1.part {font-style: normal; font-weight: bold;}
        <h1 class="part">Part Heading</h1></body>

> [...]
> \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?

I think ConTeXt behaves the opposite way you expected (or at least, this
is what I get from trial and error).

> But maybe for good reasons I don't quite understand, Context implements
> this differently.

Hans should know better about that. Coding is actually Greek to me.

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

Please, be our guest :-).



More information about the ntg-context mailing list