ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Taco Hoekwater <taco@elvenkind.com>
Subject: Re: FAQ: fonts
Date: Mon, 25 Feb 2002 14:05:15 +0100	[thread overview]
Message-ID: <20020225140515.4511882f.taco@elvenkind.com> (raw)
In-Reply-To: <200202242231.g1OMVT201729@nathir.fiee.lan>

On Sun, 24 Feb 2002 23:31:29 +0100
"Henning Hraban Ramm" <angerweit@gmx.net> wrote:

> There are some typescripts for usual fonts in your ConTeXt distribution. But 
> they seldom seem to work. It's better to make your own new metrics and 
> typescripts.

I don't want to diminish the work you've done on this FAQ, but I find that 
the documentation for fonts (and in fact the whole subsystem) is getting 
awfully confusing. 

This is caused by a number of factors:

- mtexfont.pdf and mfonts.pdf overlap eachother in areas where they shouldn't
- mfonts.pdf explains *too much* (e.g. the section on \definefont, and the
  stuff about the traditional system with \definebodyfont)
- the FAQ is too terse and doesn't mention the nasty pitfalls (like the fact
  that you *cannot* redefine a typescript collection)
- There are too many 'example' files in the distribution that fairly unusable
  in the real world (like type-buy.tex)
- the whole font subsystem is still backward compatible so all of the old
  commands still function more ore less as they used to
- \starttypescript is an awful command. It does a lot of stuff depending
  on 'special options', and the documentation for these options is incomplete
- The same is true for \definetypeface.

In order to create some sort of logic:

There should be aliases defined for at least the following commands, and the
documentation should stick to using these names instead of the basic command.

This will make the documentation and usage much clearer without introducing 
extra overhead in the ConTeXt core.

\definefontsynonym
------------------
Is used for two different things: 
- Mapping generic names to font family names, as in
	\definefontsynonym [Serif] [TimesRoman]
- Mapping font family names to disk file names, as in
	\definefontsynonym [TimesRoman] [tir] [encoding=texnansi]

The second usage needs an alias (I propose \definefontfile), so that the above
can be written as:

	\definefontsynonym [Serif] [TimesRoman]
	\definefontfile    [TimesRoman] [tir] [encoding=texnansi]

\starttypescript
----------------
Is used for *a lot* of different things. 

\starttypescript [map]
*********************

First, here is one call I do not fully  understand:

	\starttypescript[map][texnansi]
		 \loadmapfile [texnansi-urw-times.map]
	\stoptypescript

Assuming I get it right, this is what should happen: 

- Context internally has defined a very very special typescript called map.
- This is not 'really' a typescript, but behaves more like a list. A list of
  pdftex map files, in fact.
- Whenever anybody calls *any* typescript, this special typescript is automatically
  activated as well. 
- the net result of that is that all of the map files (in the correct encoding) 
  are loaded by pdftex at every typescript change.

If I get this right, the whole thing is an attempt to make pdftex read map 
files dynamically at runtime instead of statically preloading all of the
map files as soon as the executable starts.

Sadly, this won't work correctly until pdftex is patched to accept map files during
a run (in the current situation, pdftex only allows dynamic loading of map files
before the first page is shipped out, not afterwards).

Anyway, this is *ugly* when used in a call to \starttypescript. It would be much
nicer to have a new command:

	\definetypescriptencodingmapfile [texnansi] [texnansi-urw-times.map]

(or even \defineencodingmapfile, since there is no real relation to any 
specific typescript name, only to the encoding)

\starttypescript [*] [*] [size]
*******************************

Why not call this \starttypescriptsizes ?

\starttypescript [*] [*] [name]
*******************************

Why not call this \starttypescriptnames ?

\starttypescript (in general)
****************

The exact usage of the options to this command is incredibly
confusing. If I understand it all correctly, then what is generally
used as the *first* argument in the documentation (serif|sans|mono|math) 
is more optional than the second (the typescript name | default). At the
same time, I get the impression from the documentation that the order
is not important at all (mfonts.pdf page 8). This is clearly not true.

\usetypescript
**************

I think it is a little odd that documents now start with:

	\usetypescriptfile[type-mytimes]
	\usetypescript[mytimes]

Hans, do you think it is possible to add the file loading/checking
code to \usetypescript?

If I understand this correctly, then \usetypescript basically has the
same arguments as \starttypescript. It follows that if you use this command
in a typescript definition file, it only functions as a shortcut to get
to (parts of) another typescript. Hans, is this correct?

\definetypeface
***************

At one point in time I understood what this command does. But not any
longer. For one, I don't understand how it is possible that it appears
*inside* a typescript definition. I thought it was a way to map a number
of definebodyfonts into a single command. But then again, this is also what
typescripts do. So how can one be part of the other?

-- 
groeten,

Taco


  reply	other threads:[~2002-02-25 13:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-24 22:31 Henning Hraban Ramm
2002-02-25 13:05 ` Taco Hoekwater [this message]
2002-02-25 16:24   ` Hans Hagen
2002-02-25 18:05     ` Frans Goddijn
2002-02-25 21:30       ` Henning Hraban Ramm
     [not found]         ` <005801c1be69$5c3b05a0$6401a8c0@lap>
2002-02-26 20:52           ` Henning Hraban Ramm
2002-02-27 21:57             ` Frans Goddijn
2002-02-26 10:53     ` Taco Hoekwater
     [not found] ` <200202252123.g1PLNju01677@nathir.fiee.lan>
2002-02-26 11:19   ` 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=20020225140515.4511882f.taco@elvenkind.com \
    --to=taco@elvenkind.com \
    /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).