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

newer
How to place text to the right of...

Rob Heusdens

31 Jan 2015 31 Jan '15

1:37 p.m.

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. 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? Here is a MWE that shows the problem: example 1: \defineblank[sprong][.5cm] \definehead[summary][section] \setuphead[section][number=no,style=bold,before={\blank[sprong]},after=,alternative=text,indentnext=no] \setuphead[summary][number=no,style=bold,before=,after={\blank[sprong]},beforesection={\noindentation\page\starttextbackground[SummaryBackground]},aftersection={\stoptextbackground\page}] \setupwhitespace[none] \setupindenting[yes, small, next] \definetextbackground [SummaryBackground] [frame=off,frameoffset=0pt, background=color, backgroundcolor=gray, backgroundoffset=2ex] \starttext \section{First sentence. Second sentence.}\input zapf \summary{Summary}\input zapf \stoptext example 2: \defineblank[sprong][.5cm] \definehead[summary][section] \setuphead[section][number=no,style=bold,before={\blank[sprong]},after=,alternative=text,indentnext=no] \setuphead[summary][number=no,style=bold,before=,alternative=paragraph,after={\blank[sprong]},beforesection={\noindentation\page\starttextbackground[SummaryBackground]},aftersection={\stoptextbackground\page}] \setupwhitespace[none] \setupindenting[yes, small, next] \definetextbackground [SummaryBackground] [frame=off,frameoffset=0pt, background=color, backgroundcolor=gray, backgroundoffset=2ex] \starttext \section{First sentence. Second sentence.}\input zapf \summary{Summary}\input zapf \stoptext Adding [alternative=paragraph] for summary solves this problem, and is at least a workaround, but that should not be necessary. My main problem though is how to get rid of that extra horizontal space after the normal section heading. The next sentence should align just like the section is a normal sentence itself (only typeset as bold). Is there a solution for that? Many thanks. Greeting, Rob -- attached (example 1 = test5a.pdf; example 2 = test5b.pdf)

Attachments:

test5a.pdf (application/pdf — 12.1 KB)
test5b.pdf (application/pdf — 12.2 KB)

Show replies by date

Rob Heusdens

31 Jan 31 Jan

2:03 p.m.

I forgot to add the basic example, with neither for section nor for summary an option set in \setuphead[..] for alternative. So, read this as example 0: = test5.pdf Example 0: \defineblank[sprong][.5cm] \definehead[summary][section] \setuphead[section][number=no,style=bold,before={\blank[sprong]},after=,indentnext=no] \setuphead[summary][number=no,style=bold,before=,after={\blank[sprong]},beforesection={\noindentation\page\starttextbackground[SummaryBackground]},aftersection={\stoptextbackground\page}] \setupwhitespace[none] \setupindenting[yes, small, next] \definetextbackground [SummaryBackground] [frame=off,frameoffset=0pt, background=color, backgroundcolor=gray, backgroundoffset=2ex] \starttext \section{First sentence. Second sentence.}\input zapf \summary{Summary}\input zapf \stoptext Example 0 => Example 1 Setting the alternative=text for section also causes a change in behaviour of the summary section.

Pablo Rodriguez

2:32 p.m.

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.

...

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, Pablo -- http://www.ousia.tk

Rob Heusdens

3:10 p.m.

...

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

Pablo Rodriguez

11:28 p.m.

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

...

[...] \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 :-). Greetings, Pablo -- http://www.ousia.tk

Hans Hagen

1 Feb 1 Feb

6:18 p.m.

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:

\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>Heading</h1> <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:

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

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

I'm not sure what you mean but a setting like \setuphead[summary][style=\bf] 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 \definehead[one][section] \definehead[two][one] \definehead[three][two] \definehead[four][one] 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 ----------------------------------------------------------------- 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 -----------------------------------------------------------------

Keith Schultz

2 Feb 2 Feb

2:40 a.m.

Hi Hans, All,

...

Am 02.02.2015 um 02:18 schrieb Hans Hagen : [snip, snip]

...

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

When you define

\definehead[one][section] \definehead[two][one] \definehead[three][two] \definehead[four][one]

I think what Rob wants to know is for example if one has \definehead[one][section] \definehead[two][one] \definehead[three][two] \definehead[one][chapter] \definehead[four][one] Does two end up a chapter header or a section header! I would assume two is a section header and four a chapter header! Please disregard the fact that this type of coding is bad practice! regards Keith.

Hans Hagen

7:02 a.m.

On 2/2/2015 10:40 AM, Keith Schultz wrote:

...

Hi Hans, All,

...
Am 02.02.2015 um 02:18 schrieb Hans Hagen mailto:pragma@wxs.nl>: [snip, snip]

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

When you define

\definehead[one][section] \definehead[two][one] \definehead[three][two] \definehead[four][one]

I think what Rob wants to know is for example if one has

\definehead[one][section] \definehead[two][one] \definehead[three][two]

\definehead[one][chapter] \definehead[four][one]

Does two end up a chapter header or a section header! I would assume two is a section header and four a chapter header!

ah, ok ... that is a side effect of the definitions registering themselves in a special way (at the lua end) .. i can catch that in the next beta: structure > sectioning > reassigning section level 'two' to 'one' structure > sectioning > reassigning section level 'three' to 'two' structure > sectioning > reassigning section level 'three' to 'two' I'll also add: \usemodule[structure-sections] \showstructuresections

...

Please disregard the fact that this type of coding is bad practice!

regards Keith.

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

3454

Age (days ago)

3456

Last active (days ago)

List overview

Download

7 comments

4 participants

participants (4)

Hans Hagen
Keith Schultz
Pablo Rodriguez
Rob Heusdens