Re: [NTG-context] Minor date formatting issue

2013-08-09 Thread Wolfgang Schuster

Am 09.08.2013 um 05:43 schrieb Matt Gushee :

> Hello, all--
> 
> I am experimenting with the \currentdate command. I am finding that
> 
>  \currentdate [weekday,{,~},month,day+,{,~},year]
> 
> which should work according to the Wiki, produces:
> 
>  Thursday, Augustday+, 2013
> 
> This command:
> 
>  \currentdate [weekday,{,~},month,day,{,~},year]
> 
> works as expected. I also tried
> 
>  \date [][weekday,{,~},month,day+,{,~},year]
> 
> but that produced the same result as above.
> 
> I have a recent stable release of the standalone ConTeXt package from
> the Garden. Is there a new way to format a date with an ordinal
> indicator (-st, -nd, -rd, -th), or is that just not working at the
> moment? Please advise.


It’s recommended to use “day:ord” with \currentdate but you also use “day:+”.

\starttext
\currentdate[day,space,day:ord,space,day:+]
\stoptext

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] include two pages from typesetbuffer

2013-08-09 Thread Pablo Rodríguez
On 08/08/2013 10:40 PM, Hans Hagen wrote:
> On 8/8/2013 10:15 PM, Hans Hagen wrote:
>> On 8/8/2013 9:01 PM, Pablo Rodríguez wrote:
>>> Dear list,
>>>
>>> I would like to be able to include the first two pages of a typeset
>>> buffer (included with \typesetbuffer[sample][frame=on]).
>>>
>>> Is there any way to do this? I’d like to avoid to save the buffer to a
>>> file.
>>
>> \typesetbuffer[sample][frame=on,page=1]
>> \typesetbuffer[sample][frame=on,page=2]
> 
> as that runs the buffer twice the next beta will provide  this:

Many thanks, Hans, for the new feature.

I can wikify it, if you want me to do it. But I have a question before.

Wouldn’t it be easier that ConTeXt detects when a buffer has already
been typeset and automatically does all the work internally?

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
___


[NTG-context] internal mptopdf converter skips some glyphs in labels

2013-08-09 Thread Sanjoy Mahajan
The internal mptopdf converter in MkIV omit some glyphs in the labels.
Here's a minimal example (test.tex):

\starttext

\externalfigure[testfig.1][frame=on]
\blank
\externalfigure[testfig-1.pdf][frame=on]

\stoptext

And testfig.1 is produced by testfig.mp

beginfig(1)
label(btex $\Omega$ etex, (0,0));
currentpicture := currentpicture scaled 5;
endfig;
end

Here's testfig.1 to save a step in debugging:

%!PS
%%BoundingBox: -18 -18 18 18 
%%HiResBoundingBox: -17.98805 -17.0195 17.98798 17.0195 
%%Creator: MetaPost 1.803
%%CreationDate: 2013.08.09:1612
%%Pages: 1
%*Font: cmr10 49.81323 9.96265 0a:8
%%BeginProlog
%%EndProlog
%%Page: 1 1
 0 0 0 setrgbcolor
-17.98805 -17.0195 moveto
(\012) cmr10 49.81323 fshow
showpage
%%EOF

Then do:

  mptopdf testfig.1
  context test.tex
  xpdf test.pdf

The first framed box, using the internal mps->pdf conversion, is empty.
The second framed go, using the pdf file produced by mptopdf, correctly
contains \Omega.

With \enabletrackers[graphics.conversion,graphics.inclusion], the log
has the following lines, none of which seem to pinpoint the problem:

  graphics> inclusion > checking conversion of 'testfig.1', fullname 
'testfig.1', old format 'mps', new format 'pdf', conversion 'default', 
resolution 'default'
  graphics> inclusion > no converter for 'mps' to 'pdf'
  [MP to PDF]
  graphics> inclusion > checking conversion of 'testfig-1.pdf', 
fullname 'testfig-1.pdf', old format 'pdf', new format 'pdf', conversion 
'default', resolution 'default'
  graphics> inclusion > no converter for 'pdf' to 'pdf'
  graphics> inclusion > new graphic, using hash 
'testfig-1.pdf->1->crop->unknown->unknown->unknown->'

(Though I don't believe the "no converter for 'mps' to 'pdf'" diagnostic.)

This is with Context 2013.05.28 00:36 MKIV (TL2013 on Debian).

-Sanjoy
___
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] internal mptopdf converter skips some glyphs in labels

2013-08-09 Thread Aditya Mahajan

On Fri, 9 Aug 2013, Sanjoy Mahajan wrote:


The internal mptopdf converter in MkIV omit some glyphs in the labels.
Here's a minimal example (test.tex):

