From mark_difford at yahoo.co.uk  Fri Oct 17 13:38:43 2008
From: mark_difford at yahoo.co.uk (Mark Difford)
Date: Fri, 17 Oct 2008 04:38:43 -0700 (PDT)
Subject: [Rd] RFC: Kerning, postscript() and pdf()
In-Reply-To: <fab4bcf70810170132v3ed86e8atfb5e81a42cf3b7ce@mail.gmail.com>
References: <alpine.LFD.2.00.0810121544300.6167@gannet.stats.ox.ac.uk>
	<alpine.LFD.2.00.0810161002040.13524@gannet.stats.ox.ac.uk>
	<B37C0A15B8FB3C468B5BC7EBC7DA14CC61589D7B38@LP-EXMBVS10.CO.IHC.COM>
	<fab4bcf70810170132v3ed86e8atfb5e81a42cf3b7ce@mail.gmail.com>
Message-ID: <20031674.post@talk.nabble.com>


.... 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.



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