ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Idris Samawi Hamid <ishamid@lamar.colostate.edu>
Subject: RE: proposed convention for variation switching [wasRE:inheriting ...
Date: Thu, 21 Apr 2005 17:53:09 -0600	[thread overview]
Message-ID: <4278A2EE@webmail.colostate.edu> (raw)

>===== Original Message From Vit Zyka <vit.zyka@seznam.cz> =====
>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.

ok, but this is my take: although I can find workarounds that work for me, 
next month other some users will have to go through the same pain as I did, 
which seems to me to be a waste of collective energy. A standard solution for 
the 12 or so common variants of professional fonts just makes things easier 
for others, which is part of the whole ConTeXt philosophy (or so I thought). 
Everybody should not have to go through more than the minimal energy and time 
writing typescripts and defining font sizes. A standard convention will ensure 
some consistency and predictability.

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

Let's keep \sc. After all, ConTeXt already contains many redundancies (and 
that's a good thing imho->)

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

Let's keep the semibold options: medium, semibold, and bold form a common 
spectrum _within_ many a professional font family.

If we as users and writers of typescripts can agree on a common framework, it 
is perhaps more likely that the developers will implement it.

My sole interest here is saving future users as much pain and frustration as 
possible. And I want to see more and more future users, including those with 
little technical facility. Fonts carry more _standard_ options than before: I 
don't think that updating to 12 standard style switches from 7 should be such 
a big deal:-)

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

If pdfeTeX ever incorporates aleph's features this would all be much easier-) 
Till then...

Not sure I fully understand but here are some comments:

For A) If there is a global issue (like oldstyle) that covers all font 
variations, then your Var[#1] idea sounds nice. One could even do that with 
small caps for professional fonts but those are so ubiquitous that an 
exception would be in order for them (so small caps should always have a 
switch);

(I think that \Var[up] (for upright figures) is more intuituve that \Var[ns]), 
at least in English:-)))

B) Again, for a comprehensive framework we should keep semibold (and perhaps 
add light), for a total of 6(7)+symbols/ornaments;

C) If an option like condensed is global over all style variants, then it 
should go in \Var[#1].

If it is local and is a common feature of professional fonts (like semibold), 
then we need a local switch framework, in which case the switch mechanism 
needs to be improved so that user-defined switches work in harmony with the 
predefined ones in every relevant respect.

These are not final thoughts, but the beginnings of what could develop into a 
coherent framework for weights and style variation. I truly hope we can come 
to a common undestanding for the sake of future neophytes.

ADDENDUM:
Proposed framework:

Global options across all style variants and weights should go into something 
like Vit's \Var[#1] or a separate font-definition typescript.

For local options we can go on indefinitely but if we have to stop somewhere 
then we should by default have at least:

% lowercase
light \lf 
medium \tf
semibold \sb
bold \bf
lightitalic \lt
italic \it
semibold italic \st
bold italic \bi

% small caps
light \LF
medium \TF
semibold \SB
bold \BF
lightitalic \LT
italic \IT
semibold italic \ST
bold italic \BI

for a total of 16 simple and easy to remember switches, which should be rich 
enough to accomodate most professional modern fonts in \definebodyfont. Less 
common weights etc. can mostly be defined in terms of the standard 16 in 
\definebodyfont, then used as \Var.

Of course the user can still define his/her own, but the idea is to make the 
most convenient reasonable framework to cover the most-often encountered 
situations. I think that the above 16 strikes a reasonable balance between the 
mundane and the esoteric.

Sorry for the verbosity.

Best
Idris

============================
Professor Idris Samawi Hamid
Department of Philosophy
Colorado State University
Fort Collins, CO 80523

             reply	other threads:[~2005-04-21 23:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-21 23:53 Idris Samawi Hamid [this message]
2005-04-22  1:11 ` fontsite 500 CD Ciro Soto
2005-04-22  8:45 ` proposed convention for variation switching [wasRE:inheriting Vit Zyka
2005-04-22  9:03   ` Taco Hoekwater
  -- strict thread matches above, loose matches on Subject: below --
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
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

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=4278A2EE@webmail.colostate.edu \
    --to=ishamid@lamar.colostate.edu \
    --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).