- ntg-context - Mailing Lists

[***SPAM***] RE: Footnote line position
by Jan Tosovsky 01 Dec '13

01 Dec '13

On 2013-11-22 Jan Tosovsky wrote: > > when a single line footnote is used, the footnote divider is > rendered in larger distance than for footnotes with two or > more lines (I mean a gap between the line and the footnote text). > > It can be tested easily: > > \chapter{Chapter}Foo\footnote{Bar}. > \chapter{Chapter}Foo\footnote{Bar > > Bar}. > This behaviour seems to be driven by this code in strc-not.mkvi: \unexpanded\def\normalnoterule {\ifvmode \dontleavehmode \blackrule [\c!color=\noteparameter\c!rulecolor, \c!width=.2\hsize, \c!height=\noteparameter\c!rulethickness, \c!depth=\zeropoint]% \endgraf \kern\strutdepth \fi} When e.g. \endgraf or \kern\strutdepth lines are commented, the gap is smaller, but still different. Changing the depth from \zeropoint to a bigger value (1cm) makes the gap same, but it leads to extreme thick rule. What else could be tweaked here? Thnaks, Jan

1 0

Re: [NTG-context] Palatino patch for the current ConTeXt version
by Jan Tosovsky 01 Dec '13

01 Dec '13

On 2013-11-17 Jan Tosovsky wrote: > > 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. > almost fixed now using this procedure: 1) Create a new LFG file local fix_pala = { comment = "Switching i.sc glyphs indexes", fixes = function(data) local descriptions = data.descriptions descriptions[983201].index = 1170 descriptions[983261].index = 1110 end } return { name = "pala", comment = "Switching the small capped 'i' to a dotless variant in Palatino Linotype.", treatments = { ["pala.ttf"] = fix_pala, ["palai.ttf"] = fix_pala, ["palab.ttf"] = fix_pala, ["palabi.ttf"] = fix_pala, }, } 2) Place it into the folder where other LFG files are stored (tex\texmf-context\tex\context\fonts) 3) Execute 'mtxrun --generate' command to include newly added LFG file into a file database 4) Specify a new font feature referencing to this goodie in the source file: \definefontfeature[dotlessi][mode=base,goodies=pala] \definefontfamily[palatino][rm][Palatino Linotype][features={default,quality,dotlessi}] \setupbodyfont[palatino] \starttext {Athenians \smallcaps{Athenians}}\par {Athenians \sc{Athenians}}\par {\it Athenians \smallcaps{Athenians}}\par {\bf Athenians \smallcaps{Athenians}}\par {\bi Athenians \smallcaps{Athenians}}\par \stoptext 5) Trigger the generating It works except the regular font style. In this case \smallcaps option behaves differently than for e.g. \it or \bf styles. I am quite confused. Moreover, when faked caps are switched on using \sc, it works. Can anybody explain what is happening here? Thanks, Jan

1 0

Re: [NTG-context] Placefigure without Caption-Numbering
by Alan Braslau 01 Dec '13

01 Dec '13

On Sat, 30 Nov 2013 21:06:20 +0100 Jan Tosovsky <j.tosovsky(a)email.cz> wrote: > Indeed much cleaner. But that numbering option seems to be ignored ;-) > Does it work for you? Sorry, it is "number=no". Alan

1 0

Re: [NTG-context] Placefigure without Caption-Numbering
by Alan Braslau 30 Nov '13

30 Nov '13

On Sat, 30 Nov 2013 19:42:54 +0100 Jan Tosovsky <j.tosovsky(a)email.cz> wrote: > On 2013-04-16 Wolfgang Schuster wrote: > > Am 16.04.2013 um 18:56 schrieb "H. Özoguz" <h.oezoguz at mmnetz.de>: > > > > > > How to deactive the Caption-Numbering: > > > > > > \starttext > > > > > > \placefigure[here]{Blub}{\externalfigure[image][width=6cm]} > > > > > > \stoptext > > > > > > I want the caption "Blub", but not the "Figure 1" label. > > > > \placefigure[here,nonumber]{.}{.} > > It helped me now. > > Btw, there is no such an option mentioned in the WIKI or user guide... > > http://wiki.contextgarden.net/Command/placefigure > > But I'd like to add: > (1) caption=none renders 'none' instead of nothing... > (2) when key=none is combined, e.g. [none, page], the numbering is > suppressed, but the second option is ignored. But [page, none] works > fine. The order matters. It is same for [page, nonumber]. > > It would be nice to fix those examples in Wiki or if MkIV behaves > differently, add an appropriate alternative there. > > Thanks, Jan I find that the \startplacefigure \stopplacefigure interface is much cleaner: \startplacefigure [location=here,numbering=no,title=Blub] \externalfigure [image] [width=6cm] \stopplacefigure Alan

