[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: raw font encodings
- To: firstname.lastname@example.org (Alan Jeffrey)
- Subject: Re: raw font encodings
- From: Barry Smith <email@example.com>
- Date: Mon, 11 Apr 94 16:20:55 PDT
- Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
- In-Reply-To: <m0pqPI2-000073C@csrj.crn.cogs.susx.ac.uk>; from "Alan Jeffrey" at Apr 11, 94 5:56 pm
> There is a third (which appeals quite strongly to me):
> 3. Use Windows ANSI for slots 32--255, and put the missing glyphs
> (<fi>, <fl>, <dotlessi>, <dotlessj>, <ring>, <caron>, <dotaccent>,
> <breve>, <hungarumlaut> and <ogonek>) somewhere in slots 1--31.
> These slots can't be used by some Windows applications, but since
> the glyphs don't exist in Windows ANSI encoding anyway, this may not
> be a problem.
> The problem with this approach is that it means that documents
> containing `fi' or `fl' which are printed with TrueType fonts will end
> up with missing glyphs. But the only way round this is to have
> separate metrics and VFs for the TrueType fonts, without the `fi' and
> `fl' ligatures (any better suggestions anyone)?
> Oh, another problem may be with Macs, which do have <fi> and <fl>, and
> some applications may not like having them mapped to slots in the
> range 0--31.
This one gets a pretty sharp response from here; any "solution" that
omits fi and fl ligatures is a non-starter! I understand (vaguely) that
TrueType has weird/none abilities for ligatures, but of course the
glyphs can be in a TrueType font.
Perhaps I've misunderstood the implications; hope so!
Barry Smith, Blue Sky Research