- ntg-context - NTG Mailing Lists

Re: [NTG-context] [***SPAM***] Incorrect internal font processing
by Jan Tosovsky 27 Nov '13

27 Nov '13

On 2013-11-27 Jan Tosovsky wrote: > On 2013-11-27 Hans Hagen wrote: > > On 11/27/2013 10:20 PM, Jan Tosovsky wrote: > > > On 2013-11-27 Hans Hagen wrote: > > >> On 11/27/2013 9:53 PM, Jan Tosovsky wrote: > > >>> On 2013-11-27 Hans Hagen wrote: > > >>>> On 11/27/2013 8:44 PM, Jan Tosovsky wrote: > > >>>>> > > >>>>> during my attempts to patch the Palatino's dotless 'i' I found > > >>>>> that this font is parsed incorrectly by ConTeXt. > > >>>>> > > >>>>> Comparing index/name info of individual glyphs in the font > > >>>>> software and resulting pala.tma file there is the following > > >>>>> difference: > > >>>>> > > >>>>> Index | Name - font | Name - tma > > >>>>> 1110 | dotlessi.smcp | i.sc (1) > > >>>>> 1170 | i.smcp | i.sc (2) > > >>>>> > > >>>>> The first one should have IMHO a different name. > > >>>>> The same name for two glyphs might be dangerous. > > >>>> > > > > the fact that there are two i.sc in the font is suspicious ... best > > check the font in fontforge ... one never know what kind of things > > other programs do > > Hmm, FontForge glyphs naming corresponds to what we can observe in the > ConTeXt (doubled i.sc). My previous analysis was based on FontLab. I am > confused now... Actually, there are no names of these glyphs available in the font so they are calculated(!) Each of two programs uses a different method. FontLab method is based on layout tables - GPOS, GSUB, GDEF (it somehow detects that both glyps differs). The FontForge method is unclear and seems to be buggy. But we should blame rather the font itself as it is the primary cause of these problems (= missing glyph names). Jan

1 0

Re: [NTG-context] [***SPAM***] Incorrect internal font processing
by Hans Hagen 27 Nov '13

27 Nov '13

On 11/27/2013 10:20 PM, Jan Tosovsky wrote: > On 2013-11-27 Hans Hagen wrote: >> On 11/27/2013 9:53 PM, Jan Tosovsky wrote: >>> On 2013-11-27 Hans Hagen wrote: >>>> On 11/27/2013 8:44 PM, Jan Tosovsky wrote: >>>>> >>>>> during my attempts to patch the Palatino's dotless 'i' I found that >>>>> this font is parsed incorrectly by ConTeXt. >>>>> >>>>> Comparing index/name info of individual glyphs in the font software >>>>> and resulting pala.tma file there is the following difference: >>>>> >>>>> Index | Name - font | Name - tma >>>>> 1110 | dotlessi.smcp | i.sc (1) >>>>> 1170 | i.smcp | i.sc (2) >>>>> >>>>> The first one should have IMHO a different name, e.g. dotlessi.sc >>>>> (to keep conventions). The same name for two glyphs >>>>> might be dangerous. >>>> >>>> the font pala.ttf has two entries i.sc and i see no reference to >>>> *.smcp >>> >>> There is no 'i.sc' glyph available according to the font software, >>> only those .smcp, listed in the smcp6 table. >>> >>> As there are only .sc names in the TMA file, I suppose there is some >>> kind of name normalization. But not very precise... >> >> mtxrun --script font --save pala.ttf > > I can confirm your observations. In this lua export there is no .smcp, but > doubled i.sc records. Strange. There must be really some kind of > normalization there... the fact that there are two i.sc in the font is suspicious ... best check the font in fontforge ... one never know what kind of things other programs do > It would be nice to review the corresponding part of the code as it is IMHO > potentially dangerous. afaik no magic there 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 -----------------------------------------------------------------

2 1

Re: [NTG-context] [***SPAM***] Incorrect internal font processing
by Hans Hagen 27 Nov '13

27 Nov '13

On 11/27/2013 9:53 PM, Jan Tosovsky wrote: > On 2013-11-27 Hans Hagen wrote: >> On 11/27/2013 8:44 PM, Jan Tosovsky wrote: >>> >>> during my attempts to patch the Palatino's dotless 'i' I found that >>> this font is parsed incorrectly by ConTeXt. >>> >>> Comparing index/name info of individual glyphs in the font software >>> and resulting pala.tma file there is the following difference: >>> >>> Index | Name - font | Name - tma >>> 1110 | dotlessi.smcp | i.sc (1) >>> 1170 | i.smcp | i.sc (2) >>> >>> (2) - this is a composite character which consist of dotlessi.smcp >>> and dot. >>> >>> The first one should have IMHO a different name, e.g. dotlessi.sc (to >>> keep conventions). The same name for two glyphs might be dangerous. >> >> the font pala.ttf has two entries i.sc and i see no reference to *.smcp > > The version of my Palatino is 5.0 (I run on Win7) > It is located at c:/windows/fonts/pala.ttf i checked on windows 8 > There is no 'i.sc' glyph available according to the font software, only > those .smcp, listed in the smcp6 table. > > As there are only .sc names in the TMA file, I suppose there is some kind of > name normalization. But not very precise... > >> (mtxrun --script --save pala.ttf) mtxrun --script font --save pala.ttf > This returns an error: > c:/windows/fonts/pala.ttf:1: unexpected symbol > > Jan > > ___________________________________________________________________________________ > If your question is of interest to others as well, please add an entry to the Wiki! > > maillist : ntg-context(a)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 > ___________________________________________________________________________________ > -- ----------------------------------------------------------------- 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 -----------------------------------------------------------------

