ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: "Mojca Miklavec" <mojca.miklavec.lists@gmail.com>
Subject: Re: ec encoding and tcaron
Date: Sat, 10 Jun 2006 00:08:51 +0200	[thread overview]
Message-ID: <6faad9f00606091508j786a5ba6gc34a8f5d0a2d825c@mail.gmail.com> (raw)
In-Reply-To: <44895044.5060108@econ.muni.cz>

On 6/9/06, Michal Kvasnicka wrote:
> Hi Richard.
> > I'm sure the EC encoding contains the 'tcaron' character (see the
> > lm-ec.enc file for example).
> > I have ConTeXt on top of TeXLive 2005.
> > I can find:
> > texmf/fonts/enc/dvips/base/ec.enc
> > texmf/fonts/enc/dvips/lm/ec-lm.enc
> > texmf/fonts/enc/dvips/lm/lm-ec.enc
> >
> > I use EC normally for typesetting Czech documents. So I would suggest
> > to use EC ;-)
> I'm sorry you're not right. The lm-ec.enc really includes tcaron, but
> neither ec.enc nor EC.enc does, at least at my teTeX 3.0. If you use
> only LatinModern, it works, because lm-ec.enc is used. But I doubt it
> works well for other fonts. Does it? I was unsuccessful. Can you send me
> your ec.enc file please?

Approximately a year ago there was a discussion on tex-fonts mailing
list about fixing ec.enc (for example there's a glyph called "dbar",
which is agains any standards: in Unicode it's called "d with stroke"
and according to Adobe standards it should be called "dcroat"; and
many more inconsistencies).

The result of the discussion was something like: "No, we may not
change this since it may break functionality of some fonts which used
that standard years ago. Googling for this and that reveales that some
fonts still use those old glyph names ..." (perhaps Google found 4
hits or so ...) The explanation/excuse was that everyone using modern
glyph names should create his own "ec.enc" (just as it was done for
Latin Modern).

I would recommend you to use lm-ec.enc or tex256.ec ("fixed" version
of ec.enc which should be present in the same folder as ec.enc). The
Polish guys did their best to follow the standards, so the ec file of
Latin Modern should be OK for most fonts. If some glyph is still
missing, you can manually change the encoding definition (and then
note that specific encoding in map file as well, in the same was as
it's done for LM).

You can test the resulting font with
    \showfont[yourfontname] % where yourfountname should preferrably
be ec-something
In that way you'll spot any missing glyphs pretty easily.

About xl2.enc: it is incomplete and neiter supported by ConTeXt (it
could be, but there's no real benefit) nor by most popular fonts (you
have to create metrics and everything by yourself, so your files might
be highly unportable). I dropped the idea about using it pretty soon.
It's not impossible to use it, but probably not worth it.

Mojca

  parent reply	other threads:[~2006-06-09 22:08 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-09 10:33 Richard Gabriel
2006-06-09 10:41 ` Michal Kvasnicka
2006-06-09 14:23   ` Vit Zyka
2006-06-09 22:08   ` Mojca Miklavec [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-06-09 10:11 Michal Kvasnicka
2005-08-13 16:44 Vit Zyka
2005-08-13 20:35 ` Hans Hagen
2005-08-14  9:02   ` Vit Zyka
2005-08-13 21:31 ` Hans Hagen
2005-08-14  9:48   ` Vit Zyka
2005-08-14 10:12     ` Mojca Miklavec
2005-08-14 14:59       ` Vit Zyka
2005-08-14 15:12         ` Taco Hoekwater
2005-08-14 16:18           ` Mojca Miklavec
2005-08-14 17:19             ` Hans Hagen
2005-08-15 10:51             ` Hans Hagen
2005-08-14 19:12     ` Hans Hagen
2005-08-14 21:58       ` Vit Zyka
2005-08-14 23:07         ` Hans Hagen
2005-08-15  9:39           ` Vit Zyka
2005-08-15 11:09             ` Hans Hagen
2005-08-15 12:17 ` Patrick Gundlach
2005-08-15 21:10   ` Vit Zyka
2005-08-15 21:21     ` Patrick Gundlach
2005-08-16  8:51       ` Vit Zyka
2005-08-16  8:57         ` Patrick Gundlach

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=6faad9f00606091508j786a5ba6gc34a8f5d0a2d825c@mail.gmail.com \
    --to=mojca.miklavec.lists@gmail.com \
    --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).