I am going back to Simone's original query (though this will
split the thread) because subsequent replies did not include
his original. Some comments interspersed below; the main
response at the end.
I have had some private correspondence with Simone, who sent me
two of his files that exhibit the problem, and this has enabled
me to form an idea of where the trouble may lie. It would seem
that either there is something seriously wrong with the function
embedFonts(), or with ghostscript when executing the command
generated by embedFonts(), or with both. I shal descibe the results
of my esperminets, in the hope that some expert in embedFonts(),
or in ghostscript, or in both, can make a useful suggestion.
On 04-Sep-09 14:01:44, Simone Gabbriellini wrote:> Dear list,
> I am trying to make eps file with embedded font.
> I use:
>
> postscript("ranking-exp-all.eps", horizontal=TRUE, onefile=FALSE,
> paper="special", height=8, width=12,
family="Helvetica")
> # plot stuff
> dev.off()
>
> since R does not embed font, I then use:
>
> embedFonts(file="indegdistr.eps",
outfile="indegdistrEMB.eps",
> fontpaths="System/Library/Fonts")
I think Simone intended to use a different filename here, probably
embedFonts(file="ranking-exp-all.eps",
outfile="ranking-exp-all-EMB.eps",
fontpaths="System/Library/Fonts")
in line with his previous command above. This is not important here.
> the problem is that the second file, with font embedded, is cutted
> near the end, and the very last part of the plots and the border are
> off the page...
In fact the bottom of the graphic is slightly clipped when viewed
in ghostview, and the righthand side is severely clipped.
> I use R 2.8.1 on a Mac OSX
> any help more than welcome,
> regards,
> Simone
Ths problem Simone encountered can be reproduced in a simple way
as follows.
postscript(file="test1.eps",family="Times",horizontal=FALSE,
paper="special",width=10,height=5)
plot(c(0,1,2),c(0,1,4),main="Test
Plot",xlab="X",ylab="Y")
dev.off()
If I view this file "test1.eps" in ghostsript (using 'gv', on
Linux),
I see it fine. There is a nice clearance all round (about 24 points
above the "Test Plot" title, about 6 points to the left of the
"Y" y-axis label, about 30 points below the "X" x-axis
label,
and about 30 points to the right of the plot frame.
The BoundingBox line in test1.eps is
%%BoundingBox: 0 0 720 360
so it is indeed 10 inches wide and 5 inches high, as requested.
So far, so good.
Now I do the equivalent of Simone's embedFonts() command:
embedFonts(file="test1.eps",format="pswrite",
outfile="test1-EMB.eps")
and view the result of this in 'gv'. The left, top and bottom of
the plot just fit in (there is a miniscule space left around them),
but the right-hand side of the plot is severely cropped. Instead
of seeing the x-axis out to 2.0, with the right-hand side of the
frame, and a little bit of space, it is truncated around x = 1.75
The BoundingBox in "test1-EMB.eps" is specified in the lines:
%%BoundingBox: 4 18 595 336
%%HiResBoundingBox: 4.600000 18.700000 595.000000 335.300000
so the BBox 0 0 720 360 from test1.eps has been slightly trimmed
on the left, substantially (18 points) from below and (14 points)
from above, and hugely (125 points = 1.74 inches) from the right.
The lesser trimmings on the left, bottom and top can be put down,
perhaps, to ghostscript putting the BoundingBox just outside the
marks on the page; but *not* the bad cropping of the right-hand
side, since marks which ought to be included are way outside it.
Next I tried editing a copy test1B-EMB.eps of test1-EMB.eps, to
change the BoundingBox to what it ought to be (0 0 720,360).
The ghostscript window now encloises the full BoundingBox, but
the righthand part is blank (only what can be seen in test1-EMB.eps
is shown, i.e. up to x = 1.75 approx, with what should be seen
beyond this being totally blank).
It follows that, despite the BoundingBox now being the correct
one (and of course the BBox is a clipping-path for display in gv),
there is additional clipping being done in the PostScript generate
by ghostscript as a result of embedFonts().
Looking into the PostScript in test1-EMB.eps (or test1B-EMB.eps),
there are several occurrenfces of "clip" therein. However, the
additional PostScript generated by ghostscript is very obscure,
and I cannot decipher what is going on.
It next occurred to me that one may be able to add ghostsctript
options to the call to embedFonts(), to try to ensure that it
would respect the original BoundingBox. The command generated by
embedFonts(file="test1.eps",format="pswrite",
outfile="test1-EMB.eps")
is:
gs -dNOPAUSE -dBATCH -q -dAutoRotatePages=/None -sDEVICE=pswrite \
-sOutputFile=/tmp/RtmplPWs8l/Rembed24b931bd -sFONTPATH= test1.eps
A quick study of the ghostscript documentation revealed the existence
of some "EPS Parameters", of which the only one that seemed relevant
was:
-dEPSCrop
Crop an EPS file to the bounding box. This is useful when
converting an EPS file to a bitmap.
Bitmap or no, "cropping to the bounding box" looks like just the
thing to do, provided the "bounding box" in question is the one
which was in the roiginal EPS file. So I now tried
embedFonts(file="test1.eps",format="pswrite",options="-dEPSCrop",
outfile="test1C-EMB.eps")
When viewed in gv, this now show exactly the same as with test1-EMB.eps:
the visible window is cropped on the right at x = 1.75 approx, as before.
And the BoundingBox in test1C-EMB.eps is
%%BoundingBox: 4 18 595 336
%%HiResBoundingBox: 4.600000 18.700000 595.000000 335.300000
exactly as before. So the "-dEPSCrop" option has changed nothing.
The "gs" command generated by the above EmbedFonts() command was
gs -dNOPAUSE -dBATCH -q -dAutoRotatePages=/None -sDEVICE=pswrite \
-sOutputFile=/tmp/RtmplPWs8l/Rembed48a664b0 -sFONTPATH= -dEPSCrop \
test1.eps
so the option was indeed there. Hence I deduce that the "bounding
box" to which "-dEPSCrop" crops the result is not the original
BoundingBox, but the spurious one generate by 'gs' itself when
run under the control of embedFonts().
Finally -- and this strikes me as really bizarre -- I was wondering
if using ghostview to view the result was causing the viewing
problem even when (with the file test1B-EMB.eps) the BoundingBox
had been edited so as to be the correct one.
So I decided to try printing to paper on a printer with built-in
PostScript capability (HP LaserJet 1300).
First, I imported the original test1,eps (pre-embedFonts) into a
PostScript document "testembed.ps" created by groff, with source file
containing
.PSPIC test1.eps 4i
which should produce a rendering of the graphic, centred, and 4 inches
wide. Indeed it does, both when viewed using 'gv', and when printed
to paper.
Next, I additionally the included the result test1-EMB.eps of the very
first invocation of embedFonts(), exactly as output and with no messing
about, so that the groff source file was now:
.PSPIC test1.eps 4i
.sp 2
.PSPIC test1-EMB.eps 4i
which should produce a rendering of test1.eps, centred and 4 inches
wide as before, followed by a double line space, followed by a
similar rendering of test1-EMB.eps 4i centred and four inches wide.
When viewed in 'gv', there is a brief glimpse of test1.eps
followd by an even briefer glimpse of test1-EMB.eps (while the
first is still showing -- you have to be very quick to see these),
and then the whole 'gv' window goes blank.
The glimpse of test1-EMB.eps is on a much larger scale (not 4 inches
wide as it should be) than the glimpse of test1.eps (while it lasts).
And it appears much further down the page than it should.
Finally, printing the resulting PS file to paper produces a blank
sheet -- no marks on it at all.
So something really weird is going on.
As a final comment: comparing the PostScript in test1.eps and
test1-EMB.eps, I see that the entire Prologue (66 lines of PostScript
code between "%%BeginProlog" and "%%EndProlog") present in
test1.eps
has been replaced by 47 lines created by ghostscript which bear no
visible resemblance to the original. So I wonder what has happened
to all the PS definitions planted by R in test1.eps, for use when
it gets down to rendering the graphic.
I've gone into this at length (and sorry for the length), hoping
to evoke comment or analysis (of the results of my R commands above)
from people who know their way round this stuff. I have to confess
that, when it came to trying to work out what was going on in the
"embedded" file test1-EMB.eps, I found myself totally out of my
depth!
With thanks,
Ted.
(And also on behalf of Simone Gabriellini)
--------------------------------------------------------------------
E-Mail: (Ted Harding) <Ted.Harding at manchester.ac.uk>
Fax-to-email: +44 (0)870 094 0861
Date: 06-Sep-09 Time: 20:45:18
------------------------------ XFMail ------------------------------