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 ngoncal...@nalys-group.com 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 ___
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] 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] two suggestions to \typesetbuffer
Am 09.11.2013 um 12:49 schrieb Pablo Rodriguez oi...@gmx.es: 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] Configure AUCTeX to run context not texec
Le 09 novembre à 11:13:13 Peter Münster pmli...@free.fr é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 ___
[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] [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
___
Re: [NTG-context] [font-syn.lua] remove call to fontloader.to_table()
···date: 2013-11-09, Saturday···from: Hans Hagen···
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()
···date: 2013-11-09, Saturday···from: Philipp Gesang···
···date: 2013-11-09, Saturday···from: Hans Hagen···
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] 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 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] [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 ___
[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] 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
___
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
___
