Re: [NTG-context] Multi-letter variables in math mode
On Wed, 27 Nov 2013, Thaddäus Töppen wrote: Hi. Sometimes I use variables (really rather abbreviations) in math formulas. It seems to me that the letterspacing is a bit too wide then. Maybe math mode thinks I want to multiply the letters as if they were variables for themselves. Is there a way to preserve normal letterspacing locally in a formula? Latex provides a \mathit macro for such variables. From what I understand, this is essentially the same as using \text{\it ...}. For example: \starttext \startformula \startalign \NC efat \NR \NC \text{\it efat} \NR \stopalign \stopformula \stoptext You could wrap this around in a macro, if you wish (but don't use \mathit, as that is reserved for normal math in context). Aditya___ 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 ___
[NTG-context] Multi-letter variables in math mode
Hi. Sometimes I use variables (really rather abbreviations) in math formulas. It seems to me that the letterspacing is a bit too wide then. Maybe math mode thinks I want to multiply the letters as if they were variables for themselves. Is there a way to preserve normal letterspacing locally in a formula? Kind regards. ___ 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 ___
Re: [NTG-context] [***SPAM***] Incorrect internal font processing
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 ___ 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 ___
Re: [NTG-context] Eliminating orpans in the Index
On 11/26/2013 10:09 PM, Jan Tosovsky wrote: On 2013-11-23 Jan Tosovsky wrote: in my two-column index there are several cases when the last entry in the given letter group overflows to the next column/page. In the extreme case it is just the last page reference. ... Additionaly, columns are not balanced properly in all cases. When the first is longer, it is not a big problem. But the opposite case looks weird. As the registers are rendered programatically, I cannot intervene into this process. But can I influence it e.g. using 'processors' applied to problematic index entries? Processors can be used for setting the font-weight or color of particular entry. Can the same method used for manual setting of 'keep-with-previous/next' ? I can think of a hack but it will always be for last minute work. 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 ___
Re: [NTG-context] [***SPAM***] Incorrect internal font processing
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, e.g. dotlessi.sc > > (to keep conventions). 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... Jan ___ 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 ___
Re: [NTG-context] [***SPAM***] Incorrect internal font processing
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 - ___ 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 ___
Re: [NTG-context] [***SPAM***] Incorrect internal font processing
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... It would be nice to review the corresponding part of the code as it is IMHO potentially dangerous. I felt obliged to report it :-) Jan ___ 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 ___
Re: [NTG-context] bug in beta: \tab results in text overlap
On 11/27/2013 5:08 PM, Lars Huttar wrote: On 11/22/2013 4:34 PM, Hans Hagen wrote: The problem, is/was that mixed columns had not yet mark synchronization enabled. I uploaded a new beta. In the process I also made marks a bit more restrictive but it might have (yet unknown) side effects. Hans, I tried the beta of 2013.11.26, and as mentioned in a previous email, it fixes the \getmarking problem pretty well. However the same beta has a fatal problem for us: lists using \tab are now broken. MWE: \starttext \tab{AC}Autonomous Community\par \tab{\it alt.}alternate name for\par \stoptext In the TeX Live 2013 version of mkiv, this gives us a nice table with the headword separated from the definition. In the beta, the headword and the definition start at the same horizontal position, and overlap each other. side effect of automatically cleaning up spaces (skips) ... \setupdescription [tab] [sample=\kern4\emwidth] % was \hskip fixed in next version (this command is sort of obsolete) 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 ___
Re: [NTG-context] [***SPAM***] Incorrect internal font processing
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@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 - ___ 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 ___
Re: [NTG-context] Palatino patch for the current ConTeXt version
On 11/27/2013 9:16 PM, Jan Tosovsky wrote: On 2013-11-27 Hans Hagen wrote: 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, }, }, } you have to load them ... see fonts-mkiv.pdf Thanks, I got it. Two next steps are required and one turned out as redundant. 1) Create a sample LFG file 2) Place it into the folder where other LFG files are stored 3) NEW! Execute 'mtxrun --generate' command to include newly added LFG file into a file database 4) NEW! Specify a new font feature referencing to this goodie: \definefontfeature[dotlessi][mode=base,goodies=pala,unicoding=yes] \definefontfamily[mainface][rm][Palatino Linotype][features={default,quality,dotlessi}] 5) Trigger the generating It does something, but not what I need :-) My MWE: \definefontfeature[dotlessi][mode=base,goodies=pala,unicoding=yes] \definefontfamily[palatino][rm][Palatino Linotype][features={default,quality,dotlessi}] \setupbodyfont[palatino] \starttext Athenians \sc{Athenians} \stoptext This LFG core settings: unicodes = { ["a.sc"] = 97, (1) ["b.sc"] = 983261, (2) }, (1) replaces all small 'a' into small caps variants - just for testing purposes (2) doesn't replace small caps 'i' to small caps 'b', but when small caps text is selected, b is copied into the clipboard - so some replacement is performed, but incomplete. Maybe other tables need to be tweaked as well... Has anybody any experience with this? this mechanism assumes that the shapes match the one that unicode expects so the (default) tounicode is used ... originally this features was meant for fonts with a faulty mapping (some dingbat fonts have that) 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 ___
Re: [NTG-context] [***SPAM***] Incorrect internal font processing
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 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) 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@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 ___
Re: [NTG-context] Palatino patch for the current ConTeXt version
On 2013-11-27 Hans Hagen wrote: > 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, > > }, > > }, > > } > > you have to load them ... see fonts-mkiv.pdf Thanks, I got it. Two next steps are required and one turned out as redundant. 1) Create a sample LFG file 2) Place it into the folder where other LFG files are stored 3) NEW! Execute 'mtxrun --generate' command to include newly added LFG file into a file database 4) NEW! Specify a new font feature referencing to this goodie: \definefontfeature[dotlessi][mode=base,goodies=pala,unicoding=yes] \definefontfamily[mainface][rm][Palatino Linotype][features={default,quality,dotlessi}] 5) Trigger the generating It does something, but not what I need :-) My MWE: \definefontfeature[dotlessi][mode=base,goodies=pala,unicoding=yes] \definefontfamily[palatino][rm][Palatino Linotype][features={default,quality,dotlessi}] \setupbodyfont[palatino] \starttext Athenians \sc{Athenians} \stoptext This LFG core settings: unicodes = { ["a.sc"] = 97, (1) ["b.sc"] = 983261, (2) }, (1) replaces all small 'a' into small caps variants - just for testing purposes (2) doesn't replace small caps 'i' to small caps 'b', but when small caps text is selected, b is copied into the clipboard - so some replacement is performed, but incomplete. Maybe other tables need to be tweaked as well... Has anybody any experience with this? Thanks, Jan ___ 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 ___
Re: [NTG-context] [***SPAM***] Incorrect internal font processing
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 - ___ 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 ___
[NTG-context] [***SPAM***] Incorrect internal font processing
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 ___ 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 ___
Re: [NTG-context] ctxluacode inside bTABLE
· > Solved > > \getrandomnumber{36}{56}{10} Or define it monadic: \def \getrandomnumber #1{\ctxluacode {document.get_random_number (#1)}} Now you can use your original syntax: \getrandomnumber {23, 42, 10} Though it blurs the line between TeX and Lua code. Best, Philipp > > > 2013/11/27 DesdeChaves > > > Is there a way to pass arguments to getrandomnumber() function? > > > > \startluacode > > local mathrandom = math.random > > local context= context > > document.get_random_number = function (min,max,delta) > > context ("%0.1f", mathrandom (min, max) / decimal) > > end > > \stopluacode > > > > \def \getrandomnumber#1#2#3 {\ctxluacode {document.get_random_number > > (#1,#2,#3)}} > > > > \starttext > > \bTABLE > > \bTR \bTD Distance (cm) \eTD \bTD $\Delta t$ (s) \eTD \eTR > > \bTR \bTD[nr=3] \getrandomnumber{34,56,10} \eTD \bTD t1 > > \eTD \eTR > > \bTR \bTD t2 \eTD \eTR > > \bTR \bTD t3 \eTD \eTR > > \eTABLE > > \stoptext > > > > > > 2013/11/27 Philipp Gesang > > > >> Hi Jorge, > >> > >> · > >> > >> > 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. > >> > >> just wrap the code in a macro. Lua code needs a different catcode > >> regime and expansion rules that don’t cooperate well with the > >> table scanner. E.g. > >> > >> \startluacode > >> local mathrandom = math.random > >> local context= context > >> document.get_random_number = function () > >> context ("%0.1f", mathrandom (400, 600) / 10) > >> end > >> \stopluacode > >> > >> \def \getrandomnumber {\ctxluacode {document.get_random_number ()}} > >> > >> \starttext > >> \bTABLE > >> \bTR \bTD Distance (cm) \eTD \bTD $\Delta t$ (s) \eTD > >> \eTR > >> \bTR \bTD[nr=3] \getrandomnumber \eTD \bTD t1 \eTD > >> \eTR > >> \bTR \bTD t2 \eTD > >> \eTR > >> \bTR \bTD t3 \eTD > >> \eTR > >> \eTABLE > >> \stoptext > >> > >> > >> Hth, > >> Philipp > >> > >> > >> > >> ___ > >> 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 > >> > >> ___ > >> > > > > > > > > -- > > Atentamente > > > > DesdeChaves > > > > > > -- > Atentamente > > DesdeChaves > ___ > 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 > ___ pgplurss59jv8.pgp Description: PGP signature ___ 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 ___
Re: [NTG-context] ctxluacode inside bTABLE
Solved \getrandomnumber{36}{56}{10} 2013/11/27 DesdeChaves > Is there a way to pass arguments to getrandomnumber() function? > > \startluacode > local mathrandom = math.random > local context= context > document.get_random_number = function (min,max,delta) > context ("%0.1f", mathrandom (min, max) / decimal) > end > \stopluacode > > \def \getrandomnumber#1#2#3 {\ctxluacode {document.get_random_number > (#1,#2,#3)}} > > \starttext > \bTABLE > \bTR \bTD Distance (cm) \eTD \bTD $\Delta t$ (s) \eTD \eTR > \bTR \bTD[nr=3] \getrandomnumber{34,56,10} \eTD \bTD t1 > \eTD \eTR > \bTR \bTD t2 \eTD \eTR > \bTR \bTD t3 \eTD \eTR > \eTABLE > \stoptext > > > 2013/11/27 Philipp Gesang > >> Hi Jorge, >> >> · >> >> > 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. >> >> just wrap the code in a macro. Lua code needs a different catcode >> regime and expansion rules that don’t cooperate well with the >> table scanner. E.g. >> >> \startluacode >> local mathrandom = math.random >> local context= context >> document.get_random_number = function () >> context ("%0.1f", mathrandom (400, 600) / 10) >> end >> \stopluacode >> >> \def \getrandomnumber {\ctxluacode {document.get_random_number ()}} >> >> \starttext >> \bTABLE >> \bTR \bTD Distance (cm) \eTD \bTD $\Delta t$ (s) \eTD >> \eTR >> \bTR \bTD[nr=3] \getrandomnumber \eTD \bTD t1 \eTD >> \eTR >> \bTR \bTD t2 \eTD >> \eTR >> \bTR \bTD t3 \eTD >> \eTR >> \eTABLE >> \stoptext >> >> >> Hth, >> Philipp >> >> >> >> ___ >> 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 >> >> ___ >> > > > > -- > Atentamente > > DesdeChaves > -- Atentamente DesdeChaves ___ 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 ___
Re: [NTG-context] ctxluacode inside bTABLE
Is there a way to pass arguments to getrandomnumber() function? \startluacode local mathrandom = math.random local context= context document.get_random_number = function (min,max,delta) context ("%0.1f", mathrandom (min, max) / decimal) end \stopluacode \def \getrandomnumber#1#2#3 {\ctxluacode {document.get_random_number (#1,#2,#3)}} \starttext \bTABLE \bTR \bTD Distance (cm) \eTD \bTD $\Delta t$ (s) \eTD \eTR \bTR \bTD[nr=3] \getrandomnumber{34,56,10} \eTD \bTD t1 \eTD \eTR \bTR \bTD t2 \eTD \eTR \bTR \bTD t3 \eTD \eTR \eTABLE \stoptext 2013/11/27 Philipp Gesang > Hi Jorge, > > · > > > 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. > > just wrap the code in a macro. Lua code needs a different catcode > regime and expansion rules that don’t cooperate well with the > table scanner. E.g. > > \startluacode > local mathrandom = math.random > local context= context > document.get_random_number = function () > context ("%0.1f", mathrandom (400, 600) / 10) > end > \stopluacode > > \def \getrandomnumber {\ctxluacode {document.get_random_number ()}} > > \starttext > \bTABLE > \bTR \bTD Distance (cm) \eTD \bTD $\Delta t$ (s) \eTD \eTR > \bTR \bTD[nr=3] \getrandomnumber \eTD \bTD t1 \eTD \eTR > \bTR \bTD t2 \eTD \eTR > \bTR \bTD t3 \eTD \eTR > \eTABLE > \stoptext > > > Hth, > Philipp > > > > ___ > 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 > > ___ > -- Atentamente DesdeChaves ___ 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 ___
Re: [NTG-context] ctxluacode inside bTABLE
Hi Jorge, · > 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. just wrap the code in a macro. Lua code needs a different catcode regime and expansion rules that don’t cooperate well with the table scanner. E.g. \startluacode local mathrandom = math.random local context= context document.get_random_number = function () context ("%0.1f", mathrandom (400, 600) / 10) end \stopluacode \def \getrandomnumber {\ctxluacode {document.get_random_number ()}} \starttext \bTABLE \bTR \bTD Distance (cm) \eTD \bTD $\Delta t$ (s) \eTD \eTR \bTR \bTD[nr=3] \getrandomnumber \eTD \bTD t1 \eTD \eTR \bTR \bTD t2 \eTD \eTR \bTR \bTD t3 \eTD \eTR \eTABLE \stoptext Hth, Philipp pgpVMnxrZGPeS.pgp Description: PGP signature ___ 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 ___
[NTG-context] ctxluacode inside bTABLE
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 ___ 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 ___
Re: [NTG-context] bug in beta: \tab results in text overlap
On 11/27/2013 11:08 AM, Lars Huttar wrote: > > I tried the beta of 2013.11.26, and as mentioned in a previous > email, it fixes the \getmarking problem pretty well. However the same > beta has a fatal problem for us: lists using \tab are now broken. > > MWE: > \starttext > \tab{AC}Autonomous Community\par > \tab{\it alt.}alternate name for\par > \stoptext > > In the TeX Live 2013 version of mkiv, this gives us a nice table with > the headword separated from the definition. > In the beta, the headword and the definition start at the same > horizontal position, and overlap each other. > > We use these lists in the context of mixedcolumns, but the overlap > behavior occurs regardless of mixedcolumns. > > Any help would be appreciated. If we can't fix or work around this > problem, we may have to abandon the beta and go back to TeX Live 2013, > which means our page header guide words would be incorrect. > Well, it's probably not quite that fatal for our project, because it looks like the \definedescription mechanism can be used to replace \tab, and does not suffer from the same problem in the beta. Nevertheless I thought someone would like to know that \tab has stopped working, so it can be fixed (or documented as obsolete, in favor of \definedescription). Lars ___ 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 ___
[NTG-context] bug in beta: \tab results in text overlap
On 11/22/2013 4:34 PM, Hans Hagen wrote: > > The problem, is/was that mixed columns had not yet mark > synchronization enabled. I uploaded a new beta. In the process I also > made marks a bit more restrictive but it might have (yet unknown) side > effects. Hans, I tried the beta of 2013.11.26, and as mentioned in a previous email, it fixes the \getmarking problem pretty well. However the same beta has a fatal problem for us: lists using \tab are now broken. MWE: \starttext \tab{AC}Autonomous Community\par \tab{\it alt.}alternate name for\par \stoptext In the TeX Live 2013 version of mkiv, this gives us a nice table with the headword separated from the definition. In the beta, the headword and the definition start at the same horizontal position, and overlap each other. We use these lists in the context of mixedcolumns, but the overlap behavior occurs regardless of mixedcolumns. Any help would be appreciated. If we can't fix or work around this problem, we may have to abandon the beta and go back to TeX Live 2013, which means our page header guide words would be incorrect. Lars ___ 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 ___
Re: [NTG-context] Palatino patch for the current ConTeXt version
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 - ___ 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 ___