.... A huge thank you from me, too. Greg has said what should be said. Every day I look at my PS and PDF output, think through the chain of effort involved, from building the blocks to the packages that coordinate them, and say WOW! R graphics just got better, with some fine decision making.
Regards, Mark. Bálint Czúcz-4 wrote: > > 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 > > -- View this message in context: http://www.nabble.com/RFC%3A-Kerning%2C-postscript%28%29-and-pdf%28%29-tp19942727p20031674.html Sent from the R devel mailing list archive at Nabble.com. ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