2 1

Re: [NTG-context] [
by Lars Huttar 27 Nov '13

27 Nov '13

In a thread from July (http://context.markmail.org/thread/6tgzusw45whaqghi) Marco Patzer raised some questions that we have too. They were somewhat answered, but I'm still not clear on what the meanings of the keywords are. On Jul 8, 2013 4:08:33 pm Hans wrote: > On 7/9/2013 12:30 AM, Marco Patzer wrote: > >/ On 2013–07–08 Hans Hagen wrote: > />/ > />>>/ I expect the markings on the left and right to be the same and show > />>>/ A–C on the first page and D–E on the second one. Looks like a bug to > />>>/ me. > />>/ > />>/ use top and bottom > />/ > />/ This works. Thanks. > />/ > />>/ -- previous : last before sync > />>/ -- next : first after sync > />>/ > />>/ -- top : first in sync > />>/ -- bottom : last in sync > />>/ > />>/ -- first : first not top in sync > />>/ -- last : last not bottom in sync > />/ > />/ That is exactly what's in the wiki (Command/getmarking). To my > />/ defence: The manual (chapter 12.4) is outdated, it lists: > />/ > />/ previous - the last of the previous page > />/ first - the first of the actual page > />/ last - the last of the actual page > />/ both - first — last > />/ all - previous — first — last > />/ > />/ I have no idea what “first not top in sync” means, in contrast to > />/ “first of the actual page”, which is quite clear but wrong on a > />/ current MkIV. > / > old tex terminology ... in mkiv i don't use the build-in-tex marks at > all (too much juggling needed to get things right) So I'm wondering ... Hans, since the descriptions you posted are old tex terminology, what do previous/next/top/bottom/first/last/etc. mean in current terminology? I agree with Marco that the descriptions in the ref manual are much easier to understand, but appear to be wrong; and do not include top/bottom. I'll be happy to update the ref manual and the wiki if I can get clear and accurate information. We have run many examples here, including the ones on the getmarking wiki page, trying to understand what these keywords mean. top/bottom do appear to do what we need in an MWE, but are not working for us in the real document, and knowing the meaning of these keywords would be very helpful in troubleshooting the problem. Thanks, Lars

2 8

Re: [NTG-context] [***SPAM***] Incorrect internal font processing
by Hans Hagen 27 Nov '13

27 Nov '13

On 11/27/2013 8:44 PM, Jan Tosovsky wrote: > Dear All, > > during my attempts to patch the Palatino's dotless 'i' I found that this > font is parsed incorrectly by ConTeXt. > > Comparing index/name info of individual glyphs in the font software and > resulting pala.tma file there is the following difference: > > Index | Name - font | Name - tma > 1110 | dotlessi.smcp | i.sc (1) > 1170 | i.smcp | i.sc (2) > > (2) - this is a composite character which consist of dotlessi.smcp and dot. > > The first one should have IMHO a different name, e.g. dotlessi.sc (to keep > conventions). The same name for two glyphs might be dangerous. the font pala.ttf has two entries i.sc and i see no reference to *.smcp (mtxrun --script --save pala.ttf) naming of glyphs is somewhat fuzzy and not always consistentent in fonts but i fear there is not much we can do here (apart from using palatino nova instead) 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 -----------------------------------------------------------------

2 1

Re: [NTG-context] Palatino patch for the current ConTeXt version
by Hans Hagen 27 Nov '13

27 Nov '13

On 11/27/2013 12:40 AM, Jan Tosovsky wrote: > On 2013-11-17 Hans Hagen wrote: >> On 11/17/2013 12:23 PM, honyk wrote: >>> Hello Everyone, >>> >>> I am trying to fix a Palatino small caps issue using the procedure >>> explained here: >>> http://wiki.contextgarden.net/Palatino_Linotype_under_MKIV >>> >>> That fix seems to be obsolete nowadays and returning errors. >>> >> >> there are several ways to apply patches runtime, see *.lfg files (and >> also fonts-mkiv.pdf) > > 1) I've created a sample LFG file > 2) placed it into the folder where other LFG files are stored > 3) removed pala.tma and pala.tmc files from the cache > 4) triggered the generating > > My pala.lfg file seems to be ignored: > > return { > name = "pala", > comment = "Switching the small capped 'i' to a dotless variant in > Palatino Linotype.", > remapping = { > tounicode = true, > unicodes = { > ["i.sc"] = 983201, > }, > }, > } > > 1) How the LFG file is matched with the font? Is it via the 'name' > parameter, "pala" in my case? Does that name equals to the file title > without an extension or something else? > > 2) Should I see that comment in the log or is it just a remark for editors? > > 3) Can I emulate this patch via direct editing of pala.tma file? When I > change the 'unicodes' value there, it has no impact on generating (nothing > changes in the output). you have to load them ... see fonts-mkiv.pdf ----------------------------------------------------------------- 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 -----------------------------------------------------------------

2 1

[***SPAM***] Incorrect internal font processing
by Jan Tosovsky 27 Nov '13

27 Nov '13

Dear All, during my attempts to patch the Palatino's dotless 'i' I found that this font is parsed incorrectly by ConTeXt. Comparing index/name info of individual glyphs in the font software and resulting pala.tma file there is the following difference: Index | Name - font | Name - tma 1110 | dotlessi.smcp | i.sc (1) 1170 | i.smcp | i.sc (2) (2) - this is a composite character which consist of dotlessi.smcp and dot. The first one should have IMHO a different name, e.g. dotlessi.sc (to keep conventions). The same name for two glyphs might be dangerous. Regards, Jan

1 0

ctxluacode inside bTABLE
by DesdeChaves 27 Nov '13

27 Nov '13

I try make a table with some random numbers but I found a problem with this code: \starttext \ctxluacode{v=math.random(400,600)/10;context("%0.1f",v) ;} \bTABLE \bTR\bTD Distance (cm) \eTD\bTD $\Delta t$ (s) \eTD\eTR \bTR\bTD[nr=3] \ctxluacode{v=math.random(400,600)/10;context("%0.1f",v) ;} \eTD\bTD t1 \eTD\eTR \bTR\bTD t2 \eTD\eTR \bTR\bTD t3 \eTD\eTR \eTABLE \stoptext \ctxluacode{v=math.random(400,600)/10;context("%0.1f",v) ;} don't work inside the bTABLE environment. Thanks in advance. Jorge

2 4

Re: [NTG-context] Palatino patch for the current ConTeXt version
by Hans Hagen 26 Nov '13

26 Nov '13

On 11/17/2013 12:23 PM, honyk wrote: > Hello Everyone, > > I am trying to fix a Palatino small caps issue using the procedure explained > here: > http://wiki.contextgarden.net/Palatino_Linotype_under_MKIV > > That fix seems to be obsolete nowadays and returning errors. > > I've changed > fonts.otf.enhancers.patches["^pala"] > to > fonts.handlers.otf.enhancers.patches["^pala"] > which compiles, but it does nothing. > > I've also tried this variant, but that 'patch' function is never called even > though I clear my font cache every run: > > \startluacode > local fonts = fonts > local otf = fonts.handlers.otf > local patches = otf.enhancers.patches > local register = patches.register > local report = patches.report > > function patch (data,filename) > report("I am here") > report("processing data %s", table.serialize(data)) > end > > register("after","prepare glyphs","^pala", patch) > \stopluacode > > > Any idea? patches are applied when a font is cached so you need to wipe the cache after defining such a patch there are several ways to apply patches runtime, see *.lfg files (and also fonts-mkiv.pdf) 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 -----------------------------------------------------------------

2 1

Re: [NTG-context] PDF bookmarks - incorrect titles for registers
by Hans Hagen 26 Nov '13

26 Nov '13

On 11/26/2013 8:03 PM, Jan Tosovsky wrote: > On 2013-11-18 Jan Tosovsky wrote: >> >> when I specify custom titles for my registers, they are ignored in >> bookmarks: >> >> \setupinteraction[state=start] >> \placebookmarks[chapter] >> \setupinteractionscreen[option=bookmark] >> >> \defineregister[indexname][indexnames] >> \defineregister[indexsubject][indexsubjects] >> \setupheadtext[indexname=Name Index] >> \setupheadtext[indexsubject=Subject Index] >> >> \starttext >> \completecontent >> \chapter{Chapter}text\indexname{primary}\indexsubject{primary} >> \startbackmatter >> \completeindexname >> \completeindexsubject >> \stopbackmatter >> \stoptext >> >> Is it necessary to switch something else on? > > According to the proposed solution at > http://tracker.luatex.org/view.php?id=865 > > it can be switched on using this magic formula > \enabledirectives[references.bookmarks.preroll] > > What is the correct usage of this? And are there any details why it is > required and what exactly it does? by default the title is set to a label which is not expandable the directive will convert the typeset title into a bookmark > When it is added to the beginning of my example, it returns an error: > attempt to call field 'boxtostring' (a nil value) ah, only in my experimental tree, i'll add it to the beta > But to be honest, I'd expect setting this flag internally by default as I > cannot imagine any use case where the index ID should be preferred in favor > of the title... as titles can be anything and bookmarks are limited, we need to have some protection in place ... unexpandable macros are simply dropped so \labeltext{index} becomes index 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 -----------------------------------------------------------------

2 2