[R] eps file with embedded font
Paul Murrell
p.murrell at auckland.ac.nz
Fri Sep 11 06:09:25 CEST 2009
Hi
My suggested code had dropped the ...
format="epswrite"
... and if you put that back, then the /setpagesize command is removed.
Does that improve things in your test cases?
Paul
Ted Harding wrote:
> 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 ------------------------------
--
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/
More information about the R-help
mailing list