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 f1N9B7r05043 for ; Fri, 23 Feb 2001 10:11:07 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f1N9B6s11556 . for ; Fri, 23 Feb 2001 10:11:07 +0100 Received: from mail.Uni-Mainz.DE (mailserver1.zdv.Uni-Mainz.DE [134.93.8.30]) by mailgate2.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f1N9AwQ10775 for ; Fri, 23 Feb 2001 10:10:58 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09D78.8DFA4780" 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 KAA20374 for ; Fri, 23 Feb 2001 10:10:54 +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 f1N9AqQ10767 for ; Fri, 23 Feb 2001 10:10:52 +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 <0.57BF0DDA@mail.listserv.gmd.de>; Fri, 23 Feb 2001 10:10:42 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 492919 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Fri, 23 Feb 2001 10:10:47 +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 KAA11755 for ; Fri, 23 Feb 2001 10:10:45 +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 KAA44974 for ; Fri, 23 Feb 2001 10:10:43 +0100 Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f1N9Agx01230 for ; Fri, 23 Feb 2001 10:10:42 +0100 (MET) Received: from [195.20.224.219] (helo=mrvdom03.kundenserver.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 14WEFO-00002b-00 for LATEX-L@urz.uni-heidelberg.de; Fri, 23 Feb 2001 10:10:42 +0100 Received: from manz-3e36596d.pool.mediaways.net ([62.54.89.109] helo=istrati.zdv.uni-mainz.de) by mrvdom03.kundenserver.de with esmtp (Exim 2.12 #2) id 14WEF5-0001L8-00 for LATEX-L@urz.uni-heidelberg.de; Fri, 23 Feb 2001 10:10:23 +0100 Received: (from latex3@localhost) by istrati.zdv.uni-mainz.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id KAA08349; Fri, 23 Feb 2001 10:08:20 +0100 In-Reply-To: References: <14984.13275.957442.490284@istrati.zdv.uni-mainz.de> Return-Path: X-Mailer: VM 6.75 under Emacs 20.4.1 X-Authentication-Warning: istrati.zdv.uni-mainz.de: latex3 set sender to frank@mittelbach-online.de using -f Content-class: urn:content-classes:message Subject: Re: insufficent NFSS model (?) Date: Fri, 23 Feb 2001 10:08:19 +0100 Message-ID: <14998.10371.943812.829077@istrati.zdv.uni-mainz.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Frank Mittelbach" 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: 4004 This is a multi-part message in MIME format. ------_=_NextPart_001_01C09D78.8DFA4780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Roozbeh, > Javier explained the idea somehow. I'm going into complete = explanation > here. Please ask for clarification if there are ambiguities. thanks, I think it has helped, but as you can imagine there are a number = of questions. very first one, let's for the moment forget about the high-level NFSS = commands like \textbf and so on and just concentrate on the low-level interface = which can be perhaps sumarised as fonts are classified according to four different axises NFSS calls them family series shape (and implicitly sizes) but to some = extend at least "series" and "shape" are abstract names. first question: assuming you give adequate meaning to these names, are the fonts used = in your typography adequately modelled by four axises? from what i understand the answer is probably yes. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D the series attribute for Latin fonts actually encodes a combination of = width and weight; I did choose this for the model because independent changes = seemed seldom at least not within a document (i'm talking only about text fonts = here not math!) second question: i do understand that you have some characteristics in the fonts that = are suitably modelled as a series though you say you consider outline a part = of it. is that roughly correct? actually although outlines are mentioned in the LaTeX Companion (and = probably in fntguide) as a value for the shape attribute, I think it is something = that actually far better belongs to the series if one sticks within 4 axises =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > In Persian, we usually do not have the three classic families. In = Iran, well, Latin typography doesn't has these three either, i'd say. it is = true that we have some understanding what is meant by a typewriter font but = this is essentially - by its use as computer input output - by its being monospaced categories for font families is more like 6-9 depending on school, but existance of serifs is clearly an outstanding attribute for a latin = based font. However, mixture of \sf and \rm in running text is rather uncommon (unless for very specific items ---the LaTeX commands \textsf and = \textrm are really a historical accident due to what is there in plain TeX). i'm not saying that there aren't designs mixing serifed and nonserifed = fonts, eg in headings or running heads or other design items. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Because of this lack of option, outline and shaded-outline shapes are = used > much more in technical books, sometimes together with slanted and > backslanted. The model that is used in available Persian software, > modeled from how designers think, is something like this: > > family weight shape > ------ ------ ----- > normal medium upright > italics bold slanted > some others outline backslanted > shaded-outline you say that italics are considered by designers a family. okay, but you = don't have all the shape attributes for such a family, do you? ie upright, = slanted, and backslanted? anyway, if you just consider Persian text as such (not multilingual = documents mixing it with latin, say) then i don't see why the NFSS model would not serve. On the high-level commands you may need something like \itfamily and = disable \sffamily and something like \emph would select a family rather than a = shape etc but the underlying model would not be affected, would it? perhaps it would be worth thinking about how the high-level interface = could be made more adaptable to different languages. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 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 you are right, multilingual documents are different. I think the first question that needs to be asked is: Do we have a predominant language A with infrequent embeddings from a different language/script B? In that case I guess one should try to map = the meanings of the high-level commands as best as one can using those from = the dominant language, eg Something like "bf" for latin scripts could perhaps be translated to = mean "outline" in persian context or it could mean "bold nonextended". the idea being that one tries to make the best of \textbf{Some English text with a few \langfragment{persian}{Persian = words} in the middle} so that this blends as best as possible (clearly a designer issue). This should work both ways, ie if you have different high-level commands = in languages like Persian and you have a multilingual document with = dominant language Persian one should map the "persian-high-levels". More complicated perhaps are situations where the different scripts are = really equivalent in use. do we then map all such high-level commands, do we = use them all, do we just use one set, nevertheless? no good answers here i fear =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D back to the model of "classical" families > In the absense of that model, designers choose some families (for > a mathematical book, I've seen from as few as one, to as many as six = or > seven), and specify that this heading or that caption should come out = as > in this family and that shape and size. but this is exactly the way design works here as well. okay, article.cls = makes all headings simply by using the body font in a bolden version (and = since the default is CM fonts in bx) but classes with a real design would = typically specify individual fonts in certain weight, shape and size for the = individual elements of the design. what is perhaps missing in LaTeX are different levels of emphasis, ie we = have \emph{...} or {\em ...} but for any other textual emphasis people have = to use \textbf or \textsf or the like rather than being offered and abstraction = which could then be filled with life by the designer. frank ------_=_NextPart_001_01C09D78.8DFA4780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: insufficent NFSS model (?)

