Mojca Miklavec wrote:
Now, is there any way to force the fonts to map on to the old CMR names?
There is (I guess that it might be enough to include the old map files for cmr and to remove all \definefontsynonym [cmr12][lmr10]-like definitions from type-*), but you don't want to do that!
also, these cmr mapping will disappear some day
LatinModern is considered standard today. It has far more glyphs than cmr. OK, you cannot use them all with a single encoding anyway, but you don't have to bother about anything either.
Support for LatinModern math has been added recently, so it might be that there are some bugs, but if there are bugs, it means that they have to be resolved before others have the same problems.
With direct conversion to PDF (so, without the --dvi switch), your problems seem to disappear.
That is because I feel it is because of the CMR/lmodern issue that pdflatex generated PDFs appear properly, while ConTeXt ones don't. What should the map file look like?
What do you get if you use \usepackage{lmodern} with LaTeX?
The problem is related to inclusion of other documents, which is done differently in pdftex and dvips; if you embed for instance 20 images that have cmr included, you can end up with 20 instances of all cm fonts used in them; therefore, remapping the cm to lm in the map files, will give you smaller files; such things are a side effect of CMR10 now being LatinModern.... and that name is used by pdftex to resolve such isssues. However, as Taco pointed out, dvips looks at the filename (cmr10, lmr10) and so does it differently. The solution is to have two map files, one for dvips and one for pdftex. I would not be surprised if packages other than context rely on the shared map file, and then -as said- one ends up with multiple instances. Because context is mostly used with pdftex, that program's way of dealing with things (inclusions) takes preference. Of course we can provide a special map file for dvips (i have no time to look into that myself). Such a file should then be part of the context distribution because in regular tex distributions pdftex map files and dvips mapfiles are 'by definition' to be the same (no matter what arguments one can come up with that contradict that). One of the reasons that context load map files on demand (apart from speed issues, most noticably a few years ago) is to have some kind of control and not depend on some rather wildcard behaviour. Keep in mind that dvips, pdftex, dvipdfmx don't share map file code, and will never do that I fear.
Thanks for bearing with me. I want to try my best before giving up, failing which I will be forced to return to teTeX (with the old ConTeXt) and miss out on some new ConTeXt niceties, such as \startalign etc.
eventually you will have to switch -) an option is to have a local map file and load that in cont-sys.tex but then dvips may work ok, while pdftex might behave less.
The bug has to be resolved, but why not converting your EPS graphics into PDF and using pdfTeX (in pdf mode) instead? There should be an "epstopdf" script present in the TeX distribution among other "binaries".
makes sense Hans