Received: from webgate.proteosys.de (mail.proteosys-ag.com [62.225.9.49]) by lucy.proteosys (8.11.0/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id f1DLn5H28348 for ; Tue, 13 Feb 2001 22:49:05 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f1DLn4d03107 . for ; Tue, 13 Feb 2001 22:49:04 +0100 Received: from mail.Uni-Mainz.DE (mailserver1.zdv.Uni-Mainz.DE [134.93.8.30]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f1DLn3M28829 for ; Tue, 13 Feb 2001 22:49:03 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09606.C8D8DE80" Received: from mailgate2.zdv.Uni-Mainz.DE (mailgate2.zdv.Uni-Mainz.DE [134.93.8.57]) by mail.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id WAA27359 for ; Tue, 13 Feb 2001 22:49:03 +0100 (MET) Received: from mail.listserv.gmd.de (mail.listserv.gmd.de [192.88.97.5]) by mailgate2.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f1DLn1712130 for ; Tue, 13 Feb 2001 22:49:02 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <4.9AC117C3@mail.listserv.gmd.de>; Tue, 13 Feb 2001 22:48:54 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 489055 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Tue, 13 Feb 2001 22:48:59 +0100 Received: from ix.urz.uni-heidelberg.de (mail.urz.uni-heidelberg.de [129.206.119.234]) by relay.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id WAA10881 for ; Tue, 13 Feb 2001 22:48:57 +0100 (MET) Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by ix.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id WAA20702 for ; Tue, 13 Feb 2001 22:48:56 +0100 Received: from musse.tninet.se (musse.tninet.se [195.100.94.12]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with SMTP id f1DLmrg20278 for ; Tue, 13 Feb 2001 22:48:53 +0100 (MET) Received: (qmail 28243 invoked from network); 13 Feb 2001 22:48:52 +0100 Received: from garibaldi.tninet.se (HELO algonet.se) (195.100.94.103) by musse.tninet.se with SMTP; 13 Feb 2001 22:48:52 +0100 Received: from [195.100.226.152] (du152-226.ppp.su-anst.tninet.se [195.100.226.152]) by garibaldi.tninet.se (BLUETAIL Mail Robustifier 2.2.1) with ESMTP id 53823.100929.982garibaldi-s1 for ; Tue, 13 Feb 2001 22:48:49 +0100 In-Reply-To: References: <14984.13275.957442.490284@istrati.zdv.uni-mainz.de> Return-Path: X-Sender: haberg@pop.matematik.su.se (Unverified) Content-class: urn:content-classes:message Subject: Re: insufficent NFSS model (?) Date: Tue, 13 Feb 2001 22:47:31 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Hans Aberg" Sender: "Mailing list for the LaTeX3 project" To: "Multiple recipients of list LATEX-L" Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 3902 This is a multi-part message in MIME format. ------_=_NextPart_001_01C09606.C8D8DE80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 12:48 +0330 2001/02/13, Roozbeh Pournader wrote: >In Persian, we usually do not have the three classic families. In Iran, >there is rarely a need for typewriter style, that's only used for Latin >texts, and in the case they really need to show Persian on the screen, >they use screenshots. Also, I know only three non-bitmap typewriter = fonts, >and the only almost-free one is MS Courier. I use one of the other two >when writing a manual, but I'm among the few who use such a thing. I am not sure that the NFSS model is so suitable for European languages = & Latin alphabets either, as it is quite difficult to find a good set of fonts matching each other except for the NFSS attributes. In math mode, = it is of course important to have a set matching each other in wehat can be thought of appear side-by-side in math formulas. Instead (as an input), I tend to think of the fonts as having a set of attributes. If one group together some fonts together with different attributes, one might get a font-family. But different font families may have different sets of attributes available. Here are some attributes that come to my mind: ligatures: sans-serif, serif weight: thin, medium, bold, heavy slantedness: left, upright, right monospace: false, true extendedness: narrow, condensed, normal, extended outline: false, true shaded: false, true A full attribute would be a choice of tuples (ligatures, weight, slantedness, monospace, extendedness, outline, = shaded) and a set of fonts with different atributes would be a font family. Some attributes may be needed to be made more detailed by more choices. >This the Persian model only. Then you need Latin. For each of the = styles >that also may contain Latin text, they should use an equivalent fonts >that goes with it. There are some difficulties here also, one of them >being the different direction and hence different slants: there are few >backslanted Latin fonts, so you need to use slanted or italic Latin = with >backslanted Persian (which is as ugly as any backslanted font in any >script). So this might be possible then with such a model. Hans Aberg ------_=_NextPart_001_01C09606.C8D8DE80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: insufficent NFSS model (?)

At 12:48 +0330 2001/02/13, Roozbeh Pournader = wrote:
>In Persian, we usually do not have the three = classic families. In Iran,
>there is rarely a need for typewriter style, = that's only used for Latin
>texts, and in the case they really need to show = Persian on the screen,
>they use screenshots. Also, I know only three = non-bitmap typewriter fonts,
>and the only almost-free one is MS Courier. I use = one of the other two
>when writing a manual, but I'm among the few who = use such a thing.

I am not sure that the NFSS model is so suitable for = European languages &
Latin alphabets either, as it is quite difficult to = find a good set of
fonts matching each other except for the NFSS = attributes. In math mode, it
is of course important to have a set matching each = other in wehat can be
thought of appear side-by-side in math = formulas.

Instead (as an input), I tend to think of the fonts as = having a set of
attributes. If one group together some fonts together = with different
attributes, one might get a font-family. But = different font families may
have different sets of attributes available.

Here are some attributes that come to my mind:

ligatures: sans-serif, serif
weight: thin, medium, bold, heavy
slantedness: left, upright, right
monospace: false, true
extendedness: narrow, condensed, normal, = extended
outline: false, true
shaded: false, true

A full attribute would be a choice of tuples
 (ligatures, weight, slantedness, monospace, = extendedness, outline, shaded)
and a set of fonts with different atributes would be = a font family. Some
attributes may be needed to be made more detailed by = more choices.

>This the Persian model only. Then you need Latin. = For each of the styles
>that also may contain Latin text, they should use = an equivalent fonts
>that goes with it. There are some difficulties = here also, one of them
>being the different direction and hence different = slants: there are few
>backslanted Latin fonts, so you need to use = slanted or italic Latin with
>backslanted Persian (which is as ugly as any = backslanted font in any
>script).

So this might be possible then with such a = model.

  Hans Aberg

------_=_NextPart_001_01C09606.C8D8DE80--