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: Wed, 09 Feb 2011 17:36:41 +0100	[thread overview]
Message-ID: <4D52C299.2020304@wxs.nl> (raw)
In-Reply-To: <7fm3plooxbvi$.dlg@nililand.de>

On 9-2-2011 5:09, Ulrike Fischer wrote:

> While I certainly in the end want to use the (virtual) fonts also
> with LaTeX I don't want to define them in a LaTeX-specific way. A
> standard virtual font (tfm + vf) can be used with latex, plain and
> context with an identical syntax so why should this be different for
> this new type of virtual font only because they are based on
> lua-code?

The you can put them under tex/fonts/generic i suppose; but even then, 
there is no reason to assume that context or latex provides additional 
lua code in the engine that is used in such a font.

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

> (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. Also, in the past I've found 
out that one cannot rely to much on provided metrics (also because latex 
assume special values, as is the case in some tfm metrics) and this is 
why in mkii (pdftex variant) we always generated metrics a directly from 
afm files.

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

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.

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-09 16:36 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 [this message]
2011-02-10 10:03               ` Ulrike Fischer
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=4D52C299.2020304@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).