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
_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context
