ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Hans Hagen <pragma@wxs.nl>
To: news3@nililand.de, mailing list for ConTeXt users <ntg-context@ntg.nl>
Subject: Re: Using virtual  fonts defined with lua-code
Date: Thu, 10 Feb 2011 11:26:22 +0100	[thread overview]
Message-ID: <4D53BD4E.1010701@wxs.nl> (raw)
In-Reply-To: <19n2tk3ywckl2.dlg@nililand.de>

On 10-2-2011 11:03, Ulrike Fischer wrote:

> Where is this interface? Does some documentation exists about how it
> works and how it can be used?

Some of it has been reported in articles (and mk.pdf) and I will 
document it in more detail when I've cleaned it up and feel satisfied 
about it. Also, it's context speficic (I guess) and it is not on my 
agenda to make every context feature portable (the concepts between 
context and plain/latex/.. simply differ too much).

> Well it is certainly easier if there are less encodings. But the
> small encodings had one advantage: if you used a e.g. T1-encoded
> font you not only knew which characters are encoded and their
> position but also that the characters are actually present. You

that's not 100% true ... in the past I've ran into situations where 
fonts missed glyphs; also, having a bad replacement glyph is also no 
option (funny ogoneks are an example)

> could safely switch from one font to another. With unicode fonts
> this is no longer the case. If you switch fonts there is always the
> danger that a char or an accent suddenly disappears.

One always need to check each font and the problem with e.g. otf is not 
so much the coverage but more the fact that things like features are 
somewhat unpredictable (defaults, correct implemenation, etc) and 
successive versions can differ. So, patching them then also boils down 
to keeping track of all kind of changes in releases. Nu fun.

Anyway, in context mkiv there are several extension mechanisms (aka font 
goodies) and some of them also depend on support in the core (context) 
machinery. I expect more of them and virtual trickery fits into that 
picture. What ends up there is also user driven.

> The lm and gyre fonts are fine. But they cover only a small part of
> the glyphs used in the world. Many of the discussions I see are
> started by people trying to use non-western/non-latin scripts.

Sure. Anyhow, I'm not going to spend time following discussions on the 
pdftex and xetex list as I don't use these engines and context support 
for them is frozen. If context users have demands in this area I'm quite 
willing to fulfill them in mkiv using appropriate mechanisms and 
interfaces. Support for advanced arabic (using additional features and 
dedicated optimizers) is an example.

> Fixing a font needs either the rights to do it oneself or the will
> of the author(s) to do it. Both is often not the case. And fixing a
> font may remove a dependency to a virtual font but it will add a
> dependency to the fixed font version - which can get quite difficult
> if more than one "fixed" version exists.

True, but as I mentioned, there are many fonts out there and one can try 
to avoid the crappy ones.

(btw, context mkiv has some features for adding missing glyphs, which 
might be why users don't complain too much here)

Hans

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
                                              | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________


      reply	other threads:[~2011-02-10 10:26 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-08  9:40 Ulrike Fischer
2011-02-08 14:13 ` Hans Hagen
2011-02-08 14:41   ` Ulrike Fischer
2011-02-08 16:17     ` Hans Hagen
2011-02-08 14:46   ` Khaled Hosny
2011-02-08 16:07     ` Hans Hagen
2011-02-09  9:55       ` Ulrike Fischer
2011-02-09 13:52         ` Hans Hagen
2011-02-09 11:23       ` Ulrike Fischer
2011-02-09 13:30         ` Hans Hagen
2011-02-09 16:09           ` Ulrike Fischer
2011-02-09 16:36             ` Hans Hagen
2011-02-10 10:03               ` Ulrike Fischer
2011-02-10 10:26                 ` Hans Hagen [this message]

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=4D53BD4E.1010701@wxs.nl \
    --to=pragma@wxs.nl \
    --cc=news3@nililand.de \
    --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).