Menu
▾
▴
gnuplot-info
|
From: Andres C. <aci...@gm...> - 2012-05-03 05:07:39
|
Hi gnuplot users, I've been experiencing this very annoying problem with some of the plots I produce with gnuplot (happens on both 4.4.0 and 4.6.0). I produce the plots on a GNU/Linux system, specifically Debian testing, using either the pdfcairo or pdf terminals. I set fonts to be Arial. They look great on any pdf viewer I've checked. Furthermore the files open just fine in Inkscape and the font is properly detected as Arial. The nature of academic work requires cooperation. Some of these people hold Adobe Illustrator in high regard and they use it extensively for editing plots. Whenever I try opening my plots produced by gnuplot via any of the above mentioned pdf terminals, in Illustrator (on a Windows computer) it gives me an error saying that DejaVu Sans and Bitstream Vera fonts cannot be found and they will be substituted by the closest equivalent. Unfortunately the text becomes a bunch of squares with and "X" in the middle. This is very annoying. I can work around the problem using the postscript terminal. The font of the eps files produced this way works fine in Adobe Illustrator and other editors and viewers. Does anyone understand the problem here and how to get around it without having to use eps files? I don't want to have to resort to eps files. I will give cairolatex a try tomorrow and see if the situation improves. Any tips is welcome. Cheers Andres |
|
From: James C. <clo...@jh...> - 2012-05-03 14:21:58
|
>>>>> "AC" == Andres Cimmarusti <aci...@gm...> writes: AC> I produce the plots on a GNU/Linux system, specifically Debian AC> testing, using either the pdfcairo or pdf terminals. I set fonts AC> to be Arial. Do you have Arial installed? You will have had to have done it explicitly; Debian would not include that family. Does the pdf embed the fonts? pdffonts (from poppler or xpdf), mupdfinfo (from mupdf) are good tools to confirm that. Can you provide an example pdf from each terminal? Because Arial is so prevalent, default installs of fontconfig include configuration code to substitute other fonts should arial be unavailable. It looks like you end up with DejaVu Sans and/or Bitstream Vera Sans in the pdf files, but subset (only the glyphs actually used are included; that is normal for pdf files). That is why Illusrator complains. Your alternate workflow probably doesn't embed fonts, just names. -JimC -- James Cloos <cl...@jh...> OpenPGP: 1024D/ED7DAEA6 |
|
From: James C. <clo...@jh...> - 2012-05-03 19:49:56
|
>>>>> "AC" == Andres Cimmarusti <aci...@gm...> writes: AC> Yes I do have [Arial] installed (I have installed the package AC> ttf-mscorefonts-installer): D'oh. I entirely forgot about the mscorefonts-installer package.... >> Can you provide an example pdf from each terminal? AC> Attached. They both come from the pdfcairo terminal. Gnuplot will autocomplete terminal names, so if one asks for pdf but only pdfcairo is compiled in, one gets pdfcairo. AC> Correct me if I'm wrong, No. You reasoned correctly. AC> but I feel the problem here maybe slightly different. Having now seen the pdfs, your hypothesis is exacly correct. AC> I'm using some greek symbols (for tau and mu in the y and x AC> labels respectively) and I think gnuplot doesn't find these special AC> letters in Arial so it chooses the other fonts to compensate. I looked at the embedded fonts; the μ is from Vera and the τ from Deja. AC> I see. So even now that I know Arial is included, it keeps failing. Is AC> is because it says ArialMT? why would it say ArialMT in any case? (my AC> script calls for plain Arial...unfortunately this is font of choice of AC> my collaborators). The MT is for Monotype, the foundry from which MS licensed Arial. Illustrator shouldn't have a problem with that. If you have lcd-typetools installed, I'd bet that otfinfo -p arial.ttf will show that the font's PostScript Name is ArialMT. otfinfo's -i option should give additional info. If Debian's mscorefonts-installer uses the fonts from: http://corefonts.sourceforge.net/ then it should have mu and tau glyphs. If you have it installed, xfd -fa Arial should show the glyphs supported by your version of Arial; you can use lsof(8) or look in /proc/$(pidof xfd)/maps to confirm that is has loaded the right font file. If you [Next] to the 0x0300 page it should have Hellenic glyphs. I don't know why pango ignores those in favour of ones from the Sans alias. Do you run gnuplot in a utf-8 locale? If not, that may be why. If so, it could be a bug in the pdfcairo terminal. I just tried (with cairo and gnuplot from their git repos) in en_US.UTF-8. A simple plot: set term pdf enh font 'Arial,16' set out "myt.pdf" set label "Ελλενικα" plot sin(x)+2*cos(x) resulted in Arial for the mu and tau: :; pdffonts myt.pdf name type encoding emb sub uni object ID --------------- ------------- ----------- --- --- --- --------- OLTWPV+ArialMT TrueType WinAnsi yes yes yes 5 0 NUXGAE+ArialMT CID TrueType Identity-H yes yes yes 6 0 It looks like you either need to switch to a utf-8 locale or newer version(s) of gnuplot and/or cairo. -JimC -- James Cloos <cl...@jh...> OpenPGP: 1024D/ED7DAEA6 |
|
From: Andres C. <aci...@gm...> - 2012-05-04 21:18:18
|
> For some reason Illustrator ignores the ToUnicode CMAP which is included > in the pdf. Without that information is it unable to determine what > character to use in place of each glyph. > > But that is just the mechanism; I don't know the reason behind it. > > It shouldn't have a problem with the CMap, though. Text extraction works > fine with yscale_vs_width.pdf, including the Greek. Extraction also > works with your earlier pdfs. Acroread also is happy with the CMaps. > > If you have access to them, it would be interesting to know whether > InDesign or (the full) Acrobat do any better than Illustrator on > those pdfs. I don't have access to InDesign, but I did try with Acrobat (reader and full version) and it works just fine. It's illustrator that doesn't work. I just tried with gnuplot on windows. I figured there could be something wrong with the Debian fonts or version of pango/cairo. But I got the same problem! I won't even bother to attach the file. Could this be a bug in gnuplot or pango? I've produced plots with matlab before (using Arial) and Illustrator is happy with them. If it's a bug, it's a very subtle one... |
|
From: James C. <clo...@jh...> - 2012-05-05 15:29:56
|
>>>>> "AC" == Andres Cimmarusti <aci...@gm...> writes: AC> I don't have access to InDesign, but I did try with Acrobat (reader AC> and full version) and it works just fine. It's illustrator that AC> doesn't work. If you can upgrade cairo to 1.12 (1.12.2 is current) that might help. Since Acrobat is happy with them, you might try having acrobat re- generate the pdf and check whether illustrator is happy with that. If it is, the difference between the two pdfs might help explain why it doesn't like the cairo-1.10 generated pdfs. -JimC -- James Cloos <cl...@jh...> OpenPGP: 1024D/ED7DAEA6 |
|
From: Andres C. <aci...@gm...> - 2012-05-09 21:34:53
|
Hi again > If you can upgrade cairo to 1.12 (1.12.2 is current) that might help. I decided to wait till Debian testing would get the upgraded versions of cairo 1.12 and pango 1.30, which happened today. Not sure which one did the trick, but everything works as expected now. I'm assuming it was the updated pango. I think the problem lies in this difference: BEFORE: $ pdffonts sample_plot.pdf name type emb sub uni object ID ------------------------------------ ----------------- --- --- --- --------- AGCFOR+ArialMT CID TrueType yes yes yes 5 0 AFTER UPGRADE: $ pdffonts sample_plot.pdf name type emb sub uni object ID ------------------------------------ ----------------- --- --- --- --------- BNNLMS+ArialMT TrueType yes yes yes 5 0 MEXTZI+ArialMT CID TrueType yes yes yes 6 0 Somehow, pango or cairo were not embedding the truetype 'type' that Adobe Illustrator likes and thus it was seen as some unknown font. The problem still exists in older versions of these libraries, including the ones embedded in the windows gnuplot binaries. I tried using gnuplot 4.6 for windows to replicate the problem and it happened as well, so it's not a GNU/Linux centric problem. Thanks for the help! Best regards, Andres Cimmarusti |
|
From: James C. <clo...@jh...> - 2012-05-12 18:09:24
|
>>>>> "AC" == Andres Cimmarusti <aci...@gm...> writes: AC> I decided to wait till Debian testing would get the upgraded versions AC> of cairo 1.12 and pango 1.30, which happened today. Not sure which one AC> did the trick, but everything works as expected now. I'm assuming it AC> was the updated pango. Cairo is much more likely. AC> I think the problem lies in this difference: AC> BEFORE: AC> AGCFOR+ArialMT CID TrueType yes yes yes 5 0 AC> AFTER UPGRADE: AC> $ pdffonts sample_plot.pdf AC> name type emb sub uni object ID ------------------------------------ ----------------- --- --- --- --------- AC> BNNLMS+ArialMT TrueType yes yes yes 5 0 AC> MEXTZI+ArialMT CID TrueType yes yes yes 6 0 That change is due to a request by the TeX community. Certain tools expect to find TeX strings in eps files; when the tools which generated those eps file switched to cairo, that became much more difficult. So cairo was changed to embed anything which can fit in WinAnsi in a non- CID font so that it can embed that text in ()-quoted strings instead of using the <HEXHEXHEX> encoded strings which CID fonts require. I suspect that the CMap objects also are different between 1.10 and 1.12, and that *that* is the change which fixed your use case. But that is only an hypothesis.... -JimC -- James Cloos <cl...@jh...> OpenPGP: 1024D/ED7DAEA6 |
|
From: James C. <clo...@jh...> - 2012-05-14 16:37:27
|
>>>>> "JC" == James Cloos <clo...@jh...> writes: JC> That change is due to a request by the TeX community. A bug report today reminded me that that change was made at the request of psfrag users who were using inkscape to generate vector art. -JimC -- James Cloos <cl...@jh...> OpenPGP: 1024D/ED7DAEA6 |
