From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.tex.context/15636 Path: main.gmane.org!not-for-mail From: "dr. Hans van der Meer" Newsgroups: gmane.comp.tex.context Subject: typescript question Date: Sun, 4 Jul 2004 14:38:09 +0200 Sender: ntg-context-admin@ntg.nl Message-ID: <0195F073-CDB7-11D8-BDF8-003065568054@science.uva.nl> Reply-To: ntg-context@ntg.nl NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 (Apple Message framework v618) Content-Type: multipart/alternative; boundary=Apple-Mail-1--1031659969 X-Trace: sea.gmane.org 1088944883 29651 80.91.224.253 (4 Jul 2004 12:41:23 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 4 Jul 2004 12:41:23 +0000 (UTC) Original-X-From: ntg-context-admin@ntg.nl Sun Jul 04 14:41:13 2004 Return-path: Original-Received: from ref.vet.uu.nl ([131.211.172.13] helo=ref.ntg.nl) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Bh6Iz-0000gX-00 for ; Sun, 04 Jul 2004 14:41:13 +0200 Original-Received: from ref.ntg.nl (localhost.localdomain [127.0.0.1]) by ref.ntg.nl (Postfix) with ESMTP id 3A73710B2D; Sun, 4 Jul 2004 14:41:10 +0200 (MEST) Original-Received: from smtp.science.uva.nl (smtp.science.uva.nl [146.50.4.84]) by ref.ntg.nl (Postfix) with ESMTP id BC3C110AE5 for ; Sun, 4 Jul 2004 14:38:48 +0200 (MEST) Original-Received: from 118-160.uva.surfnetthuis.nl [145.98.118.160] by smtp.science.uva.nl with ESMTP (sendmail 8.11.6p2/config 11.35). id i64CclA06856; Sun, 4 Jul 2004 14:38:47 +0200 X-Organisation: Faculty of Science, University of Amsterdam, The Netherlands X-URL: http://www.science.uva.nl/ Original-To: NTG ConTeXt X-Mailer: Apple Mail (2.618) X-Virus-Scanned: by amavisd-new Errors-To: ntg-context-admin@ntg.nl X-BeenThere: ntg-context@ntg.nl X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: mailing list for ConTeXt users List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.comp.tex.context:15636 X-Report-Spam: http://spam.gmane.org/gmane.comp.tex.context:15636 --Apple-Mail-1--1031659969 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed 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 --Apple-Mail-1--1031659969 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII CourierThere 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 --Apple-Mail-1--1031659969--