From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.tex.context/59944 Path: news.gmane.org!not-for-mail From: "Paul Schalck" Newsgroups: gmane.comp.tex.context Subject: Re: Palatino Linotype under MKIV Date: Wed, 30 Jun 2010 18:16:07 +0200 Message-ID: <5734E8EB57AE4981B38CA2AC8CF5D29A@netbook> References: <4C2AF357.1040306@elvenkind.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: dough.gmane.org 1277914582 20399 80.91.229.12 (30 Jun 2010 16:16:22 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 30 Jun 2010 16:16:22 +0000 (UTC) Cc: Taco Hoekwater To: Original-X-From: ntg-context-bounces@ntg.nl Wed Jun 30 18:16:20 2010 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.69) (envelope-from ) id 1OTzxR-0008Ay-81 for gctc-ntg-context-518@m.gmane.org; Wed, 30 Jun 2010 18:16:17 +0200 Original-Received: from localhost (localhost [127.0.0.1]) by balder.ntg.nl (Postfix) with ESMTP id 9B474C9AF1; Wed, 30 Jun 2010 18:16:16 +0200 (CEST) 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 QbR-K1oJur7B; Wed, 30 Jun 2010 18:16:14 +0200 (CEST) Original-Received: from balder.ntg.nl (localhost [127.0.0.1]) by balder.ntg.nl (Postfix) with ESMTP id E0087C9AC7; Wed, 30 Jun 2010 18:16:13 +0200 (CEST) Original-Received: from localhost (localhost [127.0.0.1]) by balder.ntg.nl (Postfix) with ESMTP id 37151C9AC7 for ; Wed, 30 Jun 2010 18:16:13 +0200 (CEST) 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 Ej4N2qNJjkLp for ; Wed, 30 Jun 2010 18:16:10 +0200 (CEST) Original-Received: from fmmailgate01.web.de (fmmailgate01.web.de [217.72.192.221]) by balder.ntg.nl (Postfix) with ESMTP id 84EE9C9A8A for ; Wed, 30 Jun 2010 18:16:10 +0200 (CEST) Original-Received: from smtp07.web.de ( [172.20.5.215]) by fmmailgate01.web.de (Postfix) with ESMTP id 2031D16237BD9; Wed, 30 Jun 2010 18:16:10 +0200 (CEST) Original-Received: from [77.250.10.79] (helo=netbook) by smtp07.web.de with asmtp (WEB.DE 4.110 #4) id 1OTzxK-0005VA-00; Wed, 30 Jun 2010 18:16:10 +0200 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Sender: schickele@web.de X-Provags-ID: V01U2FsdGVkX1+TYil3VljE6AMYG61AHzUIcaU+iyKzxANXzK5J wx8l38d1TnnSSE2LGvki0pRJh2xJcf0MZ3l83eRRAPiWcjqF/r TEOlhVsDg= 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:59944 Archived-At: Thank you very much, Taco, especially for the detailed explanations you gave! It works like a charm. I've made a new Wiki page (my first one), mainly based on your answer: http://wiki.contextgarden.net/Palatino_Linotype_under_MKIV ----- Original Message ----- From: "Taco Hoekwater" To: "mailing list for ConTeXt users" Cc: "Paul Schalck" Sent: Wednesday, June 30, 2010 9:33 AM Subject: Re: [NTG-context] Palatino Linotype under MKIV > > Hi, > > On 06/29/2010 11:15 AM, Paul Schalck wrote: >> Hi, >> >> I'm trying to use the full glyph range of the Palatino Linotype font >> shipped with XP (version 1.40; significantly different from the Windows >> 7 one) under MKIV. Everything works fine (oldstyle figures, sups for >> instance), except that the small cap "i" character has a dot whereas it >> shouldn't. > > I borrowed one of the fonts from my wife's XP install (pala.ttf). > > The short answer: the font is borked, complain to Microsoft. > > The long answer: lookups are name-based, and if there are two glyphs > with the same name, you can't know which one is used in any particular > piece of software. > >> As far as I can see, it has to do with the messy name list of the >> glyphs. Both the normal small cap i and the small cap dotted i are named >> "i.sc" > > The one with a dot is meant for Turkish. > >> Moreover, the small cap glyphs have no unicode numbers in this font, so >> I cannot pick them manually with \char"XXXX or even with \charXXXXX. >> >> Any ideas how I can get the right dottless i? > > Context always maps all unencoded glyphs into a private area starting > at 0xF0000. For this font, the first i.sc (the one without dot) is at > 0xF00AF and has glyph index 0x456, and the second is at 0xF00EB > with glyph index 0x492. > > To find these numbers, run a file like this: > > \usemodule[fnt-10] > \starttext > \ShowCompleteFont{file:pala.ttf}{20pt}{1} > \stoptext > > This means that to get the dotless version, you could enter \char"F00AF > > Really long answer: to fix the problem nicely, we have to rename one of > the two glyphs. > > This could be done in an external editor, but as this is a system font, > that may not be wise or even possible. Luckily, context allows to do > this using a patching system that is active during initial font loading > time (when the cache is generated). > > In the following, we will be patching the generated cache file before > it is saved (by putting some lua code at the beginning of your test > file). Remember that you have to delete the generated cache > files after each iteration. In my case, they were /opt/tex/texmf- > cache/luatex-cache/context/c24894930eb65eadf7b71f1e305ff518/fonts/otf/pala.tm*. > If you forget to do this step in between runs, > nothing will change in the output! > > The existing font patches are in font-pat.lua, and from that file it is > possible to deduce that something like this is the correct program > structure, theoretically: > > \startluacode > function palapatch (data,filename) > -- to be filled in > end > fonts.otf.enhancers.patches["^pala"] = palapatch > \stopluacode > > The two arguments to the patch function are the data table from the > luafontloader and the font file name, respectively. The function > should patch the data table to our liking and does not have to return > anything. > > In order to have a good look at the data, the first thing to do is to > dump the data to a file. Put this code at the top of your test file, > delete the data cache files, and run: > > \startluacode > function palapatch (data,filename) > io.savedata(filename .. '.lua', table.serialize(data)) > end > > fonts.otf.enhancers.patches["^pala"] = palapatch > \stopluacode > > \definefontfeature [...] > > Afterwards, open pala.ttf.lua (or pala.TTF.lua. not sure how this works > out on an actual XP install) in an editor for browsing. > > Looking at the lua code in pala.ttf.lua, you will see that there > is a pretty large sub-array called 'glyphs', which happens to be > indexed by glyph id. There are two entries in that sub-array called > 'i.sc' and we will want to change the second of those to 'i.scturkish' > (the one at 0x492, the number we discovered above). > > Change the lua code to the code below, save your test file, delete the > data cache again, and rerun. > > \startluacode > function palapatch (data,filename) > data.glyphs[0x492].name = "a.scturkish" > end > > fonts.otf.enhancers.patches["^pala"] = palapatch > \stopluacode > > That's one problem fixed. If you look at the test's pdf, it will now > have dotless i's in the smallcaps. But now we have broken the > turkish smallcaps code (it will now also use the first i.sc, which is > wrong) so it is nice to fix that as well. Some searching back and forth > through the pala.ttf.lua code reveals that there are two lookups that > use i.sc: ss_latn_l_13_s (for normal latin) and ss_latn_l_14_s (for > turkish). These lookups are part of the glyph definition of 'i' which > lives at 0x92 (I found that number in the earlier font dump, but you > could also count the entries in pala.ttf.lua, if you are bored or like > counting stuff). > > Named lookups are small arrays (you can deduce that from the double > braces in pala.ttf.lua), so the needed patch is: > > > data.glyphs[0x92].lookups["ss_latn_l_14_s"][1].specification.variant="a.scturkish" > > And that will fix the turkish lookup. Now, I want to make sure we > only run this code for palatino version 1.40 (it should be obvious > why), and it is nice to do a terminal message as well. (note: testing > for just the font version ignores the fact that different vendors may > use the same font name for different fonts, but that is a complication > that I think can be ignored in this particular case). > > The end result is: > > \startluacode > function palapatch (data,filename) > if data.version == "1.40" then > logs.report("load otf", "patching smallcaps i") > > data.glyphs[0x92].lookups["ss_latn_l_14_s"][1].specification.variant="a.scturkish" > data.glyphs[0x492].name = "a.scturkish" > end > end > > fonts.otf.enhancers.patches["^palatino"] = palapatch > \stopluacode > > Updated test file attached. I hope this makes sense to someone who is > willing to wikify the process. > > Best wishes, > Taco > > > > > ___________________________________________________________________________________ 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 ___________________________________________________________________________________