- ntg-context - NTG Mailing Lists

how to reduce \lineskiplimit in ConTeXt grid layout
by Lars Huttar 15 Nov '13

15 Nov '13

As you know, in plain TeX, \lineskiplimit tunes the vertical glue algorithm by specifying the minimum amount of space between the bottom edge of one line and the top edge of the following line. But in ConTeXt, it appears that \lineskiplimit is set to zero, at least in grid mode. We're using grid mode, and we have some occasional high ascenders, e.g. capital letters with diacritics on top. We have bodyfont size 8.1pt, and interlinespace = 9.3pt. We realize this is less than the recommended ratio of 1.2. Understandably, when those tall characters occur, we sometimes get a blank line above them. It looks like the \lineskiplimit would be violated if the 9.3pt interlinespace were enforced, so ConTeXt adds some space (analogous to \lineskip in TeX?). But since we're on a grid, more space has to be added in order to conform to the grid. All that makes sense, but we would like to be able typeset the lines closer together, and judge for ourselves whether it looks too bad. (When we used to typeset the same text at 8.1pt/9.3pt using mkii, blank lines did not occur.) Is there something similar to \lineskiplimit that we can tweak? I've been reading section 5.5 Line Spacing in the context ref manual, but I don't see anything there about changing a threshold analogous to \lineskiplimit. I tried setting \lineskiplimit=-2pt, but that caused a worse problem: a blank line across both columns, instead of just one. Thanks, Lars Version: mkiv luatex in Tex Live 2013.

2 5

simplefonts: defining a fallback for a non-main font
by Lars Huttar 15 Nov '13

15 Nov '13

Hi again, I'm using simplefonts (TeX Live 2013 version) and I have a main font: \setmainfont[Gentium Book Basic] and I can set a fallback for it, \setmainfontfallback[Gentium Plus][range={ipaextensions}, force=yes, rscale=auto] and that works. But then I have another font for the title: \definesimplefont[titleface][Gentium Basic][size=40pt] How do I set a fallback for it? After looking at the source code for simplefonts, I tried: % undefined cs: \definesimplefontfallback[titleface][Gentium Plus][range={ipaextensions}, force=yes, rscale=auto] % undefined cs: \fontfallback[titleface][Gentium Plus][range={ipaextensions}, force=yes, rscale=auto] % undefined cs: \definefallbackfont[titleface][Gentium Plus][range={ipaextensions}, force=yes, rscale=auto] But they all gave "undefined control sequence" errors. I can work around the problem by setting the main font before the title, using the main font for the title, and then changing the main font after the title is done. But that seems kludgy. Thanks, Lars

3 5

Re: [NTG-context] Index - ranges
by honyk 15 Nov '13

15 Nov '13

On 2013-11-15 honyk wrote: > On 2013-11-12 honyk wrote: > > On 2013-11-07 honyk wrote: > > > > > > 1) when a range for my subject index entry is specified and the > > > text between doesn't overflow to the next page, even in this case > > > the range of pages 1-1 is created. Is there any option to normalize > > > it to a single page number? > > > > > > \startregister[index][range_01]{primary} > > > Dummy text. > > > \stopregister[index][range_01] I've finally found it is caused by this logic: if first == last then if first.references.lastrealpage then -- IMHO this could be optional pagerange(first,first,true,prefixspec,pagespec) else pagenumber(first,prefixspec,pagespec) end elseif last.references.lastrealpage then pagerange(first,last,true,prefixspec,pagespec) else pagerange(first,last,false,prefixspec,pagespec) end Even after normalization, if there is a range, it is preserved regardless it spans multiple pages or not. The fix is quite easy. But whether to convert these single page ranges into a single value or not could be optional, or applied according to the compress parameter (both 'yes' and 'all' would collapse the range). Jan

1 0

Win64 Version of ConTeXt Standalone?
by Bill Meahan 15 Nov '13

15 Nov '13

I'm curious (not complaining). Does a Win64 version of the Standalone suite exist? Certainly the 32-bit binary works fine (the exigencies of WOW64 notwithstanding) but it seems odd to me 64-bit versions for Mac, Linux, FreeBSD or FreeBSD/Debian exist but not a 64-bit Windows version. This seems particularly odd given most laptops/desktops the last few years have been 64-bit with a 64-bit OS even the cheap consumer-grade laptop I bought my wife. Is there a technical reason or simply lack of a maintainer? -- Bill Meahan, Westland, Michigan “Writing is like getting married. One should never commit oneself until one is amazed at one's luck.” —Iris Murdoch