\starttext

\externalfigure[testfig.1][frame=on]
\blank
\externalfigure[testfig-1.pdf][frame=on]

\stoptext

And testfig.1 is produced by testfig.mp


Any particular reason that you are compiling metapost files using mp and 
then including them in ConTeXt rather than directly using any one of the 
inbuilt ConTeXt environments for handling mp (\startMPcode, \useMPgraphic, 
\processMPbuffer, etc.)



beginfig(1)
label(btex $\Omega$ etex, (0,0));
currentpicture := currentpicture scaled 5;
endfig;
end

Here's testfig.1 to save a step in debugging:

%!PS
%%BoundingBox: -18 -18 18 18
%%HiResBoundingBox: -17.98805 -17.0195 17.98798 17.0195
%%Creator: MetaPost 1.803
%%CreationDate: 2013.08.09:1612
%%Pages: 1
%*Font: cmr10 49.81323 9.96265 0a:8
%%BeginProlog
%%EndProlog
%%Page: 1 1
0 0 0 setrgbcolor
-17.98805 -17.0195 moveto
(\012) cmr10 49.81323 fshow
showpage
%%EOF

Then do:

 mptopdf testfig.1
 context test.tex
 xpdf test.pdf

The first framed box, using the internal mps->pdf conversion, is empty.
The second framed go, using the pdf file produced by mptopdf, correctly
contains \Omega.


Try adding

prologues := 2;

or

prologues := 3;

in your mp file.

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] include two pages from typesetbuffer

2013-08-09 Thread Hans Hagen

On 8/9/2013 9:39 PM, Pablo Rodríguez wrote:

On 08/08/2013 10:40 PM, Hans Hagen wrote:

On 8/8/2013 10:15 PM, Hans Hagen wrote:

On 8/8/2013 9:01 PM, Pablo Rodríguez wrote:

Dear list,

I would like to be able to include the first two pages of a typeset
buffer (included with \typesetbuffer[sample][frame=on]).

Is there any way to do this? I’d like to avoid to save the buffer to a
file.


\typesetbuffer[sample][frame=on,page=1]
\typesetbuffer[sample][frame=on,page=2]


as that runs the buffer twice the next beta will provide  this:


Many thanks, Hans, for the new feature.

I can wikify it, if you want me to do it. But I have a question before.

Wouldn’t it be easier that ConTeXt detects when a buffer has already
been typeset and automatically does all the work internally?


actually there was already a test for that but i made a better one, so 
now we have:


\starttext

\enabletrackers[buffers.run]

\startbuffer [sample]
\starttext
\startTEXpage[offset=10pt] one   \stopTEXpage
\startTEXpage[offset=10pt] two   \stopTEXpage
\startTEXpage[offset=10pt] three \stopTEXpage
\stoptext
\stopbuffer

\typesetbuffer[sample][frame=on,page=1]
\typesetbuffer[sample][frame=on,page=2]
\typesetbuffer[sample][frame=on,page=3]

\externalfigure[\lasttypesetbuffer][frame=on,page=2]

\typesetbuffer[*][frame=on,page=3]

\stoptext


-
  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] internal mptopdf converter skips some glyphs in labels

2013-08-09 Thread Hans Hagen

On 8/9/2013 10:26 PM, Sanjoy Mahajan wrote:


With \enabletrackers[graphics.conversion,graphics.inclusion], the log
has the following lines, none of which seem to pinpoint the problem:

   graphics> inclusion > checking conversion of 'testfig.1', fullname 
'testfig.1', old format 'mps', new format 'pdf', conversion 'default', resolution 
'default'
   graphics> inclusion > no converter for 'mps' to 'pdf'
   [MP to PDF]
   graphics> inclusion > checking conversion of 'testfig-1.pdf', 
fullname 'testfig-1.pdf', old format 'pdf', new format 'pdf', conversion 'default', 
resolution 'default'
   graphics> inclusion > no converter for 'pdf' to 'pdf'
   graphics> inclusion > new graphic, using hash 
'testfig-1.pdf->1->crop->unknown->unknown->unknown->'

(Though I don't believe the "no converter for 'mps' to 'pdf'" diagnostic.)


don't worry .. that concerns an additional plugin (one can plug in 
downsamplers and so)



This is with Context 2013.05.28 00:36 MKIV (TL2013 on Debian).


the beta works ok .. are there any messages with respect to missing 
fonts or map files?


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] internal mptopdf converter skips some glyphs in labels

2013-08-09 Thread Sanjoy Mahajan
> Try adding
>  prologues := 2;
> or
>  prologues := 3;
> in your mp file.
>