Roozbeh,

 > Javier explained the idea somehow. I'm = going into complete explanation
 > here. Please ask for clarification if = there are ambiguities.

thanks, I think it has helped, but as you can imagine = there are a number of
questions.

very first one, let's for the moment forget about the = high-level NFSS commands
like \textbf and so on and just concentrate on the = low-level interface which
can be perhaps sumarised as

 fonts are classified according to four different = axises

NFSS calls them family series shape (and implicitly = sizes) but to some extend
at least "series" and "shape" are = abstract names.

first question:

 assuming you give adequate meaning to these = names, are the fonts used in your
 typography adequately modelled by four = axises?

from what i understand the answer is probably = yes.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

the series attribute for Latin fonts actually encodes = a combination of width
and weight; I did choose this for the model because = independent changes seemed
seldom at least not within a document (i'm talking = only about text fonts here
not math!)

second question:

 i do understand that you have some = characteristics in the fonts that are
suitably modelled as a series though you say you = consider outline a part of
it. is that roughly correct?

actually although outlines are mentioned in the LaTeX = Companion (and probably
in fntguide) as a value for the shape attribute, I = think it is something that
actually far better belongs to the series if one = sticks within 4 axises

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 > In Persian, we usually do not have the = three classic families. In Iran,

well, Latin typography doesn't has these three either, = i'd say. it is true
that we have some understanding what is meant by a = typewriter font but this is
essentially

 - by its use as computer input output
 - by its being monospaced

categories for font families is more like 6-9 = depending on school, but
existance of serifs is clearly an outstanding = attribute for a latin based
font. However, mixture of \sf and \rm in running text = is rather uncommon
(unless for very specific items ---the LaTeX commands = \textsf and \textrm are
really a historical accident due to what is there in = plain TeX).

i'm not saying that there aren't designs mixing = serifed and nonserifed fonts,
eg in headings or running heads or other design = items.



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


 > Because of this lack of option, outline and = shaded-outline shapes are used
 > much more in technical books, sometimes = together with slanted and
 > backslanted. The model that is used in = available Persian software,
 > modeled from how designers think, is = something like this:
 >
 > = family        = weight           &= nbsp; shape
 > = ------        = ------           &= nbsp; -----
 > = normal        = medium           &= nbsp; upright
 > = italics       = bold           &nb= sp;   slanted
 > some others   = outline           = backslanted
 >         =       shaded-outline

you say that italics are considered by designers a = family. okay, but you don't
have all the shape attributes for such a family, do = you? ie upright, slanted,
and backslanted?

anyway, if you just consider Persian text as such (not = multilingual documents
mixing it with latin, say) then i don't see why the = NFSS model would not
serve.

On the high-level commands you may need something like = \itfamily and disable
\sffamily and something like \emph would select a = family rather than a shape
etc but the underlying model would not be affected, = would it?

perhaps it would be worth thinking about how the = high-level interface could be
made more adaptable to different languages.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 > 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

you are right, multilingual documents are different. I = think the first
question that needs to be asked is:

 Do we have a predominant language A with = infrequent embeddings from a
different language/script B? In that case I guess one = should try to map the
meanings of the high-level commands as best as one = can using those from the
dominant language, eg

Something like "bf" for latin scripts could = perhaps be translated to mean
"outline" in persian context or it could = mean "bold nonextended".

the idea being that one tries to make the best = of

 \textbf{Some English text with a few = \langfragment{persian}{Persian words} in
         the = middle}

so that this blends as best as possible (clearly a = designer issue).

This should work both ways, ie if you have different = high-level commands in
languages like Persian and you have a multilingual = document  with dominant
language Persian one should map the = "persian-high-levels".

More complicated perhaps are situations where the = different scripts are really
equivalent in use. do we then map all such high-level = commands, do we use them
all, do we just use one set, nevertheless?

no good answers here i fear

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

back to the model of "classical" = families

 > In the absense of that model, designers = choose some families (for
 > a mathematical book, I've seen from as few = as one, to as many as six or
 > seven), and specify that this heading or = that caption should come out as
 > in this family and that shape and = size.

but this is exactly the way design works here as well. = okay, article.cls makes
all headings simply by using the body font in a = bolden version (and since the
default is CM fonts in bx) but classes with a real = design would typically
specify individual fonts in certain weight, shape and = size for the individual
elements of the design.

what is perhaps missing in LaTeX are different levels = of emphasis, ie we have
\emph{...} or {\em ...} but for any other textual = emphasis people have to use
\textbf or \textsf or the like rather than being = offered and abstraction which
could then be filled with life by the = designer.

frank

------_=_NextPart_001_01C09D78.8DFA4780--