ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: "dr. Hans van der Meer" <hansm@science.uva.nl>
Subject: typescript question
Date: Sun, 4 Jul 2004 14:38:09 +0200	[thread overview]
Message-ID: <0195F073-CDB7-11D8-BDF8-003065568054@science.uva.nl> (raw)

[-- Attachment #1: Type: text/plain, Size: 1640 bytes --]

There is something I don't understand about the typescript business 
(using ConText version june 30, 2004):

By calling \setupbodyfont[lbr] the following script (referred to als 
typescript number-1) in type-buy.tex (lines 161-170) is executed:

\starttypescript [lbr]
	\usetypescript [serif,sans,mono,math,calligraphy,handwriting] [lucida] 
  [name,special,\defaultencoding]
	\usetypescript [serif,sans,mono,math,calligraphy,handwriting] 
[default] [size]
	\usemathcollection[lbr]
	\usetypescript [all] [lucida] [\defaultencoding]
\stoptypescript

Also I have defined somewhere else a typescript (number-2):

\starttypescript [Times]
	...
\stoptypescript

WITHOUT the line "...[all]..." in typescript number-1 all goes well, 
lucida fonts result in the product.

However, WITH the line "...[all]..." in typescript number-1 there is 
found the following match, as can be seen in the log (by setting 
\tracetypescriptstrue):

 >>> fonts : enter [Times] [] []
 >>> fonts : check [all] [lucida] [texnansi]
 >>> fonts : matched

Now that seems strange to me. I might be misunderstanding the 
typescript search mechanism, but why does it turn out that the search 
key [lucida] is ignored? Here it seems that after the [all] the 
following search keys are ignored, reducing the check to [all][][]; but 
why then bother giving these 2nd and 3rd key at all? But even if this 
behaviour is implied by giving the first search key as [all], it leads 
to wrong results. Because now the typescript number-2 is executed too, 
working havoc to the font setup.

Is there someone who can enlighten me on these matters? Thanks in 
advance.
Hans van der Meer

[-- Attachment #2: Type: text/enriched, Size: 1688 bytes --]

<fontfamily><param>Courier</param>There is something I don't
understand about the typescript business (using ConText version june
30, 2004):


By calling \setupbodyfont[lbr] the following script (referred to als
typescript number-1) in type-buy.tex (lines 161-170) is executed:


\starttypescript [lbr]

	\usetypescript [serif,sans,mono,math,calligraphy,handwriting]
[lucida]  [name,special,\defaultencoding]

	\usetypescript [serif,sans,mono,math,calligraphy,handwriting]
[default] [size]

	\usemathcollection[lbr]

	\usetypescript [all] [lucida] [\defaultencoding]

\stoptypescript


Also I have defined somewhere else a typescript (number-2):


\starttypescript [Times]

	...

\stoptypescript


WITHOUT the line "...[all]..." in typescript number-1 all goes well,
lucida fonts result in the product.


However, WITH the line "...[all]..." in typescript number-1 there is
found the following match, as can be seen in the log (by setting
\tracetypescriptstrue):


>>> fonts : enter [Times] [] []

>>> fonts : check [all] [lucida] [texnansi]

>>> fonts : matched


Now that seems strange to me. I might be misunderstanding the
typescript search mechanism, but why does it turn out that the search
key [lucida] is ignored? Here it seems that after the [all] the
following search keys are ignored, reducing the check to [all][][];
but why then bother giving these 2nd and 3rd key at all? But even if
this behaviour is implied by giving the first search key as [all], it
leads to wrong results. Because now the typescript number-2 is
executed too, working havoc to the font setup.


Is there someone who can enlighten me on these matters? Thanks in
advance.

Hans van der Meer

</fontfamily>

             reply	other threads:[~2004-07-04 12:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-04 12:38 dr. Hans van der Meer [this message]
2009-11-22 22:52 \vspace Wolfgang Schuster
2009-11-23 10:31 ` \vspace Wolfgang Schuster
2009-11-23 10:52   ` \vspace Hans Hagen
2009-11-23 12:18     ` \vspace Alan BRASLAU
2009-11-26 18:08       ` \vspace Henning Hraban Ramm
2009-11-26 18:42         ` \vspace Hans Hagen
2009-11-26 20:31           ` typescript question Bernhard Rosensteiner
2009-11-26 21:19             ` 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=0195F073-CDB7-11D8-BDF8-003065568054@science.uva.nl \
    --to=hansm@science.uva.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).