Good thought, which I tried, though neither setting resolved the
problem.

> Any particular reason that you are compiling metapost files using mp and 
> then including them in ConTeXt rather than directly using any one of the 
> inbuilt ConTeXt environments for handling mp (\startMPcode, \useMPgraphic, 
> \processMPbuffer, etc.)

Mostly conservatism.  I cannot quite figure out the canonical
replacement for btex ... etex (textext, sometext?), and then I get
confused by the many possible environments.

What do you recommend as the best btex...etex replacement and the best
environment for replacing a standalong metapost figure (that I would
otherwise just include with \externalfigure)?

-Sanjoy
___
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] internal mptopdf converter skips some glyphs in labels

2013-08-09 Thread Sanjoy Mahajan
Hans Hagen  writes:

> the beta works ok .. are there any messages with respect to missing 
> fonts or map files?

I got rid of page numbering and added a few more trackers:

\enabletrackers[graphics.conversion,graphics.inclusion,fonts.mapfiles,fonts.loading,fonts.missing,fonts.mapping]
\setuppagenumbering[location=]

The log file didn't look strange (I've included it below).  I also
changed the label to btex $1$ etex (intead of $\Omega$), which works
fine, and diffed the context log files when making test.pdf with the
$\Omega$ figure and the $1$ figure.  The only difference is at line 132,
where the $1$ version loads cmr10.pfb

) )

which makes sense, since "1" is in cmr10, and the conversion of
testfig.1 must have figured out that cmr10 was needed.  But in the
$\Omega$ version, no font file is loaded.  

Probably it should have loaded (and reported  in the log file)
this file:

/usr/local/texlive/2013/texmf-dist/fonts/opentype/public/lm-math/latinmodern-math.otf

Does this help track down the problem in the jungle of map files and paths?

-Sanjoy

