I'm seeing inconsistent symbols from the same expression with the following code: expr = expression(sum(x, 1, n)) plot(1, main = expr, type = "n") text(1, 1, expr) Moreover, the inconsistency is reversed in r-devel compared to R 2.0.1. In particular, the main label shows a \bigoplus instead of \sum in r-devel, and the other way round in 2.0.1. demo(plotmath) shows \sum in both. Can anyone confirm? Is this intended behaviour (though I can't see how)? -Deepayan
unexpected behaviour of expression(sum())
10 messages · Brian Ripley, Deepayan Sarkar, Marc Schwartz +1 more
On Thu, 2005-03-10 at 19:57 -0600, Deepayan Sarkar wrote:
I'm seeing inconsistent symbols from the same expression with the following code: expr = expression(sum(x, 1, n)) plot(1, main = expr, type = "n") text(1, 1, expr) Moreover, the inconsistency is reversed in r-devel compared to R 2.0.1. In particular, the main label shows a \bigoplus instead of \sum in r-devel, and the other way round in 2.0.1. demo(plotmath) shows \sum in both. Can anyone confirm? Is this intended behaviour (though I can't see how)?
No problem in "Version 2.0.1 Patched (2005-03-07)". I get \sum in both places. I do not see anything in the NEWS file suggesting a bug fix for this. I just installed "Version 2.1.0 Under development (unstable) (2005-03-11)" and do not see the problem there either. Both are under FC3. HTH, Marc Schwartz
On Thu, 10 Mar 2005, Marc Schwartz wrote:
On Thu, 2005-03-10 at 19:57 -0600, Deepayan Sarkar wrote:
I'm seeing inconsistent symbols from the same expression with the following code: expr = expression(sum(x, 1, n)) plot(1, main = expr, type = "n") text(1, 1, expr) Moreover, the inconsistency is reversed in r-devel compared to R 2.0.1. In particular, the main label shows a \bigoplus instead of \sum in r-devel, and the other way round in 2.0.1. demo(plotmath) shows \sum in both. Can anyone confirm? Is this intended behaviour (though I can't see how)?
No problem in "Version 2.0.1 Patched (2005-03-07)". I get \sum in both places. I do not see anything in the NEWS file suggesting a bug fix for this. I just installed "Version 2.1.0 Under development (unstable) (2005-03-11)" and do not see the problem there either. Both are under FC3.
We need to know both the device and the locale. Assuming this is X11,
there are two fixes for font selection:
o X11() was only scaling its fonts to pointsize if the dpi
was within 0.5 of 100dpi.
o X11() font selection was looking for any symbol font, and
sometimes got e.g. bold italic if the server has such a font.
The main title in plot() and text() are asking for different sizes.
If Deepayan had problems with getting a valid (Adobe symbol-encoded) font,
this might vary by size which would explain the reported differences.
Deepayan: can you please check what symbol fonts you have: the pattern in
R-devel is
"-adobe-symbol-medium-r-*-*-*-*-*-*-*-*-*-*"
(Ideally we would select on encoding, but that is usually 'fontspecific'
so not helpful.)
Brian
Brian D. Ripley, ripley@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595
On Friday 11 March 2005 01:19, Prof Brian Ripley wrote:
On Thu, 10 Mar 2005, Marc Schwartz wrote:
On Thu, 2005-03-10 at 19:57 -0600, Deepayan Sarkar wrote:
I'm seeing inconsistent symbols from the same expression with the following code: expr = expression(sum(x, 1, n)) plot(1, main = expr, type = "n") text(1, 1, expr) Moreover, the inconsistency is reversed in r-devel compared to R 2.0.1. In particular, the main label shows a \bigoplus instead of \sum in r-devel, and the other way round in 2.0.1. demo(plotmath) shows \sum in both. Can anyone confirm? Is this intended behaviour (though I can't see how)?
No problem in "Version 2.0.1 Patched (2005-03-07)". I get \sum in both places. I do not see anything in the NEWS file suggesting a bug fix for this. I just installed "Version 2.1.0 Under development (unstable) (2005-03-11)" and do not see the problem there either. Both are under FC3.
We need to know both the device and the locale. Assuming this is X11, there are two fixes for font selection:
Yes, it's X11, with locale "C". It doesn't happen with postscript (I haven't tried anything else). I had tried on 3 different machines other than my desktop, but all remotely. Marc's reply suggested that this was a problem with X on my local machine, and I haven't yet had a chance to check on any others.
o X11() was only scaling its fonts to pointsize if the dpi
was within 0.5 of 100dpi.
o X11() font selection was looking for any symbol font, and
sometimes got e.g. bold italic if the server has such a font.
The main title in plot() and text() are asking for different sizes.
If Deepayan had problems with getting a valid (Adobe symbol-encoded)
font, this might vary by size which would explain the reported
differences.
Deepayan: can you please check what symbol fonts you have: the
pattern in R-devel is
"-adobe-symbol-medium-r-*-*-*-*-*-*-*-*-*-*"
(Ideally we would select on encoding, but that is usually
'fontspecific' so not helpful.)
I'm not really sure what I'm looking for, but everything I get seems to be 'fontspecific': deepayan $ xlsfonts | grep adobe-symbol-medium -adobe-symbol-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific -adobe-symbol-medium-r-normal--0-0-100-100-p-0-adobe-fontspecific -adobe-symbol-medium-r-normal--0-0-75-75-p-0-adobe-fontspecific -adobe-symbol-medium-r-normal--10-100-75-75-p-61-adobe-fontspecific -adobe-symbol-medium-r-normal--10-100-75-75-p-61-adobe-fontspecific -adobe-symbol-medium-r-normal--11-80-100-100-p-61-adobe-fontspecific -adobe-symbol-medium-r-normal--11-80-100-100-p-61-adobe-fontspecific -adobe-symbol-medium-r-normal--12-120-75-75-p-74-adobe-fontspecific -adobe-symbol-medium-r-normal--12-120-75-75-p-74-adobe-fontspecific -adobe-symbol-medium-r-normal--14-100-100-100-p-85-adobe-fontspecific -adobe-symbol-medium-r-normal--14-100-100-100-p-85-adobe-fontspecific -adobe-symbol-medium-r-normal--14-140-75-75-p-85-adobe-fontspecific -adobe-symbol-medium-r-normal--14-140-75-75-p-85-adobe-fontspecific -adobe-symbol-medium-r-normal--17-120-100-100-p-95-adobe-fontspecific -adobe-symbol-medium-r-normal--17-120-100-100-p-95-adobe-fontspecific -adobe-symbol-medium-r-normal--18-180-75-75-p-107-adobe-fontspecific -adobe-symbol-medium-r-normal--18-180-75-75-p-107-adobe-fontspecific -adobe-symbol-medium-r-normal--20-140-100-100-p-107-adobe-fontspecific -adobe-symbol-medium-r-normal--20-140-100-100-p-107-adobe-fontspecific -adobe-symbol-medium-r-normal--24-240-75-75-p-142-adobe-fontspecific -adobe-symbol-medium-r-normal--24-240-75-75-p-142-adobe-fontspecific -adobe-symbol-medium-r-normal--25-180-100-100-p-142-adobe-fontspecific -adobe-symbol-medium-r-normal--25-180-100-100-p-142-adobe-fontspecific -adobe-symbol-medium-r-normal--34-240-100-100-p-191-adobe-fontspecific -adobe-symbol-medium-r-normal--34-240-100-100-p-191-adobe-fontspecific -adobe-symbol-medium-r-normal--8-80-75-75-p-51-adobe-fontspecific -adobe-symbol-medium-r-normal--8-80-75-75-p-51-adobe-fontspecific deepayan $ -Deepayan
I see you have both a scalable font (the first) and size-specfic fonts. My guess is that the scalable font is not encoded in the same way as the others: can you track down where it is coming from? Otherwise my list on FC3 is the same as yours (minus the duplicates, which are also puzzling). I have also just checked Exceed, which has the same list plus scalable fonts (and also has -adobe-symbol-0-0-normal--0-0-0-0-p-0-adobe-fontspecific -adobe-symbol-0-0-normal--0-0-0-0-p-0-sun-fontspecific -adobe-symbol-0-0-normal--0-0-100-100-p-0-adobe-fontspecific -adobe-symbol-0-0-normal--0-0-100-100-p-0-sun-fontspecific -adobe-symbol-0-0-normal--0-0-75-75-p-0-adobe-fontspecific -adobe-symbol-0-0-normal--0-0-75-75-p-0-sun-fontspecific which caused problems for 2.0.1 with getting bold symbols in some sizes, hence the second bug fix I mentioned). As a wild guess, do you have a font server as well as local fonts? Brian
On Fri, 11 Mar 2005, Deepayan Sarkar wrote:
On Friday 11 March 2005 01:19, Prof Brian Ripley wrote:
On Thu, 10 Mar 2005, Marc Schwartz wrote:
On Thu, 2005-03-10 at 19:57 -0600, Deepayan Sarkar wrote:
I'm seeing inconsistent symbols from the same expression with the following code: expr = expression(sum(x, 1, n)) plot(1, main = expr, type = "n") text(1, 1, expr) Moreover, the inconsistency is reversed in r-devel compared to R 2.0.1. In particular, the main label shows a \bigoplus instead of \sum in r-devel, and the other way round in 2.0.1. demo(plotmath) shows \sum in both. Can anyone confirm? Is this intended behaviour (though I can't see how)?
No problem in "Version 2.0.1 Patched (2005-03-07)". I get \sum in both places. I do not see anything in the NEWS file suggesting a bug fix for this. I just installed "Version 2.1.0 Under development (unstable) (2005-03-11)" and do not see the problem there either. Both are under FC3.
We need to know both the device and the locale. Assuming this is X11, there are two fixes for font selection:
Yes, it's X11, with locale "C". It doesn't happen with postscript (I haven't tried anything else). I had tried on 3 different machines other than my desktop, but all remotely. Marc's reply suggested that this was a problem with X on my local machine, and I haven't yet had a chance to check on any others.
o X11() was only scaling its fonts to pointsize if the dpi
was within 0.5 of 100dpi.
o X11() font selection was looking for any symbol font, and
sometimes got e.g. bold italic if the server has such a font.
The main title in plot() and text() are asking for different sizes.
If Deepayan had problems with getting a valid (Adobe symbol-encoded)
font, this might vary by size which would explain the reported
differences.
Deepayan: can you please check what symbol fonts you have: the
pattern in R-devel is
"-adobe-symbol-medium-r-*-*-*-*-*-*-*-*-*-*"
(Ideally we would select on encoding, but that is usually
'fontspecific' so not helpful.)
I'm not really sure what I'm looking for, but everything I get seems to be 'fontspecific': deepayan $ xlsfonts | grep adobe-symbol-medium -adobe-symbol-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific -adobe-symbol-medium-r-normal--0-0-100-100-p-0-adobe-fontspecific -adobe-symbol-medium-r-normal--0-0-75-75-p-0-adobe-fontspecific -adobe-symbol-medium-r-normal--10-100-75-75-p-61-adobe-fontspecific -adobe-symbol-medium-r-normal--10-100-75-75-p-61-adobe-fontspecific -adobe-symbol-medium-r-normal--11-80-100-100-p-61-adobe-fontspecific -adobe-symbol-medium-r-normal--11-80-100-100-p-61-adobe-fontspecific -adobe-symbol-medium-r-normal--12-120-75-75-p-74-adobe-fontspecific -adobe-symbol-medium-r-normal--12-120-75-75-p-74-adobe-fontspecific -adobe-symbol-medium-r-normal--14-100-100-100-p-85-adobe-fontspecific -adobe-symbol-medium-r-normal--14-100-100-100-p-85-adobe-fontspecific -adobe-symbol-medium-r-normal--14-140-75-75-p-85-adobe-fontspecific -adobe-symbol-medium-r-normal--14-140-75-75-p-85-adobe-fontspecific -adobe-symbol-medium-r-normal--17-120-100-100-p-95-adobe-fontspecific -adobe-symbol-medium-r-normal--17-120-100-100-p-95-adobe-fontspecific -adobe-symbol-medium-r-normal--18-180-75-75-p-107-adobe-fontspecific -adobe-symbol-medium-r-normal--18-180-75-75-p-107-adobe-fontspecific -adobe-symbol-medium-r-normal--20-140-100-100-p-107-adobe-fontspecific -adobe-symbol-medium-r-normal--20-140-100-100-p-107-adobe-fontspecific -adobe-symbol-medium-r-normal--24-240-75-75-p-142-adobe-fontspecific -adobe-symbol-medium-r-normal--24-240-75-75-p-142-adobe-fontspecific -adobe-symbol-medium-r-normal--25-180-100-100-p-142-adobe-fontspecific -adobe-symbol-medium-r-normal--25-180-100-100-p-142-adobe-fontspecific -adobe-symbol-medium-r-normal--34-240-100-100-p-191-adobe-fontspecific -adobe-symbol-medium-r-normal--34-240-100-100-p-191-adobe-fontspecific -adobe-symbol-medium-r-normal--8-80-75-75-p-51-adobe-fontspecific -adobe-symbol-medium-r-normal--8-80-75-75-p-51-adobe-fontspecific deepayan $ -Deepayan
Brian D. Ripley, ripley@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595
On Fri, 2005-03-11 at 17:17 +0000, Prof Brian Ripley wrote:
I see you have both a scalable font (the first) and size-specfic fonts. My guess is that the scalable font is not encoded in the same way as the others: can you track down where it is coming from? Otherwise my list on FC3 is the same as yours (minus the duplicates, which are also puzzling). I have also just checked Exceed, which has the same list plus scalable fonts (and also has -adobe-symbol-0-0-normal--0-0-0-0-p-0-adobe-fontspecific -adobe-symbol-0-0-normal--0-0-0-0-p-0-sun-fontspecific -adobe-symbol-0-0-normal--0-0-100-100-p-0-adobe-fontspecific -adobe-symbol-0-0-normal--0-0-100-100-p-0-sun-fontspecific -adobe-symbol-0-0-normal--0-0-75-75-p-0-adobe-fontspecific -adobe-symbol-0-0-normal--0-0-75-75-p-0-sun-fontspecific which caused problems for 2.0.1 with getting bold symbols in some sizes, hence the second bug fix I mentioned). As a wild guess, do you have a font server as well as local fonts? Brian
FWIW, here is my list: $ xlsfonts | grep adobe-symbol -adobe-symbol-medium-r-normal--10-100-75-75-p-61-adobe-fontspecific -adobe-symbol-medium-r-normal--11-80-100-100-p-61-adobe-fontspecific -adobe-symbol-medium-r-normal--12-120-75-75-p-74-adobe-fontspecific -adobe-symbol-medium-r-normal--14-100-100-100-p-85-adobe-fontspecific -adobe-symbol-medium-r-normal--14-140-75-75-p-85-adobe-fontspecific -adobe-symbol-medium-r-normal--17-120-100-100-p-95-adobe-fontspecific -adobe-symbol-medium-r-normal--18-180-75-75-p-107-adobe-fontspecific -adobe-symbol-medium-r-normal--20-140-100-100-p-107-adobe-fontspecific -adobe-symbol-medium-r-normal--24-240-75-75-p-142-adobe-fontspecific -adobe-symbol-medium-r-normal--25-180-100-100-p-142-adobe-fontspecific -adobe-symbol-medium-r-normal--34-240-100-100-p-191-adobe-fontspecific -adobe-symbol-medium-r-normal--8-80-75-75-p-51-adobe-fontspecific Deepayan, which X server is being used? FC3 (fully updated) is using xorg 6.8.1 if that might make a difference. Marc
1 day later
On Friday 11 March 2005 13:13, Marc Schwartz wrote:
On Fri, 2005-03-11 at 17:17 +0000, Prof Brian Ripley wrote:
I see you have both a scalable font (the first) and size-specfic fonts. My guess is that the scalable font is not encoded in the same way as the others: can you track down where it is coming from? Otherwise my list on FC3 is the same as yours (minus the duplicates, which are also puzzling). I have also just checked Exceed, which has the same list plus scalable fonts (and also has -adobe-symbol-0-0-normal--0-0-0-0-p-0-adobe-fontspecific -adobe-symbol-0-0-normal--0-0-0-0-p-0-sun-fontspecific -adobe-symbol-0-0-normal--0-0-100-100-p-0-adobe-fontspecific -adobe-symbol-0-0-normal--0-0-100-100-p-0-sun-fontspecific -adobe-symbol-0-0-normal--0-0-75-75-p-0-adobe-fontspecific -adobe-symbol-0-0-normal--0-0-75-75-p-0-sun-fontspecific which caused problems for 2.0.1 with getting bold symbols in some sizes, hence the second bug fix I mentioned). As a wild guess, do you have a font server as well as local fonts?
I don't think so. My XF86Config-4 file has the line
FontPath "unix/:7100" # local font server
but I don't see any font server package actually installed, and I get
deepayan $ xfsinfo -server localhost:7100
xfsinfo: unable to open server "localhost:7100"
. I do have fontconfig (and a bunch of fonts all over the place), which
may explain the duplicates.
[...]
Deepayan, which X server is being used? FC3 (fully updated) is using xorg 6.8.1 if that might make a difference.
I'm using Debian testing, the version of X being 4.3.0.dfsg.1-10 (4.3.0 with some modifications). But this is not the issue, since things work fine on another Debian system with the same version of X. It turns out that the problem is with the gsfonts-x11 package. After removing it, I get the correct symbols (with a warning message):
expr = expression(sum(x, 1, n)) plot(1, main = expr, type = "n") text(1, 1, expr)
Warning message: X11 used font size 8 when 9 was requested There's still a bug, but probably not in R. The only external indication I can get that something is wrong is when I compare $ xfd -fn -adobe-symbol-medium-r-normal--20-140-100-100-p-107-adobe-fontspecific and $ xfd -fn -adobe-symbol-medium-r-normal--0-0-100-100-p-107-adobe-fontspecific The second one claims to display -urw-standard symbols l-medium-r-normal--17-120-100-100-p-89-adobe-fontspecific and in fact does *not* have the summation symbol. (Screenshots at http://www.stat.wisc.edu/~deepayan/R/xfd-fixed.png and http://www.stat.wisc.edu/~deepayan/R/xfd-scalable.png ). However, the file /usr/X11R6/lib/X11/fonts/Type1/fonts.dir has the line s050000l.pfb -urw-standard symbols l-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific which suggests that the actual font used is s050000l.pfb, and a font editor shows that it does contain the summation symbol (U+2211). Deepayan
So my guess on scalable fonts was right. I suspect this is a problem in how the X server is using Type1 fonts, specifically in how it thinks they are encoded. This is why I asked about the locale: \summation is \345 in the Adobe symbol character set and \circleplus is \305 which is a u/case to l/case difference in Latin-1. I now recall Kurt had similar problems with gsfonts-x11 last August:
Kurt has found a problem with the last two pages of demo(plotmath) on X11 (some symbols either wrong or missing completely).
We found
the issue seems to be that gsfonts-x11 has aliases -adobe-symbol-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
"-urw-standard symbols l-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific"
"-urw-standard symbols l-regular-r-normal--0-0-0-0-p-0-adobe-fontspecific" "-
urw-standard symbols l-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific"
Any way to ensure that these fonts are not taken by us?
I don't think so, for if I understand that the alias file is lying about encodings. We specifically added "-adobe-symbol" to overcome problems with abi symbol fonts at ETHZ, but if that package says the urw fonts in `standard symbols l' are in adobe symbol and they are not, you are in trouble.
Brian
On Sat, 12 Mar 2005, Deepayan Sarkar wrote:
On Friday 11 March 2005 13:13, Marc Schwartz wrote:
On Fri, 2005-03-11 at 17:17 +0000, Prof Brian Ripley wrote:
I see you have both a scalable font (the first) and size-specfic fonts. My guess is that the scalable font is not encoded in the same way as the others: can you track down where it is coming from? Otherwise my list on FC3 is the same as yours (minus the duplicates, which are also puzzling). I have also just checked Exceed, which has the same list plus scalable fonts (and also has -adobe-symbol-0-0-normal--0-0-0-0-p-0-adobe-fontspecific -adobe-symbol-0-0-normal--0-0-0-0-p-0-sun-fontspecific -adobe-symbol-0-0-normal--0-0-100-100-p-0-adobe-fontspecific -adobe-symbol-0-0-normal--0-0-100-100-p-0-sun-fontspecific -adobe-symbol-0-0-normal--0-0-75-75-p-0-adobe-fontspecific -adobe-symbol-0-0-normal--0-0-75-75-p-0-sun-fontspecific which caused problems for 2.0.1 with getting bold symbols in some sizes, hence the second bug fix I mentioned). As a wild guess, do you have a font server as well as local fonts?
I don't think so. My XF86Config-4 file has the line
FontPath "unix/:7100" # local font server
but I don't see any font server package actually installed, and I get
deepayan $ xfsinfo -server localhost:7100
xfsinfo: unable to open server "localhost:7100"
. I do have fontconfig (and a bunch of fonts all over the place), which
may explain the duplicates.
[...]
Deepayan, which X server is being used? FC3 (fully updated) is using xorg 6.8.1 if that might make a difference.
I'm using Debian testing, the version of X being 4.3.0.dfsg.1-10 (4.3.0 with some modifications). But this is not the issue, since things work fine on another Debian system with the same version of X. It turns out that the problem is with the gsfonts-x11 package. After removing it, I get the correct symbols (with a warning message):
expr = expression(sum(x, 1, n)) plot(1, main = expr, type = "n") text(1, 1, expr)
Warning message: X11 used font size 8 when 9 was requested There's still a bug, but probably not in R. The only external indication I can get that something is wrong is when I compare $ xfd -fn -adobe-symbol-medium-r-normal--20-140-100-100-p-107-adobe-fontspecific and $ xfd -fn -adobe-symbol-medium-r-normal--0-0-100-100-p-107-adobe-fontspecific The second one claims to display -urw-standard symbols l-medium-r-normal--17-120-100-100-p-89-adobe-fontspecific and in fact does *not* have the summation symbol. (Screenshots at http://www.stat.wisc.edu/~deepayan/R/xfd-fixed.png and http://www.stat.wisc.edu/~deepayan/R/xfd-scalable.png ). However, the file /usr/X11R6/lib/X11/fonts/Type1/fonts.dir has the line s050000l.pfb -urw-standard symbols l-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific which suggests that the actual font used is s050000l.pfb, and a font editor shows that it does contain the summation symbol (U+2211). Deepayan
Brian D. Ripley, ripley@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595
Prof Brian Ripley <ripley@stats.ox.ac.uk> writes:
So my guess on scalable fonts was right. I suspect this is a problem in how the X server is using Type1 fonts, specifically in how it thinks they are encoded. This is why I asked about the locale: \summation is \345 in the Adobe symbol character set and \circleplus is \305 which is a u/case to l/case difference in Latin-1.
Well, the X server is defenseless against people aliasing fonts with incompatible encodings...
I now recall Kurt had similar problems with gsfonts-x11 last August:
Kurt has found a problem with the last two pages of demo(plotmath) on X11 (some symbols either wrong or missing completely).
We found
the issue seems to be that gsfonts-x11 has aliases -adobe-symbol-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
"-urw-standard symbols l-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific"
"-urw-standard symbols l-regular-r-normal--0-0-0-0-p-0-adobe-fontspecific" "-
urw-standard symbols l-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific"
Any way to ensure that these fonts are not taken by us?
I don't think so, for if I understand that the alias file is lying about encodings. We specifically added "-adobe-symbol" to overcome problems with abi symbol fonts at ETHZ, but if that package says the urw fonts in `standard symbols l' are in adobe symbol and they are not, you are in trouble.
...as previously noted, it seems (who are you citing there?). I vaguely recall some messup with the GS fonts on Fedora 3 (making xpdf misbehave on slides) but it seems to have been resolved long ago.
O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907
On Sun, 13 Mar 2005, Peter Dalgaard wrote:
Prof Brian Ripley <ripley@stats.ox.ac.uk> writes:
So my guess on scalable fonts was right. I suspect this is a problem in how the X server is using Type1 fonts, specifically in how it thinks they are encoded. This is why I asked about the locale: \summation is \345 in the Adobe symbol character set and \circleplus is \305 which is a u/case to l/case difference in Latin-1.
Well, the X server is defenseless against people aliasing fonts with incompatible encodings...
That's still surmise.
I now recall Kurt had similar problems with gsfonts-x11 last August:
Kurt has found a problem with the last two pages of demo(plotmath) on X11 (some symbols either wrong or missing completely).
We found
the issue seems to be that gsfonts-x11 has aliases -adobe-symbol-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
"-urw-standard symbols l-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific"
"-urw-standard symbols l-regular-r-normal--0-0-0-0-p-0-adobe-fontspecific" "-
urw-standard symbols l-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific"
Any way to ensure that these fonts are not taken by us?
I don't think so, for if I understand that the alias file is lying about encodings. We specifically added "-adobe-symbol" to overcome problems with abi symbol fonts at ETHZ, but if that package says the urw fonts in `standard symbols l' are in adobe symbol and they are not, you are in trouble.
...as previously noted, it seems (who are you citing there?).
Kurt and myself (where uncredited).
Brian D. Ripley, ripley@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595