On Wed, Jun 30, 2010 at 9:33 AM, Taco Hoekwater <t...@elvenkind.com> wrote:
>
> 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.
Well, at least a good starting point for an article for MAPS.
Maybe this can solve the problem of font with zero-widths-glyphs that makes
invalid pdf/A files
--
luigi
___________________________________________________________________________________
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
___________________________________________________________________________________