(/usr/local/texlive/2013/texmf-dist/tex/context/base/cont-yes.mkiv

ConTeXt  ver: 2013.05.28 00:36 MKIV current  fmt: 2013.8.6  int: english/english

system  > 'cont-new.mkiv' loaded
(/usr/local/texlive/2013/texmf-dist/tex/context/base/cont-new.mkiv)
system  > files > jobname 'test', input './test', result 'test'
fonts   > latin modern fonts are not preloaded
languages   > language 'en' is active
(/home/sanjoy/sfse/test.tex
fonts   > mapfiles > loading map file 'mkiv-base.map'
{/usr/local/texlive/2013/texmf-dist/fonts/map/pdftex/context/mkiv-base.map}
fonts   > preloading latin modern fonts (second stage)
fonts   > typescripts > unknown library 'loc'
fonts   > mapfiles > loading map file 'lm-math.map'
{/usr/local/texlive/2013/texmf-dist/fonts/map/dvips/lm/lm-math.map}
fonts   > mapfiles > loading map file 'lm-rm.map'
{/usr/local/texlive/2013/texmf-dist/fonts/map/dvips/lm/lm-rm.map}
fonts   > defining > memory usage before: 29 MB (ctx: 28 MB)
fonts   > defining > start stage one: Serif sa 1
fonts   > defining > specification 'Serif sa 1', lookup 'file', name 
'Serif', sub '', method '', detail ''
fonts   > defining > stop stage one
fonts   > defining > start stage two: LMRoman-Regular (size 786432)
fonts   > defining > remapping name 'LMRoman-Regular', specification 
'auto', size 786432, designsize 'file:lmroman12-regular'
fonts   > defining > trying (reader sequence driven) type 'otf' for 
'lmroman12-regular' with file ''
fonts   > otf loading > loading from cache using hash 
'lmroman12-regular'
fonts   > otf loading > apply enhancement 'unpack' to file 
'/usr/local/texlive/2013/texmf-dist/fonts/opentype/public/lm/lmroman12-regular.otf'
fonts   > otf loading > apply enhancement 'add dimensions' to file 
'/usr/local/texlive/2013/texmf-dist/fonts/opentype/public/lm/lmroman12-regular.otf'
fonts   > defining > defining tfm, name 'lmroman12-regular', fullname 
'LMRoman12-Regular', filename 
'/usr/local/texlive/2013/texmf-dist/fonts/opentype/public/lm/lmroman12-regular.otf',
 hscale 786.432, vscale 786.432, math 'disabled', italics 'enabled'
fonts   > defining > registering 'lmroman12-regular' as 'otf', used 
'lmroman12-regular.otf'
fonts   > defining > loaded and hashed: lmroman12-regular @ 
normal:curs=true+kern=true+liga=true+mark=true+mkmk=true+mode=auto+script=auto+tlig=true+trep=true
 @ 786432
fonts   > defining > using opentype font with id '', name 
'lmroman12-regular', size 786432, bytes 2, encoding '', fullname 
'LMRoman12-Regular', filename 'lmroman12-regular.otf'
fonts   > defining > registering font, id 1, hash 'lmroman12-regular @ 
normal:curs=true+kern=true+liga=true+mark=true+mkmk=true+mode=auto+script=auto+tlig=true+trep=true
 @ 786432'
fonts   > defining > defining 'lmroman12-regular', id 1, target 
'modern-designsize-12pt-rm-tf-0--0', features '' / 'default', fallbacks '' / ''
fonts   > defining > memory usage after: 30 MB (ctx: 29 MB)
fonts   > defining > stop stage two
fonts   > defining > memory usage before: 30 MB (ctx: 29 MB)
fonts   > defining > start stage one: MathRoman mo 1
fonts   > defining > specification 'MathRoman mo 1', lookup 'file', 
name 'MathRoman', sub '', method '', detail ''
fonts   > defining > stop stage one
fonts   > defining > start stage two: file:latinmodern-math-regular.otf 
(size 458752)
fonts   > otf loading > loading from cache using hash 'latinmodern-math'
fonts   > otf loading > apply enhancement 'unpack' to file 
'/usr/local/texlive/2013/texmf-dist/fonts/opentype/public/lm-math/latinmodern-math.otf'
fonts   > otf loading > apply enhancement 'add dimensions' to file 
'/usr/local/texlive/2013/texmf-dist/fonts/opentype/public/lm-math/latinmodern-

Re: [NTG-context] internal mptopdf converter skips some glyphs in labels

2013-08-09 Thread Aditya Mahajan

On Fri, 9 Aug 2013, Sanjoy Mahajan wrote:


Try adding
 prologues := 2;
or
 prologues := 3;
in your mp file.



Good thought, which I tried, though neither setting resolved the
problem.


Any particular reason that you are compiling metapost files using mp and
then including them in ConTeXt rather than directly using any one of the
inbuilt ConTeXt environments for handling mp (\startMPcode, \useMPgraphic,
\processMPbuffer, etc.)


Mostly conservatism.  I cannot quite figure out the canonical
replacement for btex ... etex (textext, sometext?), and then I get
confused by the many possible environments.

What do you recommend as the best btex...etex replacement


Nothing. Just leave them as it is and MkIV is smart enough to process 
them [^1]. If you used the TEX macros (to build strings with metapost 
variables), use textext("...") instead of TEX("").



and the best
environment for replacing a standalong metapost figure (that I would
otherwise just include with \externalfigure)?


I use the following:

\startcomponent figures

\startbuffer[system-1]
 ... mp code ..
\stopbuffer

% Other figures in separate buffer

\stopcomponent

and then use

\processMPbuffer[list of buffers]

to typeset them [^2]. With this approach you loose some of the features of 
\externalfigure (scaling, backgrounds, etc.) For scaling, you can use


  \scale[]{\processMPbuffer[...]}


and if you really need a background, you can use \framed.

Another option is to use \startMPcode  \stopMPcode environment, but I 
usually like my figures to be separate files.


[^1]: To process btex ... etex, the content of each metapost 
environment is processed twice. This can sometimes lead to unexpected 
results. Basically you have to careful with := vs =, otherwise you'll get 
inconsistent equations.


[^2]: You also need to keep in mind that all metapost graphics are 
processed in a single run (think of a single mp file with multiple 
beginfigs). So you have to be careful with initializing and resetting 
variables (\startMPinclusions, \startMPinitializations, 
\startMPdefinitions, see wiki for difference) or adding bgroup ... egroup 
at appropriate location to limit scope.


Another way to avoid interference is to use separate MPinstances, but in 
my opinion that feature is more useful to module writers than normal 
users.



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] Minor date formatting issue

2013-08-09 Thread Matt Gushee
Hi, Wolfgang--

On Fri, Aug 9, 2013 at 6:58 AM, Wolfgang Schuster
 wrote:

>> I am experimenting with the \currentdate command. I am finding that
>>
>>  \currentdate [weekday,{,~},month,day+,{,~},year]
>>
>> which should work according to the Wiki, produces:
>>
>>  Thursday, Augustday+, 2013

> It’s recommended to use “day:ord” with \currentdate but you also use “day:+”.
>
> \starttext
> \currentdate[day,space,day:ord,space,day:+]
> \stoptext

Ah, yes, thank you!

Perhaps someone should update the wiki? I suppose I could get an
account and fix it myself ... if people don't mind someone as inexpert
as me messing around in there ...

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