From: Hans Hagen <pragma@wxs.nl>
Cc: ntg-context@ntg.nl
Subject: Re: FAQ: fonts
Date: Mon, 25 Feb 2002 17:24:36 +0100 [thread overview]
Message-ID: <5.1.0.14.1.20020225165613.02b28720@server-1> (raw)
In-Reply-To: <20020225140515.4511882f.taco@elvenkind.com>
At 02:05 PM 2/25/2002 +0100, Taco Hoekwater wrote:
>- mtexfont.pdf and mfonts.pdf overlap eachother in areas where they shouldn't
right, i will change this as soon as texfont.pl is finished
>- mfonts.pdf explains *too much* (e.g. the section on \definefont, and the
> stuff about the traditional system with \definebodyfont)
once the typescripts are working as expected, that part will go to an appendix
>- the FAQ is too terse and doesn't mention the nasty pitfalls (like the fact
> that you *cannot* redefine a typescript collection)
btw, you can overload one by a later accessed typescript
>- There are too many 'example' files in the distribution that fairly unusable
> in the real world (like type-buy.tex)
they come from my personal real world -)
>- 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
actually, it's just a filtering command:
\starttypescript [list a] [list b] [list c]
\usetypescript [list a] [list b] [list c]
the use command tries to match them and 'executes' everything in the
matched script (i have plans to use this feature for other things as well).
the keyword 'all' can be used to match anything
>- The same is true for \definetypeface.
apart from some font/command initializations this command just executes a
series of typescripts (as you mention later); the ideas is that one can do
things like:
\definetypeface [abra] [rm] [serif] ....
\definetypeface [cadabra] [rm] [serif] ....
and so create multiple (quite complete) bodyfont rm/ss/tt/.. definitions;
since each typeface (collection of rm,ss,tt defs) has its own namespace,
one can, in one document, for instance mix different collections, each with
different encodings and relative scaling etc.
>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]
i have no problem with providing you \definefontfile (just a \let) but keep
in mind that the third arg (encoding, mapping, handling, etc) can come at
any level in the font (file)name expansion chain.
>\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.
no, this typescript is as the others, so:
\usetypescript[map][texnansi]
will execute all typescripts marked as such, while
\usetypescript[map][all]
will load all typescripts that have a first [map] spec. The \loadmapfile
will add the names mentioned to an internal list; keep in min dthat this
loading of map files is still suboptimal (i have to discuss this with thanh).
>- This is not 'really' a typescript, but behaves more like a list. A list of
> pdftex map files, in fact.
the \loadmapfile indeed adds to a list; actually anything can happen in a
typescript, so
\starttypescript[taco]
\def\Taco{Taco Hoekwater}
\stoptypescript
is pretty valid.
>- Whenever anybody calls *any* typescript, this special typescript is
>automatically
> activated as well.
no, only when asked for; it happens that it is asked for frequently
>- the net result of that is that all of the map files (in the correct
>encoding)
> are loaded by pdftex at every typescript change.
right,
\starttypescript [map] [palatino] [texnansi]
or so would provide more granularity [the problem currently si that one
needs to load map files at the first page (after that pdftex ignores
\pdfmapfile; this may change (i hope))
>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.
right, this is needed because otherwise one cannot overload entries;
unfortunately in tex distributions everything goes into this big
psfonts,map file (with all side effects, like problems with embedded pdf
files).
>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).
right again -)
>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 ?
once i got the feeling that typescripts are stable i will look into that,
probably something \starttypefacesize is more accurate
>\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.
this is only true for the ones called for by \definettypeface, but as said,
one can use typescripts for more purposes
\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?
hm, it could be done, but would slow down things (much more file opening
and so). What i do here, is put every local thing in a file called
typeface.tex and load that one always
>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?
right
>\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?
think of the one defining the typeface as being the top (root) of a tree;
it will not load itself
[i agree that typescripts are a bit fuzzy and i hope that some day i will
have them reworked in some way (for instance as you propose with more
dedicated commands), but given the diversity of fonts, i wanted a mechanism
that i could experiment with; for instance, i will probably clean up some
encoding filtering (otherwise the third args will grow too long).]
[sorry for being confusing]
Hans
-------------------------------------------------------------------------
Hans Hagen | PRAGMA ADE | pragma@wxs.nl
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
-------------------------------------------------------------------------
fall-back web server:
www.pragma-pod.nl
-------------------------------------------------------------------------
next prev parent reply other threads:[~2002-02-25 16:24 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
2002-02-25 16:24 ` Hans Hagen [this message]
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=5.1.0.14.1.20020225165613.02b28720@server-1 \
--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).