Adam Lindsay wrote:

It's not that I'm trying to rain on your parade, it's just that I've lost a bit of enthusiasm for standardisation.

I generally agree with Adam, fonts are very varios. But the next Idris idea is nice. More intuitive then \sc, \bc, \ic, and \bic. I would vote for it, but ... at least \sc needs some backward compatibility :-(

...

%% small caps % medium \TF % bold \BF % italic \IT % bold italic \BI

Another discussion proposal: I will get the rest font families from Storm to make the support complete. So I will have to solve many similar problems with naming conventions. So I am interesting about some recommendations. What way to solve via A) variants via \Var[...] B) \tf, \bf, ... switches, C) different font family. For now I am using: A) for extended glyph definitions and old style digits {Var[os]} (if they are not default in the font - in that case there might be reverse normal style digit variant \Var[ns?]). B) standard 4 + small caps + symbols/ornaments designed to the font {\sy} C) condensed, extended, medium, ... Some comments? Cheers, vit

Adam Lindsay wrote:

Hi Idris,

I've brought the subject up repeatedly on the list, and got not a lot of response. I have to think that 1) people are happy with the standard 7 font styles, 2) people have their own hand-rolled solution (like yourself, myself or Vit--see his Storm fonts support for some nice ideas), or 3) as Hans keeps bringing up, there are other ways around it. (Layered definitions, etc., which I'm coming around to think is a better discipline with markup.)

I'd say take a look at Vit's and my typescripts (I don't directly address semibold, because semibold markup in running text doesn't usually work): http://typokvitek.com/stormcontext/ http://homepage.mac.com/atl/tex/OpenType.zip

The antykwa-torunska typescripts in the main distro also point at ways of accessing smallcaps and semibold via \Var[] variants from the main seven styles: http://source.contextgarden.net/tex/context/base/type-syn.tex

It's not that I'm trying to rain on your parade, it's just that I've lost a bit of enthusiasm for standardisation.

the problem is that we have to deal with old methods as well as new ones; there is also a speed issue involved. one of the handicaps is that we need to deal with math; on the other hand, in a mathless usage, a different font scheme is possible [we can even implement a new one]

Idris Samawi Hamid said this at Thu, 21 Apr 2005 12:36:55 -0600:

...

My suggestion: Either a) the \*a(b)(c) etc mechanism needs modification to accomodate >2-char switches, or b) an official 2-char switching convention for dealing with semibold and the standard five variants of small caps in ConTeXt is needed. Ideally users should not have to define switches for these standard variants anyway.

Here is an idea (further discussion needed):

a) Let's assume no change to the ConTeXt internals to accomodate >2-char switches.

the a/b/c/d are something from the past; since typefaces switch pretty quick, one can also switch the bodyfontsize (i can imagine something \sizea \sizeb ...) thinking of it, it may be an option if i look into an alternative implementation with (for backwar dcompatibility) \def\tfa{\sizea\tf} like definitions with \sizea being a bodyfont switch to a larger size (one problem is that in that cas ethe baseline distance would also be influences, so it may not be good idea after all)

...

b) There are twelve basic style variants in a professional modern serif font (math, greek, etc excluded): six for lower case and six for small caps.

On this basis, here is my suggestion for an official ConTeXt convention for professional fonts:

%% lowercase % medium \tf % semibold \sb % bold \bf % italic \it % semibold italic \st % bold italic \bi

%% small caps % medium \TF % semibold \SB % bold \BF % italic \IT % semibold italic \ST % bold italic \BI

the main problem here is this math family business so some choices need to be made (math does not mix well with text anyway) i'm not that much in favour of capitalized named (clashes with user commands as well as some internals), so \scbf is more likely also, whatever system we cook up ... there are so many bold variants nowadays in some fonts ... in practice one will not mix semi bold and bold in a running text, so again, this can be done by typefaces as well: \definetypeface[normalface] [...] \definetypeface[bolderface] [...] \definetypeface[cappedface] [...] and in places where this special bolder face is used, just switch to \bolderface

...

The small caps versions are identical to the lowercase versions, with the difference that the small caps versions use caps. This serves as a mnemonic device.

We also need some long-winded control sequences:

\definestyle [semiboldroman,semibold] [\sb][] \definestyle [semibolditalic] [\st][] \definestyle [smallcapssemibold,semiboldsmallcaps] [\SB][] \definestyle [smallcapsbold,boldsmallcaps] [\BF][] \definestyle [smallcapsitalic,italicsmallcaps] [\IT][] \definestyle [smallcapssemibolditalic,semibolditalicsmallcaps][\ST][] \definestyle [smallcapsbolditalic,bolditalicsmallcaps] [\BI][]

An identical or similar analysis may work for sans-serif, but I have to check...

before i do something with this i need to think it over; (and look at the storm definitions and adamns stuff more closely; keep in mind that with xetex and open type being around we may need even more features) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Hi Hans, On Fri, 22 Apr 2005 10:16:47 +0200, Hans Hagen wrote:

i'm not that much in favour of capitalized named (clashes with user commands as well as some internals), so \scbf is more likely

Heh, heh, that was my original idea; with 2-char capitals I was trying to find a way to help you avoid the late nights, headaches, etc.-) but if \tfa, etc. will soon be obsolete and replaced with \sizea etc., then we I'm quite happy to go back to \scbf etc. In any case whatever high-level framework we come up with should largely be determined by your decision on the low/mid-level framework. Best Idris -- Professor Idris Samawi Hamid Department of Philosophy Colorado State University Fort Collins, CO 80523

On Fri, 22 Apr 2005 15:55:19 +0100, Adam Lindsay wrote:

Idris Samawi Hamid said this at Fri, 22 Apr 2005 08:36:02 -0600:

...

In any case whatever high-level framework we come up with should largely be determined by your decision on the low/mid-level framework.

See, I beg to differ.

I agree with virtually everything u said, but _maybe_ u missed my point:-)) If Hans either implements a) >2-char swutch support; or b) \sizea(b)(c) etc, it affects whether the high-level framework will need to use capital 2-char switches or have the option of using unrestricted lower-case switches in whatever framework we agree on. Your point is on the framework being _mentioned_, mine was on the language _used_ to mention the framework (perhaps I should have made that clearer). The logic of the framework used should be largely independent, but the language we use to mention it partly depends on the internal implementation. I look forward to our final consensus! Best Idris -- Professor Idris Samawi Hamid Department of Philosophy Colorado State University Fort Collins, CO 80523