Re: [Rd] RFC: Kerning, postscript() and pdf()

From: Mark Difford <mark_difford_at_yahoo.co.uk>
Date: Fri, 17 Oct 2008 04:38:43 -0700 (PDT)

.... 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 <Greg.Snow_at_imail.org> 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
>> greg.snow_at_imail.org
>> 801.408.8111
>>
>>
>>> -----Original Message-----
>>> From: r-devel-bounces_at_r-project.org [mailto:r-devel-bounces_at_r-
>>> project.org] On Behalf Of Prof Brian Ripley
>>> Sent: Thursday, October 16, 2008 3:03 AM
>>> To: R-devel_at_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,                  ripley_at_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
>>> >
>>>
>>> --
>>> Brian D. Ripley,                  ripley_at_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
>>>
>>> ______________________________________________
>>> R-devel_at_r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>> ______________________________________________
>> R-devel_at_r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>

> ______________________________________________
> R-devel_at_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_at_r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Received on Fri 17 Oct 2008 - 15:27:17 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Sat 18 Oct 2008 - 16:30:22 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.

list of date sections of archive