[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: raw font encodings
- To: email@example.com
- Subject: Re: raw font encodings
- From: firstname.lastname@example.org (Alan Jeffrey)
- Date: Fri, 8 Apr 94 14:27 BST
- Cc: email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
- In-Reply-To: <199404080144.SAA22648@june.cs.washington.edu> (email@example.com)
>It is specifically for a raw font encoding, set up to ensure that
>all simplex characters are at least available for the output font
>encoding, which I treat as variable.
Yes, this is very close to what we want, *except* that we'd like an
encoding which includes the composite glyphs, for two reasons:
a) in some fonts, the composite glyphs aren't the same as the glyphs
built from the appropriate simplexes, for example <Aacute> and
<aacute> may use a different sized <acute> accent.
b) in any Type 1 font with hints, there can be no hints between glyphs
built from simplexes, so the <cedilla> and <c> in <ccedilla> may end
up colliding, which they wouldn't in a hinted <ccedilla>.
c) the PostScript produced by using virtual composite characters is
longer. Printing out the Cork alphabet with dvips uses 1.3K with raw
composite characters, and 2.1K with virtual ones. So I'd guess that a
long PostScript document with heavy accenting would be 20--50% longer
if the accents are produced virtually.
One possibility (suggested off-line by Don Hosek) would be to have the
raw font encoded with the same encoding as the virtual font, so for T1
(Cork) encoded Adobe Times the raw font would contain all the T1
glyphs which Adobe provide, and then the VF would `fill in the gaps'.
The problem with this is that if you want to use the same font with a
number of different virtual encodings, you need a different raw font
each time. Looking (not very far, I hope!) into the future, there are
plans for a Text Symbol (TS) encoding to hold glyphs like <copyright>
and <yen> which are missing from T1. It would be nice if the
T1-encoded and TS-encoded VFs could both point to the same raw font,
because this halves the number of raw TFMs needed.
So... there's a trade-off between three options:
a) Provide a raw encoding containing all the Adobe Standard and ISO
b) Have the T1 VFs point to a sparse T1-encoded raw font.
c) Don't include composite glyphs in the raw encoding.
The respective problems are:
a) Requires the use of slots 0--31, which some previewers can't
b) Requires (at least) twice as much disk space for raw fonts,
produces PostScript which uses more raw fonts.
c) Doesn't allow hinting or designed glyphs, produces longer
... are there other options? ...