[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Italic Small Caps



Thierry Bouche wrote:
> 
> "M.E. O'Neill" a écrit :
> > I was recently looking at some old metrics and FD files made by an
> > ancient version of fontinst (1.335), and saw that they included italic
> > small-caps (which were actually faked).
> 
> this reminds me something...
> 
> >    - Which should it be, `itsc' or `scit'?
> 
> whatever you want, as there are no standards at all. I heard that Alan
> Hoenig used `si'. If you have my minion metrics, you probably also have

ci, i.e. small Caps font, Italic style

> minion.sty where i say \let\scit\itsc, proving that i can't rememebr
> myself which i choosed...
> 
> >    - Why doesn't \latinfamily make italic small-caps metrics?
> 
> It could probably. The rationale would be to first try the actual thing
> (needs a standard kb name); then by italising the sc in the sc font, hen
> by faking it totally.

MEO> Not having a real italic
MEO> small caps font isn't necessarily a problem, because an oblique
version
MEO> of a real roman small caps font could be an acceptable substitute. 
Even
MEO> if a user doesn't have a real small caps font, faked italic small
caps
MEO> are no uglier than faked roman small caps.

Ugh! You have italic caps available, why you would want to fake them by
slanting???
(Yes, it is essential here to mix fonts ;-)

> 
> But, as it's out of nfss' scope (as are EC scsl fonts), probably noone
> will want to do that...

Those who could do it do not consider it as essential (perhaps even
count is as an "advantage" to have such a restricted scheme).
A more flexible, i.e. extendable scheme could help TeX to survive a bit
longer in a world of developping software...
 
> Daniel Taupin found a workaround for \textsc{\emph{...}} by making small
> caps a family rather than a shape. People from the latex team said once

Well, the only practical way is to define a family for dealing with the
attributes.
The reason is obviously that NFSS has no way to combine more than two
font attributes for a family (aside from the encoding, which is only
available in NFSS2): shape + series.

For a workaround, which is a bit simpler, I considered it as sensible
also to use \sl for scit since for proper font application there is not
much room to use slanted versions (except for those fonts where you have
real slanted designs).

> that the proper `fix' would be to add a new nfss axis called `case'
> (making us rid of MakeUppercase troubles, etc.) but this was never
> implemented, afaik.

I don't know if "case" will give us relief here. Indeed it is the
restricted philosophy of axes, just similar to the problem of only 4
attributes beeing possible for one font name in M$-Win...
 
> Thierry
> 
> PS When using a MM font with design size axis, you're far away from
> anything latinfamily can handle anyway (a typical font name would be
> pmnrci7d12.afm !)
mnci712.afm?

Hilmar Schlegel

###