I have completed some work which allows fairly complete use of Computer
Modern fonts in R.
First, I have a quick bug fix to devPS.c: If an afm file could not be
loaded, R gives a "cannot read afm file" which should be followed by the
name of the file, but instead it is followed by garbage. Here is a patch
to devPS.c that fixes it:
1150c1150
< warning("cannot read afm file %s", buf);
---
warning("cannot read afm file %s", p);
1156c1156
< warning("cannot read afm file %s", buf);
---
warning("cannot read afm file sy______.afm");
my system is: platform i686-pc-linux-gnu arch i686 os linux-gnu system i686, linux-gnu status major 1 minor 3.0 year 2001 month 06 day 22 language R I think there may be similar problems with the error messages of the xfig and pdf drivers, but I have not tried to understand them. Before I send the pathches which allow use of CM fonts, I would like to see whether there is interest in them or whether the changes I made would be considered unacceptable. These changes allow CM fonts in straight postscript output only. The basic idea is: 1) Extend the family option in the postscript driver to take a list of five afm files instead of four. The fifth is for the symbol afm file. The code changes for this are fairly clear. 2) Manipulate the CM fonts in the postscript file, merging them into new fonts which are encoded with ISOLatin1 or Symbol encoding. This I currently implemented by adding two new global variables like .ps.prolog. One adds additional comments to the postscript file to allow the user to request more resources in the postscript file, the second allows the user to add commands to manipulate the fonts. When the second variable is used, the default font reencoding is not used. This is not very elegant and it leaves a lot up to the user, but the CM fonts are really a special case and perhaps a function could be provided which sets up the system for the CM fonts. The advantage is that this requires very few changes to the original code. 3) Construct new afm files for the CM fonts which reflect the merged state of the fonts that exist in the postscript file. I have done this, and although it is not great to have to distribute customized afms, it is simple to use now that it is done. Currently I have this all working, although part (1) breaks old code that doesn't specify a fifth afm file. This could of course be fixed by making symbol added on if only four afms are given. Also changes reqired for (1) may or may not break the other postscript related drivers. What do you think? If you are interested, what is the best way for me to package it up to submit it? Although the patches are small, the modified afms are somewhat bulky to paste into email, but I have no experience with cvs. Would an attached tarball of stuff be OK? Thank you, Brian D'Urso -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._