[R] eps file with embedded font
(Ted Harding)
Ted.Harding at manchester.ac.uk
Wed Sep 9 20:40:58 CEST 2009
Thanks, Paul.
In fact I had been hoping to lure you to the surface, from the
12740-km ocean depths which you inhabit, during our hours of
darkness!
Your suggested modification of the "options" in the embedFonts
command indeed produces an EPS file which displays without clipping.
However, when these files are imported into a PS document using
'groff', the "blanking" problem described at the end of my included
orifginal posting (below) persisted.
So I posted a summary of the problem to the 'groff' mailing-list.
This can be found in the thread
[Groff] EPS importing problem, Ted Harding, 2009/09/09
at
http://lists.gnu.org/archive/html/groff/2009-09/threads.html
There is a reply by Tadziu Hoffmann:
> Attached are two EPS files:
>
> test1.eps
> test1-EMB2.eps
>
[snip]
File "test1-EMB2.eps"[*] contains a call to "setpagedevice"
(through "setpagesize"), which is a bin no-no for EPS files.
Does the problem still occur If you delete the line that says
"720 360 /letter setpagesize"?
[*] which was generated by your modified "embedFonts()"
and, as my reply confirms, commenting-out that line resolved the
problem (though there a minor issue that the BoundingBox is not
what is really wanted, but that can be resolved by editing the
EPS file). I'm not sure where the insertion of the call to
"setpagedevice" arose from, but I think it is down to 'gs'.
There was a much longer private reply from a Robert Herrmann,
which I shall send you privately since it may be of interest,
along with the PS filoe I got after implementing Tadziu Hoffmann.
Meanwhile, those who are interested by the issues arising in this
thread, raised by Simone Gabbriellini, may find the above useful.
Ted.
On 08-Sep-09 23:51:27, Paul Murrell wrote:
> 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.
--------------------------------------------------------------------
E-Mail: (Ted Harding) <Ted.Harding at manchester.ac.uk>
Fax-to-email: +44 (0)870 094 0861
Date: 09-Sep-09 Time: 19:40:47
------------------------------ XFMail ------------------------------
More information about the R-help
mailing list