internal mptopdf converter skips some glyphs in labels
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
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
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
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
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 -----------------------------------------------------------------
Hans Hagen
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
Hans Hagen
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. ==================
On 6/5/2014 4:17 AM, Sanjoy Mahajan wrote:
Hans Hagen
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 -----------------------------------------------------------------
Hans Hagen
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
On 6/5/2014 9:37 PM, Sanjoy Mahajan wrote:
Hans Hagen
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 -----------------------------------------------------------------
Hans Hagen
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
On 6/5/2014 11:27 PM, Sanjoy Mahajan wrote:
Hans Hagen
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 -----------------------------------------------------------------
participants (4)
-
Aditya Mahajan
-
Hans Hagen
-
Sanjoy Mahajan
-
Sanjoy Mahajan