On 2/1/2015 7:28 AM, Pablo Rodriguez wrote:
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:

     \setuphead[summary][number=yes, style=\it]

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>


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

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

I'm not sure what you mean but a setting like


is just that, a setting. If you redefine \bf the style also changes. Or when you set color=red and then \definecolor[red][g=1] the summary comes out as green.

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.

It's for good reason. Now you can change the style any time.

When you define


the lookup for four is (1) four related settings, (2) one related settings, (3) section related settings, (4) root section settings

for three the chain is three, two, one, section, root

with respect to style: there is style, textstyle and numberstyle so make sure you set the right ones (normally style is used for a switch that is shared between text and number)

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

tex is a macro language .. stuff gets expanded immediately or delayed; metapost is also a macro language but with different properties


                                          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 

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

Reply via email to