ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Hans Hagen <pragma@wxs.nl>
Cc: Context <ntg-context@ntg.nl>
Subject: Re: Fonts & "esotic" languages
Date: Thu, 14 Sep 2000 10:40:34 +0200	[thread overview]
Message-ID: <3.0.6.32.20000914104034.0165d7f0@pop.wxs.nl> (raw)
In-Reply-To: <39C08870.D2895934@econ.muni.cz>

At 10:12 AM 9/14/00 +0200, Michal Kvasnicka wrote:
>Dear friends at Pragma,
>
>the previous mail remind me one (maybe important) thing
>I wanted to to ask you. Is there some possibility to have different
>font-***.tex for different encodings?
>
>It is a really important things for people in the Central Europe.
>For example, to be able to typeset with Palatino, I must use different
>.pfb files (or at least different .afm, and this way different .tfm + .vf
too)
>than those people using only ISO Latin 1 characters.
>
>In LaTeX, it is solve with different .fd files. There is one .fd file for
every
>
>family and every encoding. How is it solved in the ConTeXt?
>
>(Now I'm preparing font-***.tex file for every TeX job uniquely,
>but in some time it would be better for me to solve it properly. How?)

Since at pragma we use texnansi encoding while most tex users use ec, you
can imagine that this problem already solved -) 

If you look into the font files you will see that we use definitions like: 

bf = RegularBold sa 1

which means 'take the current regular font (roman, serif) in its bold
incarnation. When this font is asked for, 'RegularBold' is resolved. In
palatino, this means that 'RegularBold' becomes 'Palatino-Bold'. Now,
that's still no font file. Mapping on the filename takes place in the last
stage, and there the encoding is chosen too. That happens for instance in
font-ber.tex. So, what you should do is to make a local file [here we use
font-loc.tex] to map the names to filenames and encodings. 

So, what you can do is to make a file font-eec.tex [for easter european
countries] that lists all the fonts + names + encodings used in your
region.  There is no reason to change any font-... file, just the filename
should change. This also means that definitions like  

\definefont [VeryBig] [RegularBold at 48pt] 

will use that file and encoding [and mapping if specified]

This brings up another problem. When users are making their own font-*
files, at a certain moment we will run into naming problems. So, basically
the font-* files should be reserved for 'official' files. I'm thinking of a
way to load 'user' files. It's like the modules: s-* and m-* files are
extensions to context, users should define their files in environments! 

\environment yourfile.tex 

This fits more nicely in the project support present in context. I will
come back to that later. 

Hans 

-------------------------------------------------------------------------
                                                  Hans Hagen | PRAGMA ADE
                      Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
 tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------


  reply	other threads:[~2000-09-14  8:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-13 20:31 Giuseppe Bilotta (Oblomov)
2000-09-14  8:12 ` Michal Kvasnicka
2000-09-14  8:40   ` Hans Hagen [this message]
2000-09-14  9:52 ` Hans Hagen

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=3.0.6.32.20000914104034.0165d7f0@pop.wxs.nl \
    --to=pragma@wxs.nl \
    --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).