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

Am Wed, 09 Feb 2011 17:36:41 +0100 schrieb Hans Hagen:

 
>> Also if a font is defective (e.g. wrong kerning, missing glyphs,
>> faulty glyph names, missing open type features ...) a virtual font
>> which improves this font should be useful for all formats which can
>> use it, so I don't think that a format specific location is
>> sensible.

> We have a different machinery for things like that and support is 
> integrated into context (and targets at context). Also, there is an 
> experimental vf creation interface that will be extended.

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


 
>> (I must say I'm wondering a bit why problems with fonts are so
>> seldom discussed in the context list. In the last weeks I have seen
>> in the xetex list a discussion how to add missing glyphs to a font,
>> a discussion about kerning flaws, discussions about bad accent
>> placement, in another group someone missed the "m with dot" in a
>> font, in the luatex.user list you can find a message about a problem
>> with fea-files and kerning, and so one ... Why do context user seems
>> to have no problems with defective fonts? Do they use a smaller set
>> of fonts?)
> 
> I don't know. Personally I just reject a font if it's flawed esp because 
> there are enough fonts out there that are ok. And I definitely (as 
> context user) don't want to go along the route of using all kind of 
> patches to fonts, because we then end up with the same mess as we have 
> with special encodings in traditional tex. 

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
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. 




> The lm and gyre font projects are in fact triggered by people within the 
> context community as a solution to all these incomplete fonts that have 
> been used for ages. Fortunately these projects soon became generic and 
> were adopted and supported by latex as well. (In context we switched 
> immediately to them.)


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. 


> I'm glad that we got rid of the font mess and would like to keep it that 
> way. If a font is bugged ... preferably fix the font. (We currently 
> impose a few runtime fixes to e.g. cambria but I'd expect that to be a 
> temporary thing.) Don't get me wrong, context users can do a lot of 
> tweaking if they want, which can be seen from questions on the list with 
> respect to layout, but maybe they don't want to create a dependency on 
> tweaks in fonts.

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.  


-- 
Ulrike Fischer 

___________________________________________________________________________________
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:03 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 [this message]
2011-02-10 10:26                 ` 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=19n2tk3ywckl2.dlg@nililand.de \
    --to=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).