ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Hans Hagen <pragma@wxs.nl>
Subject: Re: typescript checking
Date: Thu, 19 Aug 2004 00:19:04 +0200	[thread overview]
Message-ID: <4123D5D8.60809@wxs.nl> (raw)
In-Reply-To: <CFBD3A1B-CEA9-11D8-B4EB-003065568054@science.uva.nl>

dr. Hans van der Meer wrote:

> Hi Hans,
>
> On my "travels" through ConTeXt's fonthandling I got the following 
> result on typescript matching:
>     enter[xyz][][] and check[xyz][pqr][]
> does match.
>
> If I read the definition of  \dochecktypescript#1#2#3 well, this is 
> because an empty  argument #1 at once leads to a \donetrue. That makes 
> the checking of an empty argument equivalent to the checking with an 
> [all] key (but for the additional fact that [all] matches on both the 
> entered and the checked key). Then
>
> (enter[xyz][][] --- check[xyz][pqr][]) is equivalent with 
> (enter[xyz][all][] --- check[xyz][pqr][])
>
> Isn't this counterintuitive? I would have expected empty matching 
> nothing at all, or at most matching another empty argument. The point 
> is, I wanted to do a nice structured setup, something like:
>
> \starttypescript [A]  \usetypescript[A][AA]  
> \usetypescript[A][AB]\stoptypescript
> \starttypescript [A][AA] ...
> \starttypescript [A][AB] ...
> etc.
>
> Now [A] matches[A][AA] (i.e. [A][][] matching [A][AA][]) and this 
> doesn't work.
> It has the addtional problem that for example typescript [pos] in 
> type-pre.tex (by calling \setupbodyfont[pos]) has a sub-typescript 
> [all][times,helvetica,courier][texnansi] that now will match 
> typescript [A][][]. That was not meant to be the case! At least not by 
> me when I wrote the typesciprt. But if the file containing [A][][] is 
> in the searchpath it will be processed in each round. In some cases it 
> even can lead to an infinite recursion of typescripts.
>
> Setting up things from "back to front" ([AA}[A] etc.) alleviates some 
> of the problems, but does not stop the unwanted occasions where [A] 
> matches [all][other_things].
>
> Do I have it all wrong?
> Thanks to those who will take the trouble to look into this matter.
> Hans van der Meer

Ok, the next release will have: 

\usetypescriptexact

where empty defaults to a false match, so that you can play a bit with that alternative. I'll send you the file.  

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

           reply	other threads:[~2004-08-18 22:19 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <CFBD3A1B-CEA9-11D8-B4EB-003065568054@science.uva.nl>]

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=4123D5D8.60809@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).