[R] eps file with embedded font
simone gabbriellini
simone.gabbriellini at gmail.com
Wed Sep 9 11:47:23 CEST 2009
Hi Paul,
I've tried your solutions and it works great... still my eps viewer
(CocoViewX) doesn't visualize them well, but the pdf converter (I use
mac, the Finder does this conversion automagically) visualize all the
images correctly
thank you very much for your help!
simone
Il giorno 09/set/09, alle ore 01:51, Paul Murrell ha scritto:
> Hi
>
> Thanks for the further analysis on this Ted. I think the problem is
> that, with such a "wide" plot, you are running into the default
> paper size. If you look at the EPS produced by ghostscript, you
> will see a line like this ...
>
> 612 792 /letter setpagesize
>
> ... and notice that the value 612 corresponds to the unexpected
> right hand clipping margin. So a possible solution is to specify a
> paper size or, more generally, a device size, that is larger
> (especially wider) than the original plot. Here's an example for
> this particular case ...
>
> embedFonts(file="test1.eps",
> outfile="test1-EMB.eps",
> options="-dDEVICEWIDTHPOINTS=720 -dDEVICEHEIGHTPOINTS=360")
>
> Now, rather than clipping the output to the default paper size, the
> result is clipped to the edges of the plot.
>
> Hope that helps.
>
> Paul
>
> p.s. Another useful tip that helps in these situations is to get
> ghostscript to just calculate a bounding box for your plot. For
> example ...
>
> > gs -dNOPAUSE -dBATCH -q -sDEVICE=bbox test1.eps
> %%BoundingBox: 4 18 691 336
> %%HiResBoundingBox: 4.968000 18.719999 690.134885 335.214341
>
> ... which shows that ghostscript can produce the right bounding box,
> if it ignores the default paper size for output.
>
>
> Ted Harding wrote:
>> 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 ------------------------------
>> ______________________________________________
>> R-help at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
>> and provide commented, minimal, self-contained, reproducible code.
>
> --
> Dr Paul Murrell
> Department of Statistics
> The University of Auckland
> Private Bag 92019
> Auckland
> New Zealand
> 64 9 3737599 x85392
> paul at stat.auckland.ac.nz
> http://www.stat.auckland.ac.nz/~paul/
>
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
Dr. Simone Gabbriellini, PhD
Department of Political and Social Sciences
University of Pisa
http://www.digitaldust.it
simone.gabbriellini at sp.unipi.it
More information about the R-help
mailing list