2 1

Re: [NTG-context] Placefigure without Caption-Numbering
by Jan Tosovsky 30 Nov '13

30 Nov '13

On 2013-04-16 Wolfgang Schuster wrote: > Am 16.04.2013 um 18:56 schrieb "H. Özoguz" <h.oezoguz at mmnetz.de>: > > > > How to deactive the Caption-Numbering: > > > > \starttext > > > > \placefigure[here]{Blub}{\externalfigure[image][width=6cm]} > > > > \stoptext > > > > I want the caption "Blub", but not the "Figure 1" label. > > \placefigure[here,nonumber]{.}{.} It helped me now. Btw, there is no such an option mentioned in the WIKI or user guide... http://wiki.contextgarden.net/Command/placefigure But I'd like to add: (1) caption=none renders 'none' instead of nothing... (2) when key=none is combined, e.g. [none, page], the numbering is suppressed, but the second option is ignored. But [page, none] works fine. The order matters. It is same for [page, nonumber]. It would be nice to fix those examples in Wiki or if MkIV behaves differently, add an appropriate alternative there. Thanks, Jan

1 0

Keeping titles together with the following text when grid is on
by Jan Tosovsky 30 Nov '13

30 Nov '13

Dear All, when grid is on, orphan and widows have to be eliminated using additional penalty settings. Whereas it works fine for body text, section titles are still sometimes left at the bottom of the page. It can be reproduced using this example: \setuppapersize[B5] \startsetups[grid][mypenalties] \setdefaultpenalties \setpenalties\widowpenalties{2}{10000} \setpenalties\clubpenalties {2}{10000} \stopsetups %comment the following line to see the difference \setuplayout[grid=yes, setups=mypenalties] \showgrid \starttext \blank[force, 9.5cm] \input tufte \section{Tufte} \input tufte \stoptext Is there any extra option for handling this? Thanks, Jan

1 0

Duplexing a single-sided layout?
by Adam Khan 30 Nov '13

30 Nov '13

I have a document in which left and right cannot be equated with inner and outer respectively (outside the header texts). So I use \setuppagenumbering[alternative={singlesided,doublesided}]. But I still need a gutter along (what would be) the inner margin. So, how would I go about duplexing a single-sided layout? For example: \definepapersize[custom][width=335mm,height=500mm] \setuppapersize[custom][B3] \setuplayout[% width=middle,% height=middle,% backspace=90mm,% topspace=25mm,% leftmargin=30mm,% rightmargin=15mm,% leftmargindistance=5mm,% rightmargindistance=20mm,% location={doublesided,duplex},% bottomspace=25mm,% cutspace=90mm] \setuppagenumbering[alternative={singlesided,doublesided}] Sincerely yours, Adam Khan

1 0

Re: [NTG-context] [***SPAM***] Provide showgrid as a PDF layer
by Hans Hagen 30 Nov '13

30 Nov '13

On 11/30/2013 12:04 AM, Jan Tosovsky wrote: > Dear All, > > it would be nice to have a possibility to interactively disable/enable a > grid rendered via \showgrid command. Whereas this grid is helpful for > debugging, it disturbs when the page is evaluated as the whole. Using layers > could make this process more efficient (not requiring to generate both > variants). > > I've noticed something like this is already implemented for the body area > (visualizer vbox layer). > > Or is there any option for this already? \setupinteraction[state=start] \showgrid \showframe \showmakeup \showlayoutcomponents \starttext \input tufte \placefigure{}{} \stoptext but you need a viewer that supports layers (can turn them on and off) 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

[***SPAM***] Provide showgrid as a PDF layer
by Jan Tosovsky 30 Nov '13

30 Nov '13

