LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Mailing list for the LaTeX3 project <[log in to unmask]>
Mon, 27 Nov 2006 15:05:37 +0100
Mailing list for the LaTeX3 project <[log in to unmask]>
text/plain; charset=us-ascii
Frank Mittelbach <[log in to unmask]>
text/plain (68 lines)
Hi Will,

 > > Here's a quick recap as a starting point for discussion:
 > > I think that covers most options / possibilities. Most of the weird
 > > variations get folded into family (so one could have
 > > Thames-Calligraphic Engraved).
 > This is a good taxonomy, but I'm not convinced (any more) that a  
 > fixed scheme is necessary these days. Take fontspec, for example --  
 > it's certainly not perfect, but what features does it lack by not  
 > having a rigid structure for font definitions?

I must confess ignorance on the latest stage of fontspec, but anyway, here are
a few thoughts on the subject

 - to communicate with a font resource (from within a source document) there
   has to be an understanding on the side of the user what the result of
   specifying X means for a certain font resource.

 - now there are several ways and levels on which this understanding can be

    1) on the level of the user: he just knows that normal width font
    resources for family X are called "book" while they are call "regular" for
    font family Y. Dito for all font attributes etc etc.

    2) on an intermediate level, eg as currently provided by NFSS in
    LaTeX. NFSS hides the font resource differences by providing a uniform

    3) on the level of the font resources: the font resource implement a
    uniform model so that this uniform model can be propaged 1-to-1 to the

 - now 3) is clearly wishful thinking which leaves 1) or 2)

why do you want to have an intermediate layer? basically to allow for easy
configuration changes and flexibility. it is the old story: unless you build a
common exchange layer modification is more than painful.

If you go for option 1) then

 - the user has potentially more flexibility in specification

 - he/she has to know what individual font resources provide and how they call
   what they provide

 - update/changes, eg replacing one font family with another is a major effort
   within a document, same for material reuse.

So in short, in my opinion an intermediate layer that unifies the interface
from the user perspecitive is more than beneficial. It is true that the axis
concept of NFSS (which was born out of the evailable font resources and the
possibility given in TeX installations back then) is no longer fully adequate
but in my opinion theway forward would be an extended/variant model on the
same level, rather than one on the user level.

by the way an intermediate interface model wouldn't need to have a fixed axis
set, it could very well work with an open-ended attributes --- the important
point would be that it would provide a uniform set of attributes with a single
set of conventions regards of how font resources implement those attributes
eventually (that level of translation would happen behind the scenes in the