Dear Prof Ripley, FWIW, kerning problems seem to affect even European character sets, e.g.:
> pdf(); plot(0,main="árvíztűrő tükörfúrógép"); dev.off() in a clean session produces some misaligned characters in the resulting Rplots.pdf. [--> note the misplacements after the characters ő and ű (Hungarian long umlaut): intToUtf8(c(337L,369L)) ] Otherwise I completely concur with Greg Snow, huge Thank You for keeping on improving the marvellous capabilities of R! Best regrads, Bálint -- > sessionInfo() R version 2.6.2 (2008-02-08) i386-pc-mingw32 locale: LC_COLLATE=Hungarian_Hungary.1250;LC_CTYPE=Hungarian_Hungary.1250;LC_MONETARY=Hungarian_Hungary.1250;LC_NUMERIC=C;LC_TIME=Hungarian_Hungary.1250 attached base packages: [1] stats graphics grDevices utils datasets methods base [* sorry for not using the most recent R version, I hope this is still helpful -- otherwise please ignore my comment...] -- Bálint Czúcz Institute of Ecology and Botany of the Hungarian Academy of Sciences H-2163 Vácrátót, Alkotmány u. 2-4. HUNGARY Tel: +36 28 360122/157 +36 70 7034692 On Thu, Oct 16, 2008 at 5:56 PM, Greg Snow <[EMAIL PROTECTED]> wrote: > Prof. Ripley, > > I am sure I speak for many others when I say Thank You for this and all the > other great work that you do. R is already capable of producing high quality > graphics, this will just make them better. Kerning is one of those things > that generally don't get noticed unless done wrong/poorly, so I expect in the > future people will look at their graphs and know that they look great, but > not understand why, or the work that you put into giving them that extra > quality. So I just wanted to take this chance to say thank you (I/we > probably don't say it enough). > > Also Thank You to the rest of R core for all the great work. > > R: Come for the price, Stay for the Quality > > -- > Gregory (Greg) L. Snow Ph.D. > Statistical Data Center > Intermountain Healthcare > [EMAIL PROTECTED] > 801.408.8111 > > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >> project.org] On Behalf Of Prof Brian Ripley >> Sent: Thursday, October 16, 2008 3:03 AM >> To: R-devel@r-project.org >> Subject: Re: [Rd] RFC: Kerning, postscript() and pdf() >> >> I've now implemented B and C in R-devel, with C as the default. >> >> On Sun, 12 Oct 2008, Prof Brian Ripley wrote: >> >> > Ei-ji Nakama has pointed out (from another Japanese user, I believe) >> that >> > postscript() and pdf() have not been handling kerning correctly, and >> this is >> > a request for opinions about how we should correct it. >> > >> > Kerning is the adjustment of the spacing between letters from their >> natural >> > width, so that for example 'Yo' is usually typeset with the o closer >> to the Y >> > than 'Yl' would be. Kerning is not very well standardized, so that >> for >> > example R's default Helvetica and its URW clone (Nimbus Sans) have >> quite >> > different ideas of the amount of kerning corrections for 'Yo'. This >> matters, >> > because not many people actually see Helvetica when viewing R's >> PostScript or >> > PDF output, but rather a similar face like Nimbus Sans or Arial, or >> in the >> > case of Acrobat Reader, a not very similar face. Kerning is only a >> feature >> > of some proportionally spaced fonts and so not of Courier nor CJK >> fonts. >> > >> > The current position (R <= 2.8.0) is that string widths have been >> computing >> > using kerning from the Adobe Font Metric files for the nominal font, >> but the >> > strings have been displayed without using kerning (at least in the >> viewers we >> > are aware of, and the PostScript and PDF reference manuals mandate >> that >> > behaviour, if rather obscurely). This means that in strings such as >> 'You', >> > the width used in the string placement differs from that actually >> displayed. >> > >> > For postscript(), this doesn't have much impact, as centring or right >> > justification ('hadj' in text()) is done by PostScript code and >> computes the >> > width from the actual font used (and so copes well with font >> substitution). >> > It might affect the fine layout in plotmath, but using strings which >> would be >> > kerned in annotations is not common. >> > >> > For pdf() the effect is more commonly seen, as all text is set >> > left-justified, and the computed width is used to centre/right- >> justify. >> > >> > There are several things we could do: >> > >> > A. Do nothing, for back compatibility. After all, this has been >> going on >> > for years and no one has complained until last month. >> > >> > B. Ignore kerning, and hence change the string width computations to >> match >> > the current display. This is more attractive than it appears at >> first sight >> > -- as far as I know all other devices ignore kerning, and we are >> increasingly >> > used to seeing 'typeset' output without kerning. It would be >> desirable when >> > copying graphs by e.g. dev.copy2eps from devices that do not kern. >> > >> > C. Insert kerning corrections by splitting up strings, so e.g. 'You' >> is set >> > as (Y)-140 kc(ou): this is what TeX engines do. >> > >> > D. Compute the position of each letter in the string and place them >> > individually. >> > >> > C and D would give visually identical output when the font used is >> exactly as >> > specified, and hopefully also when a substitute font is using with >> the same >> > glyph widths (as substituting Nimbus Sans for Helvetica, at least for >> some >> > versions of each), but where the substitute is a poor match, C ought >> to look >> > more elegant but line up less well. D would produce much larger >> files than >> > C. >> > >> > We do have the option of not changing the output when there is no >> kerning. >> > That would be by far the most common case except that some fonts >> (including >> > Helvetica but not Nimbus Sans) kern between punctuation and a space, >> e.g. ', >> > '. I'm inclined to believe that most uses of ',' in R graphical >> output are >> > not punctuation (certainly true of R's own examples), and also that >> we >> > nowadays do not expect to see kerning involving spaces. >> > >> > Ei-ji Nakama provided an implementation of C for pdf() and D for >> postscript() >> > (thanks Ei-ji, and apologies that we did not have a chance to discuss >> the >> > principles first). I'm inclined to suggest that we should go >> forwards with >> > at most two of these alternatives, and those two should be the same >> for >> > postscript() and pdf() -- my own inclination is to B and C. >> > >> > So questions: >> > >> > 1) Do people feel strongly that we should preserve graphical output >> from past >> > versions of R, even when there are known bugs? I can see the need to >> > reproduce published figures, but normally this would also need using >> the same >> > version of R. >> > >> > 2) Is kerning worth pursuing? >> > >> > 3) If so, is elegant looking output more important than exact layout? >> > >> > 4) If we allow kerning, should it be the default (or only) option? >> > >> > To see that sometimes there can be a large effect, try in >> postscript() or >> > pdf() >> > >> > xx <- 'You You You You You You You You' >> > plot(0,0,xlim=c(0,1),ylim=c(0,1),type='n') >> > abline(v=0) >> > text(0, 0.5, xx, adj=0) >> > abline(v=strwidth(xx)) >> > x2 <- strsplit(xx, "") >> > w <- sapply(x2, strwidth) >> > abline(v=sum(w)) >> > >> > The leftmost of the right pair of lines is the computed width, the >> rightmost >> > the (normal) displayed width. >> > >> > Unless there are cogent reasons to bring this forward to 2.8.1, any >> changes >> > would be as from 2.9.0. >> > >> > Brian Ripley >> > >> > -- >> > Brian D. Ripley, [EMAIL PROTECTED] >> > 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 >> > >> >> -- >> Brian D. Ripley, [EMAIL PROTECTED] >> 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 >> >> ______________________________________________ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
