Re: [NTG-context] Argument of \startInvoice has an extra }.
On Sat, Nov 09 2013, Aditya Mahajan wrote: > One possibility is to restrict optional arguments to one line: > > \def\beginInvoice{\bgroup\obeylines\dosingleempty\dobeginInvoice} > \def\dobeginInvoice[#1]{\egroup\grabbufferdata[myLetter][beginInvoice][endInvoice]} Thanks. How did you find the reason for the error (and the solution)? Is there also a solution with support for multiple lines? Unfortunately this does not work: --8<---cut here---start->8--- \def\beginInvoice{\bgroup\obeylines\dosingleempty\dobeginInvoice} \def\dobeginInvoice[#1]{\egroup\getparameters[PRM][#1]% \grabbufferdata[myLetter][beginInvoice][endInvoice]} \def\endInvoice{\getbuffer[myLetter]} \def\startInvoice#1\stopInvoice{#1} \starttext \beginInvoice[bla=blub, blub=bla] \startInvoice test \PRMblub \stopInvoice \endInvoice \beginInvoice \startInvoice test \stopInvoice \endInvoice \stoptext --8<---cut here---end--->8--- TIA, -- Peter ___ 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] Argument of \startInvoice has an extra }.
On Sat, 9 Nov 2013, Peter Münster wrote: Hi, How could I avoid that error here please: --8<---cut here---start->8--- \def\beginInvoice{\dosingleempty\dobeginInvoice} \def\dobeginInvoice[#1]{\grabbufferdata[myLetter][beginInvoice][endInvoice]} \def\startInvoice#1\stopInvoice{bla} \starttext \beginInvoice \startInvoice test \stopInvoice \endInvoice \stoptext One possibility is to restrict optional arguments to one line: \def\beginInvoice{\bgroup\obeylines\dosingleempty\dobeginInvoice} \def\dobeginInvoice[#1]{\egroup\grabbufferdata[myLetter][beginInvoice][endInvoice]} 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] Argument of \startInvoice has an extra }.
Hi, How could I avoid that error here please: --8<---cut here---start->8--- \def\beginInvoice{\dosingleempty\dobeginInvoice} \def\dobeginInvoice[#1]{\grabbufferdata[myLetter][beginInvoice][endInvoice]} \def\startInvoice#1\stopInvoice{bla} \starttext \beginInvoice \startInvoice test \stopInvoice \endInvoice \stoptext --8<---cut here---end--->8--- TIA for any help, -- Peter ___ 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] [font-syn.lua] remove call to fontloader.to_table()
On 11/9/2013 8:48 PM, Philipp Gesang wrote: Scratch that, I just did some tests and memory consumption seems to be the same. Thanks for revealing this feature! fyi: it's one of the reasons why the overhead in terms of memory of the initial loading of large fonts (pre-caching) became less (already a few years ago now) 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] [font-syn.lua] remove call to fontloader.to_table()
On 11/9/2013 8:42 PM, Philipp Gesang wrote: Aren’t you allocating fonts without freeing them? With this approach you need fontloader.close() somewhere inside check_names() which isn’t straightforward if you hide the font data inside the metatable. Btw. calling fontloader.info() first yields a table for ttcs and is unnoticable performance-wise. i assume that the loader automatically closes when the userdata is garbage collected (just like file handlers are) .. it doesn't seem to be a problem when generating the database 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] How to test the emptyness of a variable?
On Thu, 7 Nov 2013, Géry Ogam wrote: I'm sure there is also a "cleaner" TeX way, but I'm not experienced enough for that. I think you misunderstood my issue: your Lua way does the same thing than my TeX way: it displays: ONE Cool 2 Cat 3 Mouse but that is NOT what I want. What I want is: 1 Cool 2 Cat 3 Mouse So I need to check if the chapter label has been set empty or not by the user, because it is not empty (let's say the user chose the string "CHAPTER~" for the chapter label) I want to display this: CHAPTER ONE Cool CHAPTER 2 Cat CHAPTER 3 Mouse The way to do that is to check if the variable \currentstructurelabel is empty, so the code must be: Why not just check the labeltext? \define[1]\MyConversion {\doifelse{#1}{1}{ONE}{#1}} \define\CheckedConversion % #1 number {\doiftextelse{\labeltexts{chapter}}\MyConversion\numbers} \defineconversion[CheckedConversion][\CheckedConversion] \setuphead[chapter][conversion=CheckedConversion] \doifmode{label}{\setuplabeltext[chapter=CHAPTER~]} \starttext \chapter{Cool} \chapter{Cat} \chapter{Mouse} \stoptext compile with and without --mode=label. 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 ___
Re: [NTG-context] [font-syn.lua] remove call to fontloader.to_table()
· > · > > > On 11/9/2013 6:45 PM, Philipp Gesang wrote: > > > Hi all, > > > > > > calling fontloader.to_table() appears to be redundant when > > > extracting font names, see the attached patch. On my system I > > > measured 42 (patched) vs 59 (vanilla) seconds for rebuilding the > > > entire index: > > > > > >mtxrun --script fonts --reload --force > > > > > > The resulting index is -- except for the uuid, naturally -- > > > identical in both cases. > > > > Okay. > > > > In fact this fullinfo was meant as temporary hack because > > fontloader.info should return these values (and might at some time). > > > > In the meantime delayed loading was introduced which is why: > > > > function fontloader.fullinfo(...) -- lazy loading anyway > > local ff = fontloader.open(...) > > if ff then > > return ff > > else > > return nil, "error in loading font" > > end > > end > > > > also could work ok (in fact, the explicit glyphs = nil in the current > > variant assumes the old loader and has the speed impact you notice > > because it now first loads all glyphs and next discards them) > > > > Okay, in practice we need something like this: > > > > function fontloader.fullinfo(...) -- lazy loading anyway > > local ff = fontloader.open(...) > > if ff then > > local d = { } -- ff is userdata so [1] or # fails on it > > setmetatable(d, { __index = ff }) > > return d > > else > > return nil, "error in loading font" > > end > > end > > Aren’t you allocating fonts without freeing them? Scratch that, I just did some tests and memory consumption seems to be the same. Thanks for revealing this feature! Best, Philipp pgpjI__CuoJg1.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] [font-syn.lua] remove call to fontloader.to_table()
· > On 11/9/2013 6:45 PM, Philipp Gesang wrote: > > Hi all, > > > > calling fontloader.to_table() appears to be redundant when > > extracting font names, see the attached patch. On my system I > > measured 42 (patched) vs 59 (vanilla) seconds for rebuilding the > > entire index: > > > >mtxrun --script fonts --reload --force > > > > The resulting index is -- except for the uuid, naturally -- > > identical in both cases. > > Okay. > > In fact this fullinfo was meant as temporary hack because > fontloader.info should return these values (and might at some time). > > In the meantime delayed loading was introduced which is why: > > function fontloader.fullinfo(...) -- lazy loading anyway > local ff = fontloader.open(...) > if ff then > return ff > else > return nil, "error in loading font" > end > end > > also could work ok (in fact, the explicit glyphs = nil in the current > variant assumes the old loader and has the speed impact you notice > because it now first loads all glyphs and next discards them) > > Okay, in practice we need something like this: > > function fontloader.fullinfo(...) -- lazy loading anyway > local ff = fontloader.open(...) > if ff then > local d = { } -- ff is userdata so [1] or # fails on it > setmetatable(d, { __index = ff }) > return d > else > return nil, "error in loading font" > end > end Aren’t you allocating fonts without freeing them? With this approach you need fontloader.close() somewhere inside check_names() which isn’t straightforward if you hide the font data inside the metatable. Btw. calling fontloader.info() first yields a table for ttcs and is unnoticable performance-wise. Best, Philipp pgpDLLknNrBhp.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] [font-syn.lua] remove call to fontloader.to_table()
On 11/9/2013 6:45 PM, Philipp Gesang wrote: Hi all, calling fontloader.to_table() appears to be redundant when extracting font names, see the attached patch. On my system I measured 42 (patched) vs 59 (vanilla) seconds for rebuilding the entire index: mtxrun --script fonts --reload --force The resulting index is -- except for the uuid, naturally -- identical in both cases. Okay. In fact this fullinfo was meant as temporary hack because fontloader.info should return these values (and might at some time). In the meantime delayed loading was introduced which is why: function fontloader.fullinfo(...) -- lazy loading anyway local ff = fontloader.open(...) if ff then return ff else return nil, "error in loading font" end end also could work ok (in fact, the explicit glyphs = nil in the current variant assumes the old loader and has the speed impact you notice because it now first loads all glyphs and next discards them) Okay, in practice we need something like this: function fontloader.fullinfo(...) -- lazy loading anyway local ff = fontloader.open(...) if ff then local d = { } -- ff is userdata so [1] or # fails on it setmetatable(d, { __index = ff }) return d else return nil, "error in loading font" end end because I check for [1] or # in case of a ttc font which fails on the ff userdata table. This variant is somewhat more in tune with the 'full' aspect. Thanks for noticing, 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] [font-syn.lua] remove call to fontloader.to_table()
Hi all, calling fontloader.to_table() appears to be redundant when extracting font names, see the attached patch. On my system I measured 42 (patched) vs 59 (vanilla) seconds for rebuilding the entire index: mtxrun --script fonts --reload --force The resulting index is -- except for the uuid, naturally -- identical in both cases. Best, Philipp --- /home/phg/base/font-syn.lua 2013-10-25 00:01:04.0 +0200 +++ font-syn.lua2013-11-09 18:30:33.540364371 +0100 @@ -266,8 +266,21 @@ function fontloader.fullinfo(...) -- check with taco what we get / could get local ff = fontloader.open(...) if ff then -local d = ff and fontloader.to_table(ff) -d.glyphs, d.subfonts, d.gpos, d.gsub, d.lookups = nil, nil, nil, nil, nil +local fields = table.tohash (fontloader.fields (ff), true) +local d = { +names = fields.names and ff.names, +familyname = fields.familyname and ff.familyname, +fullname= fields.fullnameand ff.fullname, +fontname= fields.fontnameand ff.fontname, +weight = fields.weight and ff.weight, +italicangle = fields.italicangle and ff.italicangle, +units_per_em= fields.units_per_emand ff.units_per_em, +design_range_bottom = fields.design_range_bottom and ff.design_range_bottom, +design_range_top= fields.design_range_topand ff.design_range_top, +design_size = fields.design_size and ff.design_size, +italicangle = fields.italicangle and ff.italicangle, +pfminfo = fields.pfminfo and ff.pfminfo, +} fontloader.close(ff) return d else pgpACw5YFizX4.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] Configure AUCTeX to run context not texec
Le 09 novembre à 11:13:13 Peter Münster écrit notamment: | On Sat, Nov 09 2013, Jean Magnan de Bornier wrote: > | > This problem does not appear on my machine where instead of "context | > --nonstopmode %t" I wrote "PATH=~/context/tex/texmf-linux/bin:$PATH | > context %s" > | Interesting. What's your ConTeXt version, AUCTeX version and | Emacs version? emacs 24.3.1 ubuntu context minimal many versions (I update about once a week) auctex 11.87.2 (installed via elpa and frequently updated) I added the PATH thing so emacs can be started by the session manager. -- Jean ___ 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] two suggestions to \typesetbuffer
Am 09.11.2013 um 12:49 schrieb Pablo Rodriguez : > On 11/08/2013 11:39 PM, Hans Hagen wrote: >> On 11/8/2013 7:11 PM, Pablo Rodriguez wrote: >>> Dear Hans, >>> >>> I have presentations that include buffers typeset with \typesetbuffer. >>> >>> One of the presentation includes 33 buffers, which are small ConTeXt >>> samples. >>> >>> Any time I change anything on the presentation (not on the buffers >>> themselves), every buffer is typeset again. And the compilation time is >>> longer than probably desired. >>> >>> My first suggestion would be to skip compiling buffers again, if the >>> following three requirements are met: >>> >>> 1. Buffer content (.tmp file, I guess) is identical (checked with a >>> hash) with the previous one from last compilation. >> >> no temp file is used but a although a hash is possible it also means a >> lot of extra housekeeping due to the fact that buffers are reused (in >> which case no run happens) > > Compiling the presentation I‘m talking about for the first time on my > laptop takes about 210 seconds. Every subsequent compilation takes about > 70 seconds. > > I know my laptop is old and slow. > > But if I make a copy of the presentation source and remove the > \typesetbuffer commands, first compilation takes about 22 seconds and > subsequent compilations take about 7 seconds. > > I have no idea on how ConTeXt works internally, but what I’m trying to > say is that if \typesetbuffer has been already compiled, compiling again > is no gain. Try the filter module: https://github.com/adityam/filter Wolfgang ___ 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] two suggestions to \typesetbuffer
On 11/08/2013 11:39 PM, Hans Hagen wrote: > On 11/8/2013 7:11 PM, Pablo Rodriguez wrote: >> Dear Hans, >> >> I have presentations that include buffers typeset with \typesetbuffer. >> >> One of the presentation includes 33 buffers, which are small ConTeXt >> samples. >> >> Any time I change anything on the presentation (not on the buffers >> themselves), every buffer is typeset again. And the compilation time is >> longer than probably desired. >> >> My first suggestion would be to skip compiling buffers again, if the >> following three requirements are met: >> >> 1. Buffer content (.tmp file, I guess) is identical (checked with a >> hash) with the previous one from last compilation. > > no temp file is used but a although a hash is possible it also means a > lot of extra housekeeping due to the fact that buffers are reused (in > which case no run happens) Compiling the presentation I‘m talking about for the first time on my laptop takes about 210 seconds. Every subsequent compilation takes about 70 seconds. I know my laptop is old and slow. But if I make a copy of the presentation source and remove the \typesetbuffer commands, first compilation takes about 22 seconds and subsequent compilations take about 7 seconds. I have no idea on how ConTeXt works internally, but what I’m trying to say is that if \typesetbuffer has been already compiled, compiling again is no gain. >> 3. Buffer content was correctly compiled in previous compilation. > > define correctly I meant completely compiled: PDF has been generated. >> My second suggestion may be a bit complex to implement, but I think it >> would be useful. Wouldn’t it be possible that the fonts are only >> embedded one in the presentation? > > how often does it happen ... if we're talking about one page files > processing should normally fast e.g. > > \setupbodyfont[pagella] \starttext \input tufte \stoptext > > takes .3 seconds on my laptop. > > normally fonts are embedded efficiently (subsets) and shared Sorry, there was a typo in my message: “that fonts are only embedded once in the presentation”. My second suggestion isn’t about compilation time, but about duplicated fonts. I tried to provide a sample, but I don’t know why it doesn’t work: \starttext These are bufers: \dorecurse{10}{\startbuffer[text:\recurselevel]\setuppapersize[A7]\starttext\input tufte\stoptext\stopbuffer\typesetbuffer[text:\recurselevel][frame=on]} \stoptext Of course, fonts are embedded fine in documents, but \typesetbuffer is a special case. Having the fonts embedded only once in the final document would be better. Many thanks for your help, Pablo -- http://www.ousia.tk ___ 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] Configure AUCTeX to run context not texec
On Sat, Nov 09 2013, Jean Magnan de Bornier wrote: > This problem does not appear on my machine where instead of "context > --nonstopmode %t" I wrote "PATH=~/context/tex/texmf-linux/bin:$PATH > context %s" Interesting. What's your ConTeXt version, AUCTeX version and Emacs version? -- Peter ___ 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] Installing Context on Windows XP
Thanks for the tip. I have been very busy and forgot to say thanks. Better late than never. Nelson On 06-11-2013 16:28, Alan BRASLAU wrote: Try an ssh tunnel. See Proxy settings in http://wiki.contextgarden.net/ConTeXt_Standalone Alan On Wed, 6 Nov 2013 15:22:15 +0100 Nelson Goncalves wrote: Hello, I want to install Context on Windows XP, but the rsync commands fails because the network ports are closed. And the admin of my company does not want to modify the settings. Is there any other way to install Context on Windows other than the script for the command line ? Thanks, Nelson P.S - I already sacrified a member of my family and did the tours around the pentagram but the admin would not change his mind. ___ 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 ___