ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Hans Hagen <pragma@wxs.nl>
To: mailing list for ConTeXt users <ntg-context@ntg.nl>
Subject: Re: coloring rules
Date: Sun, 24 Jan 2010 14:02:52 +0100	[thread overview]
Message-ID: <4B5C44FC.9070007@wxs.nl> (raw)
In-Reply-To: <E7A892E0-7B31-4C2D-AF95-6ECE07BC6CFC@uva.nl>

On 23-1-2010 14:32, Hans van der Meer wrote:
> Further experimentation has shown that it is not impossible to color
> \vrule's, thus \blackrule is not specifically needed. Let me first
> mention that I put the colored rules away with \setbox\B=\hbox{} and
> then later call \B up. It is a pity until now I am not able to concoct a
> minimal example showing consistently the behaviour.
>
> However I have made the following observations:
> define: \definecolor[mycolor][r=myR,g=myG,b=myB]
>
> (1) \color[mycolor]{rule} typesets a black rule
> (2) \color[red]{something}\color[mycolor]{rule} typesets a mycolor rule
> (3) \definecolor[green][r=myR,g=myG,b=myB]\color[mycolor]{rule} typesets
> a mycolor rule
> (4) changing the values of myR,myG,myB between runs keeps typesetting
> the old mycolor
> (5) it seems there is a memory effect on defined colors, something with
> a cache that keeps me from changing things.
>
> It is mainly the seemingly erratic behaviour of the color changes that
> puzzles me. I seem not being able to pinpoint a culprit.

it's not that erratic at all, just do the same experiment with fonts ...

In traditional tex color is implemented using specials and code is 
injected. Compare this with fonts: you choose a font, which sets a state 
and that state carries with the following glyphs till set otherwise (or 
restored). Boxing and unboxing keeps that state.

In mkiv we use attributes for color (btw, the mk.pdf documents mentions 
al those things). And attributes are kept with objects and as a result 
are retained, which in my opinion is as it shoul dbe.

So, in traditional tex you have:

box == somerule

[somecolor][thatbox]

which effectively is

[somecolor]somerule

so the rule gets somecolor

but if you have

box == [somecolor]somerule

[anothercolor][thatbox]

you have

[anothercolor][somecolor]somerule

and te box will stay somecolor

in mkiv nocolor is really nocolor so in the first example your rule will 
be black (as it has no attribute set and will not gte one set either as 
a box has frozen states

When I wrote the backend code for colors I added an inheritance model 
but it's not yet perfect (and might even disappear or change).

\starttext

x\definecolor[mycolor][green]\color[mycolor]{\vrule width 10cm}x

\setbox0\hbox{x\color[mycolor]{\vrule width 10cm}x}

x\definecolor[mycolor][red]\color[mycolor]{\vrule width 10cm}x

\color[mycolor]{\copy0}

\enableattributeinheritance

\color[mycolor]{\attributedcopy0}

\stoptext

Your bad luck is that inheritance does not play well with rules currently.

On the other hand, the fact that you could this in mkii is no proof that 
it's the right way to do it. Most attribute driven features behave like 
fonts have been doing in mkii for ages.

Hans



-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
      tel: 038 477 53 69 | fax: 038 477 53 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
___________________________________________________________________________________


  parent reply	other threads:[~2010-01-24 13:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-21 16:28 Hans van der Meer
2010-01-21 21:24 ` Aditya Mahajan
2010-01-23 13:32   ` Hans van der Meer
2010-01-23 13:49     ` Wolfgang Schuster
2010-01-23 15:06       ` Hans van der Meer
2010-01-23 18:19         ` Wolfgang Schuster
2010-01-24 13:02     ` Hans Hagen [this message]
2010-01-24 13:04     ` Hans Hagen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B5C44FC.9070007@wxs.nl \
    --to=pragma@wxs.nl \
    --cc=ntg-context@ntg.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).