ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Hans Hagen <pragma@wxs.nl>
Subject: Re: proposed convention for variation switching	[wasRE:inheriting ...
Date: Fri, 22 Apr 2005 10:16:47 +0200	[thread overview]
Message-ID: <4268B2EF.2070007@wxs.nl> (raw)
In-Reply-To: <20050421205604.33@mail.comp.lancs.ac.uk>

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
-----------------------------------------------------------------

  parent reply	other threads:[~2005-04-22  8:16 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-21 18:36 Idris Samawi Hamid
2005-04-21 19:56 ` Adam Lindsay
2005-04-21 22:43   ` Vit Zyka
2005-04-21 23:00     ` Adam Lindsay
2005-04-22  8:16   ` Hans Hagen [this message]
2005-04-22  9:38     ` Vit Zyka
2005-04-22 14:36     ` Idris Samawi Hamid
2005-04-22 14:55       ` Adam Lindsay
2005-04-22 17:13         ` Idris Samawi Hamid
2005-04-21 19:59 ` Adam Lindsay
2005-04-21 23:53 Idris Samawi Hamid
2005-04-22  8:45 ` Vit Zyka
2005-04-22  9:03   ` Taco Hoekwater

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4268B2EF.2070007@wxs.nl \
    --to=pragma@wxs.nl \
    --cc=ntg-context@ntg.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).