Dear All, it would be nice to have a possibility to interactively disable/enable a grid rendered via \showgrid command. Whereas this grid is helpful for debugging, it disturbs when the page is evaluated as the whole. Using layers could make this process more efficient (not requiring to generate both variants). I've noticed something like this is already implemented for the body area (visualizer vbox layer). Or is there any option for this already? Thanks, Jan

1 0

Re: [NTG-context] Eliminating orpans in the Index
by Hans Hagen 29 Nov '13

29 Nov '13

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 -----------------------------------------------------------------

2 1

bibliography - maybeyear
by Alan Braslau 29 Nov '13

29 Nov '13

Hello, Using \setuppublications [alternative=num] for example, should not append letters to the publication years when encountering multiple publications by the same author(s) per year. So, in the use of bibliographies, I have not understood how to control \maybeyear. In the bibl-xxx.tex files, it is defined as \def\maybeyear#1{#1} or \def\maybeyear#1{} as needed. Perhaps this is for mkii. In bibl-bib.mkiv, one has \appendtoks \doifelse{\bibtexpublicationsparameter\c!maybeyear}\v!off {\let\maybeyear\gobbleoneargument} {\let\maybeyear\firstofoneargument}% \to \everysetupbibtexlistplacement which seems to then use the keyword maybeyear. I guess that \setupbibtexpublications [maybeyear=off] in my source would turn off the appended letters, but this is not correct. I have tried many variants (\setuppublications, \setupbibtex). What am I misunderstanding? Or is this a bug? Alan

3 5

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

29 Nov '13

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 -----------------------------------------------------------------

2 1

sagemath in context (like sagetex)
by Xan 29 Nov '13

29 Nov '13

Hi, Is there any kind of package for embedded sagemath in ConTeXt (like sagetex in latex). I found the same question previosly asked (http://www.ntg.nl/pipermail/ntg-context/2009/040483.html) but more things are changed until 2009... so perhaps there is now a solution By the other hand, I see lua lunatic code: http://wiki.contextgarden.net/User:Luigi.scarso/luatex_lunatic#SageMath but this is very programmer centric code, in my opinion. Is there any easy way to do that? I use MKIV Thanks, Xan.

1 0

Unexpected behaviour of enumeration in mkiv
by Thomas Möbius 28 Nov '13

28 Nov '13

Hi, please have a look at the minimal example at the bottom. I am typesetting theorems and lemmata which are numbered consecutively within chapters in a book. I used the same code for a document written in mkii, and I thought I could just reuse it in mkiv. Obviously, there is something I am missing. Question: How do I get the same output when compiling the following code with 'context' as when compiled with 'texexec'. When compiled with 'context', the chapter number is missing in the numbering of theorems. Lemmas are not numbered at all. ~~~snip~~~ \setupenumerations [title=yes, style=normal, list=all, before={\blank[big]}, after={\blank[big]}, location=serried, width=broad, distance=0.5em, headstyle=bold, titlestyle=bold, way=bychapter, conversion=numbers] \defineenumeration [theorem] [text=Theorem, listtext={Theorem }] \defineenumeration [lemma] [text=Lemma, listtext={Lemma }, number=theorem] \starttext \chapter{First chapter} \theorem Hello \theorem Hello \lemma Hello \theorem Hello \stoptext ~~~snip~~~

2 3

Line numbers and tabulate cells in Mark IV
by Adam Khan 28 Nov '13

28 Nov '13

The lines of a tabulate cell may be numbered with code like the following under Mark II, but not under Mark IV. \starttabulate[|p|p|] \NC \input knuth \NC \startlinenumbering \input knuth \stoplinenumbering \NC\NR \stoptabulate How may the lines of a tabulate cell be numbered under Mark IV? Sincerely yours, Adam Khan

2 2

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

28 Nov '13

On 11/27/2013 11:35 PM, Jan Tosovsky wrote: > 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 that is okay to make names unique, although there can still be multiple variants so in fact i.smcp and i.ss01.4 are valid names then, but .smcp and .onum are not understood by name parsers (for adobe glyph names) > differs). The FontForge method is unclear and seems to be buggy. But we some kind of numbering would make more sense i.1 or so > should blame rather the font itself as it is the primary cause of these > problems (= missing glyph names). indeed 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 -----------------------------------------------------------------

1 0

Multi-letter variables in math mode
by Thaddäus Töppen 28 Nov '13

28 Nov '13

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.

2 1

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