I have written my PhD thesis and would now like to submit it to a print shop. The thesis relies heavily on ROOT figures in PDF format produced with ROOT 6.12.
The problem I am facing is that the print shop won’t accept the PDF version of my thesis because some fonts are not embedded. After researching for 4h in the middle of the night I figured that some greek symbols (epsilon, mu, chi) but also exponents (-1, -2), tildes, and superscripts are implemented by ROOT as objects rather than as text (I come to this conclusion because I the item, though it appears as text object in Acrobad, cannot be accessed - I cannot change the text within the text object). This entails, trying to run [1] does not help because the font of the object cannot be embedded.
This issue I am facing at 291 occurrences on my thesis.
As an example, below you can find the output of pdffonts for a given plot that contains an #epsilon symbol placed by ROOT6.
name type encoding emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
DZILZG+Helvetica-Oblique Type 1C WinAnsi yes yes no 14 0
CFANWS+Helvetica Type 1C WinAnsi yes yes no 11 0
Symbol Type 1 Custom no no no 13 0
Is there any way this symbol can be placed as a text (including embedding the font) into the PDF?
As the post you are referring too says, there is no such option in ROOT. I am surprised your print should is not happy with ROOT PDF files containing #epsilon. There is 1000th of publications done with ROOT pictures inside, and we have not receive such complain until now. I guess you may find some tools (see the post you referred too) doing this embedding afterwards.
ROOT does not embed fonts. This has been raised as an issue many times, but as far as I know, it will not be changed.
What you can do to fix your problem is open your plots with Inkspace and re-save them by choosing to embed fonts. You must ensure that you have the corresponding Adobe and TeX-Gyre fonts (install depends on your distribution, Xorg should have them) and then it should all work. You can also use some command line tools to do that in bulk, but I cannot guarantee your success there.
Given that there are 291 occurrences of such missing embeddings, I wasn’t really in favor of placing them by hand (i.e. opening Acrobad, placing a new symbol over the old one and deleting the old one). Maybe the inkspace solution would be more automatic since the entire file is saved and with it all occurrences, then I would only need to open 30 or so figures and hope it works.
Actually, for this round the print shop offered me to place the symbols by themselves for 10EUR. Either they have some automatic tools or an elaborate money making scheme… Desperately enough I paid it yesterday, though will try the inkspace way in the next days (need to get inkspace first).
May be generating the PS file using TMathTex via TLatex as shown here: https://root.cern/doc/master/classTLatex.html#L14
And then using the linux “convert” command to make PDF might be an other solution ?
@heico,
back some years ago the debian mailinglist suggested me to use ghostscript gs -o repaired.pdf -dPDFSETTINGS=/prepress -sDEVICE=pdfwrite broken.pdf
Not sure what this will do if you run it on the entire thesis (hyperrefs, pdf table of contents, …) but in a shell script over all individual plot pdfs, that might do the job.
Sorry for the late reply and thank you for the additional suggestions.
However, I actually already have tried the ghostscript command and it replaces all but the 291 ROOT symbols that cannot be embedded. Same for the Acrobad solution. I actually also tried to “convert symbols into contours” preflight in Acrobad, and it also does not work.
In the meantime I have received my test copy from the print shop and the symbols in question (which they replaced themselves for the 10 additional euros) look just the same as plotted from ROOT directly…
just as an FYI, gonum/plot can embed fonts into PDF files.
Together with go-hep/rootio (to read ROOT files and TH1x+TH2x) and go-hep/hplot (that deals with HEP oriented plots), this could make for a nice stack to produce PDF plots.
Is it able to not embed also ? A quick test on a simple plot proves that the pdf file with embedded fonts is typically between 10 and 20 times bigger than the same PDF using built-in standard adobe fonts.
To simplify the embedding process a new option is now implemented in the root master.
root [0] hpx->Draw()
Info in <TCanvas::MakeDefCanvas>: created default TCanvas with name c1
root [1] gPad->Print("a.pdf","EmbedFonts")
Info in <TCanvas::Print>: EmbedFonts file a.pdf has been created
root [2]
gs does a great job. Depending how many fonts are used in a plot it can be about the same size for a standard simple plot up to a factor 6 for pictures using many different fonts.
Sorry for the harsh phrasing but I was thinking about this issue a bit more and concluded: I rank root plots being out of the box unfit for thesis printing as very severe. In submission stress, one does not want to encounter last minute that all plots need to be re-rendered (if self made in the first place, they might be citations from someone else, who can’t provide updated versions immediately) and I doubt every copy shop catches this type of issue (let alone provides fixes). In that perspective I would even opt for embed fonts by default, and sacrifice a possible size benefit for portability of the pdf.
Beyond that, the issue with non embedded fonts is visible on lxplus, so that’s somehow cern software not behaving correctly on cern computers …
TH1F* h = new TH1F("h","h",100,-5,5)
h->GetXaxis()->SetTitle("#mu#epsilon#pi")
h->FillRandom("gaus",500)
TCanvas* c = new TCanvas()
h->Draw()
c->SaveAs("b0rken.pdf")
.q
The embedding mechanism I implemented needs gs to be installed. Making the embed option the default will force people to install gs. I think it is quite flexible now. Either by creating the pdf with the Embed option (need gs) . Or use the PDFEmbed script posted in this thread. It is quite easy to embed fonts in PDF file when you know the command, and even if you don’t know it is quite easy to find it with google … Therefore I quite don’t understand why the printing shops make money with this … well, yes I do: that’s really easy money
