Re: [NTG-context] internal mptopdf converter skips some glyphs in labels
On 6/5/2014 4:17 AM, Sanjoy Mahajan wrote: Hans Hagen pra...@wxs.nl writes: 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? FYI, with recent betas (2014.05.17 from a context standalone or 2014.05.21 from Debian TL2014), I still find the problem with the internal mptopdf converter dropping glyphs. I work around it in the Makefile (convert using mptopdf externally). However, in case it is worth tracking down, here is the original report with the minimal example. you see the message: LuaTeX warning (file cmr10): Font cmr10 at 3000 not found so you need to load a map file that matches the used fonts: \loadmapfile[mkiv-base] == The internal mptopdf converter in MkIV omits 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. == -- - 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
Hans Hagen pra...@wxs.nl writes: you see the message: LuaTeX warning (file cmr10): Font cmr10 at 3000 not found You are right, though I had unwisely ignored it (weak excuse below). so you need to load a map file that matches the used fonts: \loadmapfile[mkiv-base] That does fix it, thanks. The warning message, which is helpful, seems to happen only with a relatively recent LuaTeX. In my earlier tests, with 0.78, there wasn't a message, and also with the luatex in Debian's TL2014 there isn't one (which is why I ignored it). Debian's TL has luatex beta-0.79.1 (TeX Live 2014/Debian) (rev 4971) The version in the context standalone is just a bit later: beta-0.79.1 (TeX Live 2014/dev) (rev 4972) Hard to believe that one svn revision makes all the difference, but maybe it does. -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
On 6/5/2014 9:37 PM, Sanjoy Mahajan wrote: Hans Hagen pra...@wxs.nl writes: you see the message: LuaTeX warning (file cmr10): Font cmr10 at 3000 not found You are right, though I had unwisely ignored it (weak excuse below). so you need to load a map file that matches the used fonts: \loadmapfile[mkiv-base] That does fix it, thanks. The warning message, which is helpful, seems to happen only with a relatively recent LuaTeX. In my earlier tests, with 0.78, there wasn't a message, and also with the luatex in Debian's TL2014 there isn't one (which is why I ignored it). Debian's TL has luatex beta-0.79.1 (TeX Live 2014/Debian) (rev 4971) The version in the context standalone is just a bit later: beta-0.79.1 (TeX Live 2014/dev) (rev 4972) Hard to believe that one svn revision makes all the difference, but maybe it does. I've added a --mapfiles option to mtxrun --script metapost (the more modern replacement for mptopdf) and default to some base map files. Will be in next beta. In context itself (when embedding such graphics) one still need to include those map files. However, when using mp graphics in context, it makes much more sense to define them runtime. Alternatively, you can consider making your mp graphics like this: \startMPpage some code \stopMPpage This will use the regular font system, gives access to everything context as well, and makes it possible to opentype fonts. The resulting (cropped) graphic can of course be included. One can also have more of them: \starttext \startMPpage some code \stopMPpage \startMPpage some code \stopMPpage \stoptext and include the pages selectively. 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
Hans Hagen pra...@wxs.nl writes: Alternatively, you can consider making your mp graphics like this: \startMPpage some code \stopMPpage This will use the regular font system, gives access to everything context as well, and makes it possible to opentype fonts. The resulting (cropped) graphic can of course be included. One can also have more of them: That's an improvement on what I am doing. (Though I may be getting lots of ConTeXt and OpenType fonts, by using a preamble with verbatimtex %cont-en ... etex ) Right now my figure source (blah.mpfig, say) is what would go in between begin/endfig. The Makefile wraps it in begin/endfig, and includes a header.mp with all the definitions hopefully consistent with the main document's environment (terrible, I know), writes out blah.mp, which is run through metapost and mptopdf. The disadvantage of incorparating everything into the .tex may be the edit--compile cycle gets much longer for the figures, because you have to compile the whole document or component to see the revised figure. (My rule of thumb is that typing is about 10 times faster than handwriting, unless one has to do equations, in which case you lose a factor of 3; or if you have to make figures, in which case you lose the other factor of 3 (3^2=10), and maybe more.) -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
On 6/5/2014 11:27 PM, Sanjoy Mahajan wrote: Hans Hagen pra...@wxs.nl writes: Alternatively, you can consider making your mp graphics like this: \startMPpage some code \stopMPpage This will use the regular font system, gives access to everything context as well, and makes it possible to opentype fonts. The resulting (cropped) graphic can of course be included. One can also have more of them: That's an improvement on what I am doing. (Though I may be getting lots of ConTeXt and OpenType fonts, by using a preamble with verbatimtex %cont-en ... etex ) I must admit that I never use verbatimtex (nor btex/etex). Right now my figure source (blah.mpfig, say) is what would go in between begin/endfig. The Makefile wraps it in begin/endfig, and includes a header.mp with all the definitions hopefully consistent with the main document's environment (terrible, I know), writes out blah.mp, which is run through metapost and mptopdf. Including environments and styles is easier when you run the mp graphic as context file. Just \environment ... will do. The disadvantage of incorparating everything into the .tex may be the edit--compile cycle gets much longer for the figures, because you have to compile the whole document or component to see the revised figure. (My rule of thumb is that typing is about 10 times faster than handwriting, unless one has to do equations, in which case you lose a factor of 3; or if you have to make figures, in which case you lose the other factor of 3 (3^2=10), and maybe more.) That is only true if you can produce content at high speed -) Otherwise the ratio typing - thinking - making up text etc is not that good. Are you sure' it's 'much' longer? You can still put graphics in external files, or use \useMPgraphic etc ... Running mp in context (luatex) is pretty fast (esp when your viewer refreshes fast too). And when at some point you want to use the new lua extension in mp you can only run it that way. 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
Hans Hagen pra...@wxs.nl writes: 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? FYI, with recent betas (2014.05.17 from a context standalone or 2014.05.21 from Debian TL2014), I still find the problem with the internal mptopdf converter dropping glyphs. I work around it in the Makefile (convert using mptopdf externally). However, in case it is worth tracking down, here is the original report with the minimal example. == The internal mptopdf converter in MkIV omits 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. == ___ 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
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] internal mptopdf converter skips some glyphs in labels
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
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
Hans Hagen pra...@wxs.nl 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
) )/usr/local/texlive/2013/texmf-dist/fonts/type1/public/amsfonts/cm/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 blah.otf 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'
fontslatin modern fonts are not preloaded
languageslanguage 'en' is active
(/home/sanjoy/sfse/test.tex
fontsmapfiles loading map file 'mkiv-base.map'
{/usr/local/texlive/2013/texmf-dist/fonts/map/pdftex/context/mkiv-base.map}
fontspreloading latin modern fonts (second stage)
fontstypescripts unknown library 'loc'
fontsmapfiles loading map file 'lm-math.map'
{/usr/local/texlive/2013/texmf-dist/fonts/map/dvips/lm/lm-math.map}
fontsmapfiles loading map file 'lm-rm.map'
{/usr/local/texlive/2013/texmf-dist/fonts/map/dvips/lm/lm-rm.map}
fontsdefining memory usage before: 29 MB (ctx: 28 MB)
fontsdefining start stage one: Serif sa 1
fontsdefining specification 'Serif sa 1', lookup 'file', name
'Serif', sub '', method '', detail ''
fontsdefining stop stage one
fontsdefining start stage two: LMRoman-Regular (size 786432)
fontsdefining remapping name 'LMRoman-Regular', specification
'auto', size 786432, designsize 'file:lmroman12-regular'
fontsdefining trying (reader sequence driven) type 'otf' for
'lmroman12-regular' with file ''
fontsotf loading loading from cache using hash
'lmroman12-regular'
fontsotf loading apply enhancement 'unpack' to file
'/usr/local/texlive/2013/texmf-dist/fonts/opentype/public/lm/lmroman12-regular.otf'
fontsotf loading apply enhancement 'add dimensions' to file
'/usr/local/texlive/2013/texmf-dist/fonts/opentype/public/lm/lmroman12-regular.otf'
fontsdefining 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'
fontsdefining registering 'lmroman12-regular' as 'otf', used
'lmroman12-regular.otf'
fontsdefining 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
fontsdefining using opentype font with id '', name
'lmroman12-regular', size 786432, bytes 2, encoding '', fullname
'LMRoman12-Regular', filename 'lmroman12-regular.otf'
fontsdefining 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'
fontsdefining defining 'lmroman12-regular', id 1, target
'modern-designsize-12pt-rm-tf-0--0', features '' / 'default', fallbacks '' / ''
fontsdefining memory usage after: 30 MB (ctx: 29 MB)
fontsdefining stop stage two
fontsdefining memory usage before: 30 MB (ctx: 29 MB)
fontsdefining start stage one: MathRoman mo 1
fontsdefining specification 'MathRoman mo 1', lookup 'file',
name 'MathRoman', sub '', method '', detail ''
fontsdefining stop stage one
fontsdefining start stage two: file:latinmodern-math-regular.otf
(size 458752)
fontsotf loading loading from cache using hash 'latinmodern-math'
fontsotf loading apply enhancement 'unpack' to file
'/usr/local/texlive/2013/texmf-dist/fonts/opentype/public/lm-math/latinmodern-math.otf'
fontsotf loading apply enhancement 'add dimensions' to file
Re: [NTG-context] internal mptopdf converter skips some glyphs in labels
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
___
