From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.tex.context/54254 Path: news.gmane.org!not-for-mail From: Hans Hagen Newsgroups: gmane.comp.tex.context Subject: Re: Math setup with Times (Termes) Date: Thu, 12 Nov 2009 10:42:51 +0100 Message-ID: <4AFBD89B.2080609@wxs.nl> References: <6faad9f00911101010p13c88d9dv2022727b0ec7bd9@mail.gmail.com> <6faad9f00911101212p6de2bf02l17875665bcb915b1@mail.gmail.com> <4AFA77FA.8000307@wxs.nl> <6faad9f00911110701of349ea6r66f5aacaac07b253@mail.gmail.com> <6faad9f00911110736w7b66f493n9ef514bfe05019dc@mail.gmail.com> <4AFADE42.9010209@wxs.nl> <6faad9f00911110802q469294bao69cf5354d1ba2bb7@mail.gmail.com> <6faad9f00911110837p269804b6p4fa41ef714d129dd@mail.gmail.com> Reply-To: mailing list for ConTeXt users NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1258019000 21800 80.91.229.12 (12 Nov 2009 09:43:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 12 Nov 2009 09:43:20 +0000 (UTC) To: mailing list for ConTeXt users Original-X-From: ntg-context-bounces@ntg.nl Thu Nov 12 10:43:10 2009 Return-path: Envelope-to: gctc-ntg-context-518@m.gmane.org Original-Received: from balder.ntg.nl ([195.12.62.10]) by lo.gmane.org with esmtp (Exim 4.50) id 1N8WCr-0004qV-SM for gctc-ntg-context-518@m.gmane.org; Thu, 12 Nov 2009 10:43:09 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by balder.ntg.nl (Postfix) with ESMTP id 96789C9AF1; Thu, 12 Nov 2009 10:41:05 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at balder.ntg.nl Original-Received: from balder.ntg.nl ([127.0.0.1]) by localhost (balder.ntg.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id oNSL0bGiLVWH; Thu, 12 Nov 2009 10:41:01 +0100 (CET) Original-Received: from balder.ntg.nl (localhost [127.0.0.1]) by balder.ntg.nl (Postfix) with ESMTP id A5D35C9AAA; Thu, 12 Nov 2009 10:41:01 +0100 (CET) Original-Received: from localhost (localhost [127.0.0.1]) by balder.ntg.nl (Postfix) with ESMTP id CA230C9AAA for ; Thu, 12 Nov 2009 10:40:59 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at balder.ntg.nl Original-Received: from balder.ntg.nl ([127.0.0.1]) by localhost (balder.ntg.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nnAnxgPerIrX for ; Thu, 12 Nov 2009 10:40:47 +0100 (CET) Original-Received: from mail.solcon.net (dsl-083-247-100-017.solcon.nl [83.247.100.17]) by balder.ntg.nl (Postfix) with ESMTP id C30A4C9A7C for ; Thu, 12 Nov 2009 10:40:47 +0100 (CET) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=10.100.1.100; Original-Received: from [10.100.1.100] (unverified [10.100.1.100]) by controller-9 (SurgeMail 4.2a3) with ESMTP id 2747-1713362 for ; Thu, 12 Nov 2009 10:42:26 +0100 User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) In-Reply-To: <6faad9f00911110837p269804b6p4fa41ef714d129dd@mail.gmail.com> X-Authenticated-User: hagen@controller-9 X-BeenThere: ntg-context@ntg.nl X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list for ConTeXt users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: ntg-context-bounces@ntg.nl Errors-To: ntg-context-bounces@ntg.nl Xref: news.gmane.org gmane.comp.tex.context:54254 Archived-At: Mojca Miklavec wrote: > What are we talking about? Do you mean the old virtual fonts (.vf > files) or mkiv's virtual fonts or something completely different? What You Don't Want To Know: a virtual font is just a regular font but has references to other fonts instead, like char 1 -> font x, char 10 (or dvi commands instead) and then it can has kerning etc within its own set tex itself only sees characters as things with dimensions and a few properties and when typesetting the paragraph uses info from the font with respect to kerning and ligature building now, traditional tex has only tfm files and when virtual fonts were introduced the engine was not adapted at all; so, a virtual font still has a tfm file (with characters etc) however, when the font is being used in the backend, an extra lookup takes place and when a vf file is found, information from that file is used for embedding (in pdftex); of course dvi postprocessors also look at that file so we have: tfm -> tfm used by frontend and backend tfm + vf -> tfm used by frontend, vf used by backend on top of that a map file will point from fontname to real name (pfb) and this is why in a map file you don't see the virtual font names at all, as it's the names inside the vf that matter so say that we have: a.tfm + a.vf but internally a.vf -> font b, c, d (or further chained) then b, c, d need to be resolved to real names as there is no checking going on and as the tfm file has no info about itself being virtual you can imagine that interesting side effects can take place when an old (unknown of) vf lays around ... it will kick in at backend time (this is why the texfont script does a clean up) in luatex we have integrated these mechanisms, so internally a font can have virtual properties (a few more than original tex) however, by default luatex acts like tex, so users won't notice; as luatex has the backend integrated, at some point it will need the vf and mkiv will happily fulfill that request but ... and this is the catch ... in mkiv we use (1) opentype, (2) type 1 and (3) traditional tex fonts (1) is not related to virtual fonts but we can (and do) extend fonts internally using virtual technology (2) in pdftex tfm/vf files are used but mkiv does not look at those files but uses afm files directly (right from the start) (3) the only place in mkiv where tex metric files are still used is in math as we need the additional (math specific) info as it makes no sense to keep supporting the old math fonts while open type variant sare under way, i decided to stick to unicode math and as a result we need to use virtual font technology to make that unicode variant for the lm fonts, this is mostly done and as they have no virtual (vf based) fonts it's transparent for tx/px however, as they use virtual fonts, it gets hairy what file to load; technically there is no obstacle but i've chosen to stay away from the tfm/vf mess and use just the natural tfm variants (i.e. the ones that match the pfb) and therefore we might need a few extra vectors (and maybe font files) in math-vfu that map to the right slots; using the vf's as well would complicate matters and it's not worth the trouble so, what we need to do is to figure out teh few missing files/vectors, add them, and then let users fill in the gaps in vectors are you still there? Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 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 ___________________________________________________________________________________