2 1

Is it OK to release the source files of fonts-mkiv.pdf?
by seasoul 15 Nov '13

15 Nov '13

Recently I encountered to the new font manual in mkiv. http://www.pragma-ade.com/general/manuals/fonts-mkiv.pdf I really like the document style: the structure, the page and section design. where could I find the source files, if it is ok to be released to the public. Thanks.

1 0

Re: [NTG-context] Handling index entries with many references
by honyk 15 Nov '13

15 Nov '13

On 2013-06-09 honyk wrote: > > in my book I want to place the index (aka register) of places. > Some of them are mentioned very often (>10). > > In one old book I've found the following solution for this: > in the index there are first three page references listed for > that index entry followed by 'and many' phrase. > > Can something like this be done in the ConTeXt (MkIV)? I found an elegant way for this: \defineprocessor[many][right= and many] This processor is then applied just for the last index entry page reference: \index[many->]{primary} This can be automated in my system. Wow, great! Jan

1 0

"no format found" only with "--jit" option
by stephleg＠free.fr 15 Nov '13

15 Nov '13

Hello, For the same ConTeXt file, if i use the "--jit" option i get the following error: mtx-context | error, no format found with name: cont-en, aborting But when i use no option, there is no error and the PDF is ok. This is with ConTeXt version "2013.11.14 23:22". Regards, Stéphane.

1 0

Re: [NTG-context] Index - ranges
by honyk 15 Nov '13

15 Nov '13

On 2013-11-12 honyk wrote: > On 2013-11-07 honyk wrote: > > > > 1) when a range for my subject index entry is specified and the text > > between doesn't overflow to the next page, even in this case > > the range of pages 1-1 is created. Is there any option to normalize > > it to a single page number? > > > > \startregister[index][range_01]{primary} > > Dummy text. > > \stopregister[index][range_01] > > > I've found a promising option compress=no|yes|all in an experimental > test case located in the strc-reg.mkiv file. The corresponding lua > code seems to be performing some cleanup of page ranges, but when > I define it same way, there is no difference in my output (still 1-1). Looking into the lua code this one is an edge case as normalization is performed if #pages > 1 which is not achieved here. No problem. But I've encountered more serious issue now: When original pages are 'compressed' for the index 114, 117, 119, 122, 130-132, 135, 135-139, 188-204, 321-321 The incorrect result is returned: 114, 117, 119, 122, 130-135, 135-321 I'd expect: 114, 117, 119, 122, 130-132, 135-139, 188-204, 321 Debugging it roughly I've noticed unsorted page numbers before compressing (in collapsedpage function in strc-reg.lua), which leads to unexpected result from first/second comparison. Some kind of page entries sorting might help here. Regards, Jan

1 0

TEXpage problem in lare betas
by Thomas A. Schmitz 15 Nov '13

15 Nov '13

Hi, the latest betas have problems with TEXpage. The following example gives the expected result with an older version of context (2013.06.10 22:51), but fails with several betas from November (empty page created, no error); unfortunately, it is an older file, and I have no idea when exactly it broke: \startTEXpage[offset=0.5ex] \bTABLE[frame=off,loffset=1ex,roffset=1ex,align={middle,lohi}] \bTR \bTD A \eTD \bTD B \eTD \bTD C \eTD \eTR \eTABLE \stopTEXpage All best Thomas

4 12

Problem with *lettrine* module in Mk-iv
by Francisco Gracia 14 Nov '13

14 Nov '13

I am glad to report that the problems that I experienced until recently with the *lettrine* module have disappeared. At present it works like any other regular module. As the *lettrine* source file does not seem to have been modified, I conclude that the reason of the improvement should be attributed to the modification of some other unknown piece of the complex *ConTeXt* machinery. The interpreter at work is mkiv lua stats > luatex banner: this is luatex, version beta-0.77.0 (tex live 2013/w32tex) (rev 4645) This should be good news (at least it has been for me) as *lettrine* is a more powerful and complete command than *inital* for the intended job and, above all, is much better documented. Regards Francisco

1 0