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

2015-02-02 Thread Hans Hagen

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

Hi Hans, All,



Am 02.02.2015 um 02:18 schrieb Hans Hagen pra...@wxs.nl
mailto:pra...@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:


structuresectioning  reassigning section level 'two' to 'one'
structuresectioning  reassigning section level 'three' to 'two'
structuresectioning  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
___




--

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

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

2015-02-02 Thread Keith Schultz
Hi Hans, All,


 Am 02.02.2015 um 02:18 schrieb Hans Hagen pra...@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! 

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
___

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

2015-02-01 Thread Hans Hagen

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:

 h1Heading/h1
 h1 class=partPart 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
 h1Heading/h1
 h1 class=partPart 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
-
___
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
___

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

2015-01-31 Thread Rob Heusdens
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)

test5a.pdf
Description: Adobe PDF document


test5b.pdf
Description: Adobe PDF document
___
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
___

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

2015-01-31 Thread Rob Heusdens
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.


test5c.pdf
Description: Adobe PDF document
___
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
___

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

2015-01-31 Thread Pablo Rodriguez
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
___
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
___

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

2015-01-31 Thread Pablo Rodriguez
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:

h1Heading/h1
h1 class=partPart 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
h1Heading/h1
h1 class=partPart 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
___
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
___

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

2015-01-31 Thread Rob Heusdens
 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
___