From roym at ce.washington.edu Fri Mar 9 01:05:47 2007 From: roym at ce.washington.edu (Roy Mayfield) Date: Thu, 08 Mar 2007 22:05:47 -0800 Subject: [Tioga-users] Embedded fonts Message-ID: <45F0F93B.5020501@ce.washington.edu> I am submitting a pdf file to a publisher who requires ALL fonts to be embedded. The figures that I have created with Tioga that use ZapfDingbat symbols don't seem to have that font embedded in the pdf even though I have the pdflatex cfg file setup to embed the 14 standard fonts. Is this an issue with Tioga or do I need to keep digging into the pdflatex setup (or something else)? -- Thanks, Roy Mayfield From vincent.fourmond at 9online.fr Fri Mar 9 06:06:08 2007 From: vincent.fourmond at 9online.fr (vincent.fourmond at 9online.fr) Date: Fri, 09 Mar 2007 11:06:08 +0000 (GMT) Subject: [Tioga-users] Embedded fonts In-Reply-To: <45F0F93B.5020501@ce.washington.edu> References: <45F0F93B.5020501@ce.washington.edu> Message-ID: An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/tioga-users/attachments/20070309/ad4f6fdd/attachment.html From vincent.fourmond at 9online.fr Fri Mar 9 05:47:47 2007 From: vincent.fourmond at 9online.fr (vincent.fourmond at 9online.fr) Date: Fri, 09 Mar 2007 10:47:47 +0000 (GMT) Subject: [Tioga-users] Segfault fixes ?? Message-ID: An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/tioga-users/attachments/20070309/151fd0d8/attachment.html From edder at tkwsping.nl Fri Mar 9 09:36:56 2007 From: edder at tkwsping.nl (Edwin) Date: Fri, 09 Mar 2007 14:36:56 -0000 Subject: [Tioga-users] Segfault fixes ?? In-Reply-To: References: Message-ID: On Fri, 09 Mar 2007 10:47:47 -0000, wrote: Hi Vincent > I hope it will work for at least some of you. Please keep me posted !! I tested and still the same problem, I did find out though that plots with log axis will work (never tested this before), so from the example file number 3 (Log_Reds) works, but all the others give segmentation fautls. (gdb) run /usr/bin/tioga plots.rb -1 Starting program: /usr/bin/ruby /usr/bin/tioga plots.rb -1 (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) loading /home/edwin/tmp/tioga-1.4/samples/plots/plots.rb Program received signal SIGSEGV, Segmentation fault. 0xb7a93958 in End_Axis_Standard_State at plt () from /usr/lib/ruby/site_ruby/1.8/i686-linux/Tioga/FigureMaker.so (gdb) bt #0 0xb7a93958 in End_Axis_Standard_State at plt () from /usr/lib/ruby/site_ruby/1.8/i686-linux/Tioga/FigureMaker.so #1 0xb7a9dd3d in c_show_side () from /usr/lib/ruby/site_ruby/1.8/i686-linux/Tioga/FigureMaker.so #2 0xb7a9e9ae in FM_show_axis () from /usr/lib/ruby/site_ruby/1.8/i686-linux/Tioga/FigureMaker.so #3 0xb7e6c9f7 in rb_rescue () from /usr/lib/libruby18.so.1.8 #4 0xb7e76120 in rb_yield () from /usr/lib/libruby18.so.1.8 #5 0xb7e76558 in rb_yield () from /usr/lib/libruby18.so.1.8 #6 0xb7e738ba in rb_yield () from /usr/lib/libruby18.so.1.8 #7 0xb7e76136 in rb_yield () from /usr/lib/libruby18.so.1.8 #8 0xb7e76558 in rb_yield () from /usr/lib/libruby18.so.1.8 #9 0xb7e72ee6 in rb_yield () from /usr/lib/libruby18.so.1.8 #10 0xb7e76136 in rb_yield () from /usr/lib/libruby18.so.1.8 #11 0xb7e76558 in rb_yield () from /usr/lib/libruby18.so.1.8 #12 0xb7e72ee6 in rb_yield () from /usr/lib/libruby18.so.1.8 #13 0xb7e71389 in rb_frozen_class_p () from /usr/lib/libruby18.so.1.8 #14 0xb7e7af84 in rb_iter_break () from /usr/lib/libruby18.so.1.8 #15 0xb7e6c619 in rb_rescue () from /usr/lib/libruby18.so.1.8 #16 0xb7e76120 in rb_yield () from /usr/lib/libruby18.so.1.8 #17 0xb7e76558 in rb_yield () from /usr/lib/libruby18.so.1.8 #18 0xb7e7379e in rb_yield () from /usr/lib/libruby18.so.1.8 #19 0xb7e724e2 in rb_yield () from /usr/lib/libruby18.so.1.8 #20 0xb7e76136 in rb_yield () from /usr/lib/libruby18.so.1.8 #21 0xb7e76558 in rb_yield () from /usr/lib/libruby18.so.1.8 #22 0xb7e738ba in rb_yield () from /usr/lib/libruby18.so.1.8 #23 0xb7e7523b in rb_yield () from /usr/lib/libruby18.so.1.8 #24 0xb7e76136 in rb_yield () from /usr/lib/libruby18.so.1.8 #25 0xb7e76558 in rb_yield () from /usr/lib/libruby18.so.1.8 #26 0xb7e7379e in rb_yield () from /usr/lib/libruby18.so.1.8 #27 0xb7e7523b in rb_yield () from /usr/lib/libruby18.so.1.8 #28 0xb7e76136 in rb_yield () from /usr/lib/libruby18.so.1.8 #29 0xb7e76558 in rb_yield () from /usr/lib/libruby18.so.1.8 #30 0xb7e72ee6 in rb_yield () from /usr/lib/libruby18.so.1.8 #31 0xb7e71389 in rb_frozen_class_p () from /usr/lib/libruby18.so.1.8 #32 0xb7e7af84 in rb_iter_break () from /usr/lib/libruby18.so.1.8 #33 0xb7e6c619 in rb_rescue () from /usr/lib/libruby18.so.1.8 #34 0xb7e76120 in rb_yield () from /usr/lib/libruby18.so.1.8 #35 0xb7e76558 in rb_yield () from /usr/lib/libruby18.so.1.8 #36 0xb7e7379e in rb_yield () from /usr/lib/libruby18.so.1.8 #37 0xb7e749ad in rb_yield () from /usr/lib/libruby18.so.1.8 #38 0xb7e76136 in rb_yield () from /usr/lib/libruby18.so.1.8 #39 0xb7e76558 in rb_yield () from /usr/lib/libruby18.so.1.8 #40 0xb7e738ba in rb_yield () from /usr/lib/libruby18.so.1.8 #41 0xb7e724e2 in rb_yield () from /usr/lib/libruby18.so.1.8 #42 0xb7e76136 in rb_yield () from /usr/lib/libruby18.so.1.8 #43 0xb7e76558 in rb_yield () from /usr/lib/libruby18.so.1.8 #44 0xb7e76a6b in rb_respond_to () from /usr/lib/libruby18.so.1.8 #45 0xb7e76bbc in rb_funcall () from /usr/lib/libruby18.so.1.8 #46 0xb7a98d54 in FM_private_make () from /usr/lib/ruby/site_ruby/1.8/i686-linux/Tioga/FigureMaker.so #47 0xb7e6c9e6 in rb_rescue () from /usr/lib/libruby18.so.1.8 #48 0xb7e76120 in rb_yield () from /usr/lib/libruby18.so.1.8 #49 0xb7e76558 in rb_yield () from /usr/lib/libruby18.so.1.8 #50 0xb7e738ba in rb_yield () from /usr/lib/libruby18.so.1.8 #51 0xb7e724e2 in rb_yield () from /usr/lib/libruby18.so.1.8 #52 0xb7e749ad in rb_yield () from /usr/lib/libruby18.so.1.8 #53 0xb7e76136 in rb_yield () from /usr/lib/libruby18.so.1.8 #54 0xb7e76558 in rb_yield () from /usr/lib/libruby18.so.1.8 #55 0xb7e738ba in rb_yield () from /usr/lib/libruby18.so.1.8 #56 0xb7e724e2 in rb_yield () from /usr/lib/libruby18.so.1.8 #57 0xb7e749ad in rb_yield () from /usr/lib/libruby18.so.1.8 #58 0xb7e72ea1 in rb_yield () from /usr/lib/libruby18.so.1.8 #59 0xb7e76136 in rb_yield () from /usr/lib/libruby18.so.1.8 #60 0xb7e76558 in rb_yield () from /usr/lib/libruby18.so.1.8 #61 0xb7e738ba in rb_yield () from /usr/lib/libruby18.so.1.8 #62 0xb7e724e2 in rb_yield () from /usr/lib/libruby18.so.1.8 #63 0xb7e76136 in rb_yield () from /usr/lib/libruby18.so.1.8 #64 0xb7e76558 in rb_yield () from /usr/lib/libruby18.so.1.8 #65 0xb7e738ba in rb_yield () from /usr/lib/libruby18.so.1.8 #66 0xb7e76136 in rb_yield () from /usr/lib/libruby18.so.1.8 #67 0xb7e76558 in rb_yield () from /usr/lib/libruby18.so.1.8 #68 0xb7e7379e in rb_yield () from /usr/lib/libruby18.so.1.8 #69 0xb7e724e2 in rb_yield () from /usr/lib/libruby18.so.1.8 #70 0xb7e76136 in rb_yield () from /usr/lib/libruby18.so.1.8 #71 0xb7e76558 in rb_yield () from /usr/lib/libruby18.so.1.8 #72 0xb7e738ba in rb_yield () from /usr/lib/libruby18.so.1.8 #73 0xb7e73842 in rb_yield () from /usr/lib/libruby18.so.1.8 #74 0xb7e749ad in rb_yield () from /usr/lib/libruby18.so.1.8 #75 0xb7e76136 in rb_yield () from /usr/lib/libruby18.so.1.8 #76 0xb7e76558 in rb_yield () from /usr/lib/libruby18.so.1.8 #77 0xb7e767e6 in rb_obj_call_init () from /usr/lib/libruby18.so.1.8 #78 0xb7e9eb5e in rb_class_new_instance () from /usr/lib/libruby18.so.1.8 #79 0xb7e6ca16 in rb_rescue () from /usr/lib/libruby18.so.1.8 #80 0xb7e76120 in rb_yield () from /usr/lib/libruby18.so.1.8 #81 0xb7e76558 in rb_yield () from /usr/lib/libruby18.so.1.8 #82 0xb7e7379e in rb_yield () from /usr/lib/libruby18.so.1.8 #83 0xb7e800b8 in rb_load () from /usr/lib/libruby18.so.1.8 #84 0xb7e806f1 in rb_require_safe () from /usr/lib/libruby18.so.1.8 #85 0xb7e80925 in rb_f_require () from /usr/lib/libruby18.so.1.8 #86 0xb7e6c9f7 in rb_rescue () from /usr/lib/libruby18.so.1.8 #87 0xb7e76120 in rb_yield () from /usr/lib/libruby18.so.1.8 ---Type to continue, or q to quit--- #88 0xb7e76558 in rb_yield () from /usr/lib/libruby18.so.1.8 #89 0xb7e738ba in rb_yield () from /usr/lib/libruby18.so.1.8 #90 0xb7e749ad in rb_yield () from /usr/lib/libruby18.so.1.8 #91 0xb7e76136 in rb_yield () from /usr/lib/libruby18.so.1.8 #92 0xb7e76558 in rb_yield () from /usr/lib/libruby18.so.1.8 #93 0xb7e738ba in rb_yield () from /usr/lib/libruby18.so.1.8 #94 0xb7e817f0 in rb_eval_string () from /usr/lib/libruby18.so.1.8 #95 0xb7e81830 in ruby_exec () from /usr/lib/libruby18.so.1.8 #96 0xb7e81865 in ruby_run () from /usr/lib/libruby18.so.1.8 #97 0x080486a2 in main () Hope this helps, Edwin From vincent.fourmond at 9online.fr Fri Mar 9 10:48:41 2007 From: vincent.fourmond at 9online.fr (Vincent Fourmond) Date: Fri, 09 Mar 2007 16:48:41 +0100 Subject: [Tioga-users] Segfault fixes ?? In-Reply-To: References: Message-ID: <45F181D9.6080904@9online.fr> Edwin wrote: > On Fri, 09 Mar 2007 10:47:47 -0000, wrote: > Hi Vincent > >> I hope it will work for at least some of you. Please keep me posted !! > > I tested and still the same problem, I did find out though that plots with > log axis will work (never tested this before), so from the example file > number 3 (Log_Reds) works, but all the others give segmentation fautls. This is weird... > (gdb) run /usr/bin/tioga plots.rb -1 > Starting program: /usr/bin/ruby /usr/bin/tioga plots.rb -1 > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > loading /home/edwin/tmp/tioga-1.4/samples/plots/plots.rb ^^^ Are you sure it is the last version you're using ? I can't understand what could be the cause. Thanks for the backtrace, I'll have a closer look as soon as I have the time (which might not come so soon, unfortunately...). Cheers, and thanks for testing, Vincent -- Vincent Fourmond, PhD student (not for long anymore) http://vincent.fourmond.neuf.fr/ From edder at tkwsping.nl Fri Mar 9 10:59:59 2007 From: edder at tkwsping.nl (Edwin) Date: Fri, 09 Mar 2007 15:59:59 -0000 Subject: [Tioga-users] Segfault fixes ?? In-Reply-To: <45F181D9.6080904@9online.fr> References: <45F181D9.6080904@9online.fr> Message-ID: >> loading /home/edwin/tmp/tioga-1.4/samples/plots/plots.rb > ^^^ > Are you sure it is the last version you're using ? I can't understand > what could be the cause. Thanks for the backtrace, I'll have a closer > look as soon as I have the time (which might not come so soon, > unfortunately...). Oops could have known that would cause confusion. I used those samples, because I downloaded the 1.5 version without-images and for some weird reason assumed that that would mean it was without samples. So, I can assure you it is the latest version I have installed, I double checked the make install and made sure I didn't have a copie left of any file. You can also see from the following that the error was in FigureMaker.so, so I made triple sure that that was the latest version. Program received signal SIGSEGV, Segmentation fault. 0xb7a93958 in End_Axis_Standard_State at plt () from /usr/lib/ruby/site_ruby/1.8/i686-linux/Tioga/FigureMaker.so I am also still very puzzled by this. For now I am using tioga over ssh from a 64bit machine where it is working. I am a bit worried that it would be only on my two machine, but I have no problems with any other programs that I compiled myself. Edwin From paxton at kitp.ucsb.edu Fri Mar 9 11:26:03 2007 From: paxton at kitp.ucsb.edu (Bill Paxton) Date: Fri, 9 Mar 2007 08:26:03 -0800 Subject: [Tioga-users] Embedded fonts In-Reply-To: <45F0F93B.5020501@ce.washington.edu> References: <45F0F93B.5020501@ce.washington.edu> Message-ID: On Mar 8, 2007, at 10:05 PM, Roy Mayfield wrote: > I am submitting a pdf file to a publisher who requires ALL fonts to > be embedded. > The figures that I have created with Tioga that use ZapfDingbat > symbols don't > seem to have that font embedded in the pdf even though I have the > pdflatex cfg > file setup to embed the 14 standard fonts. Is this an issue with > Tioga or do I > need to keep digging into the pdflatex setup (or something else)? > -- > Thanks, > Roy Mayfield Hi Roy, Thanks for the email. I presume that you are using ZapfDingbats as marker symbols in plots. That means that they are treated as graphics elements rather than as text to be sent to TeX. As you undoubtedly know, the fonts for markers are limited to the 14 standard Adobe fonts. Here's what I say about the situation in the Tioga::MarkerConstants documentation: "All PDF devices are guaranteed to have the 14 standard Adobe fonts, so they are easy to provide ? and that?s what I?ve done." http://theory.kitp.ucsb.edu/~paxton/tioga_doc/classes/Tioga/ MarkerConstants.html It isn't just my idea that these fonts will be available everywhere -- it is part of the definition of PDF and PostScript! The info on page 416 of the 6th Edition of the Adobe PDF Reference Version 1.7 (November 2006) makes it clear (http://www.adobe.com/ devnet/pdf/pdf_reference.html): Standard Type 1 Fonts The PostScript names of 14 Type 1 fonts, known as the standard fonts, are as follows: Times?Roman Helvetica Courier Symbol Times?Bold Helvetica?Bold Courier?Bold ZapfDingbats Times?Italic Helvetica?Oblique Courier?Oblique Times?BoldItalic Helvetica?BoldOblique Courier?BoldOblique These fonts, or their font metrics and suitable substitution fonts, must be avail- able to the consumer application. That means that these 14 fonts are built into the PDF/PostScript standard and must be available as part of any implementation of PDF/PostScript. In other words, these fonts have been declared as part of the standard just so that it would NOT be necessary to embed them! And this isn't some new addition to PostScript -- those 14 fonts have had special status for a long time. For example, back in the 2nd Edition of the PDF Reference, the same info appears on page 296. For any font not on this list, I can understand perfectly why your publisher would require embedding. But for the 14 standard fonts, embedding is explicitly defined to be stupid! So your challenge is to educate your publisher -- good luck! Cheers, Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/tioga-users/attachments/20070309/c814985d/attachment.html From paxton at kitp.ucsb.edu Fri Mar 9 12:39:18 2007 From: paxton at kitp.ucsb.edu (Bill Paxton) Date: Fri, 9 Mar 2007 09:39:18 -0800 Subject: [Tioga-users] Embedded fonts In-Reply-To: <45F19686.6090405@ce.washington.edu> References: <45F0F93B.5020501@ce.washington.edu> <45F19686.6090405@ce.washington.edu> Message-ID: <3D5A36E4-EA7D-4EB8-A036-DD7C4B9BE4BC@kitp.ucsb.edu> On Mar 9, 2007, at 9:16 AM, Roy Mayfield wrote: > Hi Bill, > > Thanks for the background information. I am far from informed about > this matter, especially in comparison with you, but after googling > the > topic it seems that my situation is not an isolated case -- some > publishers require all fonts to be embedded. The argument for this > seems to be based on the quality and uniformity of the standard fonts; > here is a quote from the updmap.cfg man file: "Should pdftex download > the base 14 pdf fonts? Since some configurations (ps / pdf tools / > printers) use bad default fonts, it is safer to download the fonts." > > Your point about the pdf standard is a good one, and matters would be > simplified considerably if the standard were applied consistently. > However, a standard is only useful if everyone agrees to adopt it > and if > it is implemented effectively and uniformly. The last point seems > to be > the rub in this case. > > As for educating publishers, I offer 2 quotes: > > 1) What is the difference between a publisher and a terrorist? You > can > negotiate with a terrorist. > > 2) Fatty and skinny went to bed. Fatty rolled over and skinny was > dead. > > As an author in a technical field, I am most definitely skinny. > -- > Cheers, > Roy > Okay. "I feel your pain" as the saying goes. Perhaps there's still a way around this. What do you do to get pdflatex to embed fonts? Might it be possible to fake a use of ZapfDingbats at the tex level to get the font embedded? The background info here is that Tioga PDFs for plots are built by pdflatex using a temporary PDF file for the graphics. The graphics PDF is combined with text from TeX to produce the "final" PDF for the plot. Any TeX text that shows up in the figure will need to have it's fonts embedded, so if you can trick it into doing ZapfDingbats, we might have a workaround. Let me know if that works! Thanks, Bill From roym at ce.washington.edu Fri Mar 9 12:16:54 2007 From: roym at ce.washington.edu (Roy Mayfield) Date: Fri, 09 Mar 2007 09:16:54 -0800 Subject: [Tioga-users] Embedded fonts In-Reply-To: References: <45F0F93B.5020501@ce.washington.edu> Message-ID: <45F19686.6090405@ce.washington.edu> Bill Paxton wrote: > > On Mar 8, 2007, at 10:05 PM, Roy Mayfield wrote: > >> I am submitting a pdf file to a publisher who requires ALL fonts to be >> embedded. >> The figures that I have created with Tioga that use ZapfDingbat >> symbols don't >> seem to have that font embedded in the pdf even though I have the >> pdflatex cfg >> file setup to embed the 14 standard fonts. Is this an issue with >> Tioga or do I >> need to keep digging into the pdflatex setup (or something else)? >> -- >> Thanks, >> Roy Mayfield > > Hi Roy, > > Thanks for the email. I presume that you are using ZapfDingbats as > marker symbols in plots. > That means that they are treated as graphics elements rather than as > text to be sent to TeX. > As you undoubtedly know, the fonts for markers are limited to the 14 > standard Adobe fonts. > Here's what I say about the situation in the Tioga::MarkerConstants > documentation: > > "All PDF devices are guaranteed to have the 14 standard Adobe fonts, > so they are easy to provide ? and that?s what I?ve done." > > http://theory.kitp.ucsb.edu/~paxton/tioga_doc/classes/Tioga/MarkerConstants.html > > It isn't just my idea that these fonts will be available everywhere -- > it is part of the > definition of PDF and PostScript! The info on page 416 of the 6th > Edition of the Adobe PDF Reference > Version 1.7 (November 2006) makes it clear > (http://www.adobe.com/devnet/pdf/pdf_reference.html): > > Standard Type 1 Fonts > > The PostScript names of 14 Type 1 fonts, known as the standard fonts, > are as > follows: > > Times?Roman Helvetica Courier Symbol > Times?Bold Helvetica?Bold Courier?Bold ZapfDingbats > Times?Italic Helvetica?Oblique Courier?Oblique > Times?BoldItalic Helvetica?BoldOblique Courier?BoldOblique > > These fonts, or their font metrics and suitable substitution fonts, must > be avail- > able to the consumer application. > That means that these 14 fonts are built into the PDF/PostScript standard > and must be available as part of any implementation of PDF/PostScript. > In other words, these fonts have been declared as part of the standard > just so > that it would NOT be necessary to embed them! And this isn't some new > addition > to PostScript -- those 14 fonts have had special status for a long > time. For example, > back in the 2nd Edition of the PDF Reference, the same info appears on > page 296. > > For any font not on this list, I can understand perfectly why your > publisher would require > embedding. But for the 14 standard fonts, embedding is explicitly > defined to be stupid! > > So your challenge is to educate your publisher -- good luck! > > Cheers, > Bill > Hi Bill, Thanks for the background information. I am far from informed about this matter, especially in comparison with you, but after googling the topic it seems that my situation is not an isolated case -- some publishers require all fonts to be embedded. The argument for this seems to be based on the quality and uniformity of the standard fonts; here is a quote from the updmap.cfg man file: "Should pdftex download the base 14 pdf fonts? Since some configurations (ps / pdf tools / printers) use bad default fonts, it is safer to download the fonts." Your point about the pdf standard is a good one, and matters would be simplified considerably if the standard were applied consistently. However, a standard is only useful if everyone agrees to adopt it and if it is implemented effectively and uniformly. The last point seems to be the rub in this case. As for educating publishers, I offer 2 quotes: 1) What is the difference between a publisher and a terrorist? You can negotiate with a terrorist. 2) Fatty and skinny went to bed. Fatty rolled over and skinny was dead. As an author in a technical field, I am most definitely skinny. -- Cheers, Roy From vincent.fourmond at 9online.fr Sun Mar 11 17:45:04 2007 From: vincent.fourmond at 9online.fr (Vincent Fourmond) Date: Sun, 11 Mar 2007 22:45:04 +0100 Subject: [Tioga-users] Segfault fixes ?? In-Reply-To: References: <45F181D9.6080904@9online.fr> Message-ID: <45F47860.3010509@9online.fr> Edwin wrote: > So, I can assure you it is the latest version I have installed, I double > checked the make install and made sure I didn't have a copie left of any > file. You can also see from the following that the error was in > FigureMaker.so, so I made triple sure that that was the latest version. > Program received signal SIGSEGV, Segmentation fault. > 0xb7a93958 in End_Axis_Standard_State at plt () > from /usr/lib/ruby/site_ruby/1.8/i686-linux/Tioga/FigureMaker.so > > I am also still very puzzled by this. For now I am using tioga over ssh > from a 64bit machine where it is working. I am a bit worried that it > would be only on my two machine, but I have no problems with any other > programs that I compiled myself. I'm glad it's working on a 64 bit machine. I had a closer look at the function causing the segfault, I really can't understand how it could cause segfaults, as it is not using shared symbols (which are kinda slippery on different archs) and not even pointers that would have a chance to get there uninitialized. It might be a compiler bug. I really won't have any opportunity to take a closer look over the next two weeks as I'm away from my computer. However, you could try to modify the Makefile produced by extconf.rb to replace -O2 (or any other optimization options) by -O0, replace CC by another compiler if you have one available and so on. It would help a lot to know if it is compiler-related. If you feel like hacking the code, add fprintf(stderr, "TF: %p\n", TF); in pdffile.c/Write_grestore. (before the extisting line). If the values displayed change in one run, it really would look like a compiler bug to me. Cheers, and good hunt ! Vincent -- Vincent Fourmond, PhD student (not for long anymore) http://vincent.fourmond.neuf.fr/ From vincent.fourmond at 9online.fr Sun Mar 11 18:04:04 2007 From: vincent.fourmond at 9online.fr (Vincent Fourmond) Date: Sun, 11 Mar 2007 23:04:04 +0100 Subject: [Tioga-users] Embedded fonts In-Reply-To: <3D5A36E4-EA7D-4EB8-A036-DD7C4B9BE4BC@kitp.ucsb.edu> References: <45F0F93B.5020501@ce.washington.edu> <45F19686.6090405@ce.washington.edu> <3D5A36E4-EA7D-4EB8-A036-DD7C4B9BE4BC@kitp.ucsb.edu> Message-ID: <45F47CD4.4030902@9online.fr> Bill Paxton wrote: > On Mar 9, 2007, at 9:16 AM, Roy Mayfield wrote: > >> Hi Bill, > Any TeX text that shows up in the figure will need to have it's fonts > embedded, so if > you can trick it into doing ZapfDingbats, we might have a workaround. Seems like my post got lost ;-)... So here is a summary of what you need to do to embed the PDF standard fonts inside a PDF. You really should have all the tools here as a part of a standard LaTeX installation - you might need to install xpdf, though, to get pdftops. I can't get gs to work with this yet. First run pdftops -eps Plot.pdf This produces an EPS file, Plot.eps. Then, run the following command-line to convert it back to PDF embedding also the standard fonts: epstopdf --nogs Plot.eps |gs -q -sDEVICE=pdfwrite -dAutoRotatePages=/None -dPDFSETTINGS=/prepress -sOutputFile=Plot_new.pdf - (do not forget the - at the end of the command !). And, now, all fonts are embedded, which you can check with pdffonts: 23:01 vincent at tanyaivinco ~ pdffonts Plot_new.pdf name type emb sub uni object ID ------------------------------------ ------------ --- --- --- --------- YOPKJB+CMR10 Type 1C yes yes no 11 0 ICPHXL+CMMI10 Type 1C yes yes no 13 0 MCEARB+CMSY10 Type 1C yes yes no 15 0 ACTAOE+ZapfDingbats Type 1C yes yes no 9 0 When I have some time, I'll write a little shell script to do this thing; I'll include it into the tioga distribution to make life simpler for people in your case. Cheers, I hope it will help ! Vincent -- Vincent Fourmond, PhD student (not for long anymore) http://vincent.fourmond.neuf.fr/ From edder at tkwsping.nl Mon Mar 12 06:30:56 2007 From: edder at tkwsping.nl (Edwin) Date: Mon, 12 Mar 2007 10:30:56 -0000 Subject: [Tioga-users] Segfault fixes ?? In-Reply-To: <45F47860.3010509@9online.fr> References: <45F181D9.6080904@9online.fr> <45F47860.3010509@9online.fr> Message-ID: > It might be a compiler bug. I thought I already tried using a different version of gcc, but to make sure I tried it again today and low and behold it works! :) So it seems to work with gcc 3.4.6, but not with 4.1.1. I am actually quite surprised by this, because I am using gentoo, which means that basically all software I am using is compiled when installing it. I would have thought I'd notice such a bug with other software. Anyway I am glad it is working again. Thanks for all the help. Edwin From roym at ce.washington.edu Tue Mar 13 10:28:38 2007 From: roym at ce.washington.edu (Roy Mayfield) Date: Tue, 13 Mar 2007 07:28:38 -0700 Subject: [Tioga-users] Embedded fonts Message-ID: <45F6B516.4010405@ce.washington.edu> Vincent Fourmond wrote: > Bill Paxton wrote: >> On Mar 9, 2007, at 9:16 AM, Roy Mayfield wrote: >> >>> Hi Bill, >> Any TeX text that shows up in the figure will need to have it's fonts >> embedded, so if >> you can trick it into doing ZapfDingbats, we might have a workaround. > > Seems like my post got lost ;-)... > > So here is a summary of what you need to do to embed the PDF standard > fonts inside a PDF. You really should have all the tools here as a part > of a standard LaTeX installation - you might need to install xpdf, > though, to get pdftops. I can't get gs to work with this yet. First run > > pdftops -eps Plot.pdf > > This produces an EPS file, Plot.eps. Then, run the following > command-line to convert it back to PDF embedding also the standard fonts: > > epstopdf --nogs Plot.eps |gs -q -sDEVICE=pdfwrite > -dAutoRotatePages=/None -dPDFSETTINGS=/prepress -sOutputFile=Plot_new.pdf - > > (do not forget the - at the end of the command !). And, now, all fonts > are embedded, which you can check with pdffonts: > > 23:01 vincent at tanyaivinco ~ pdffonts Plot_new.pdf > name type emb sub uni object ID > ------------------------------------ ------------ --- --- --- --------- > YOPKJB+CMR10 Type 1C yes yes no 11 0 > ICPHXL+CMMI10 Type 1C yes yes no 13 0 > MCEARB+CMSY10 Type 1C yes yes no 15 0 > ACTAOE+ZapfDingbats Type 1C yes yes no 9 0 > > When I have some time, I'll write a little shell script to do this > thing; I'll include it into the tioga distribution to make life simpler > for people in your case. > > Cheers, I hope it will help ! > > Vincent Thanks Vincent, Your suggestion is consistent with other online posts. I lashed up a slightly simpler one-step method using Ghostscript: gs -q -dNOPAUSE -dBATCH -dPDFSETTINGS=/prepress -sDEVICE=pdfwrite -sOutputFile=output.pdf input.pdf This causes Ghostscript to read input.pdf and write to output.pdf; the /prepress setting causes Ghostscript to embed all the fonts. I found, though, that just running this on my dissertation pdf didn't fix the problem; I had to run it on the individual figures then rerun pdflatex. To make this manageable, I wrote the figure filenames to a text file then ran a cheesy little bash script to grind through the whole list. This worked just fine for me, but I strongly suggest creating a backup of all files that are being processed. By the way, I am working on a Gnu/Linux box with the Kubuntu 3.10 distribution. -- Cheers, Roy From fourmond at gmail.com Wed Mar 14 05:28:47 2007 From: fourmond at gmail.com (Vincent Fourmond) Date: Wed, 14 Mar 2007 10:28:47 +0100 Subject: [Tioga-users] Embedded fonts In-Reply-To: <45F6B516.4010405@ce.washington.edu> References: <45F6B516.4010405@ce.washington.edu> Message-ID: <2e474d6f0703140228n3afa8f0evad9c52511c3b34d3@mail.gmail.com> On 3/13/07, Roy Mayfield wrote: > Your suggestion is consistent with other online posts. I lashed up a slightly > simpler one-step method using Ghostscript: > > gs -q -dNOPAUSE -dBATCH -dPDFSETTINGS=/prepress -sDEVICE=pdfwrite > -sOutputFile=output.pdf input.pdf Great ! Bill, could you include this in the tutorial ?? (and the other method, just in case this one is giving troubles. Cheers, Vincent, in a very good mood (look at nm.debian.org for Vincent Fourmond...) From pchoi at pomona.edu Fri Mar 16 12:08:13 2007 From: pchoi at pomona.edu (Philip Choi) Date: Fri, 16 Mar 2007 09:08:13 -0700 Subject: [Tioga-users] x11forwarding & preview Message-ID: Dear Tioga users, I am trying to run tioga via ssh but am finding that I cannot X11 forward non-x11 applications such as Preview or Safari (they pop up on the console rather than being forwarded to my remote machine). Has anyone else run into this and have a solution? I am having a surprisingly hard time finding a reasonably updated PDF viewer for X11, but I do have xdvi running, so I am wondering if it is possible to output dvi output as well as the pdf files for q quick view. Thanks, Phil ------------------------------------------------------------- This message has been scanned by Postini anti-virus software. From fourmond at gmail.com Fri Mar 16 12:31:18 2007 From: fourmond at gmail.com (Vincent Fourmond) Date: Fri, 16 Mar 2007 17:31:18 +0100 Subject: [Tioga-users] x11forwarding & preview In-Reply-To: References: Message-ID: <2e474d6f0703160931g1cc7d31ib72079b8d3dc9513@mail.gmail.com> On 3/16/07, Philip Choi wrote: > I am trying to run tioga via ssh but am finding that I cannot X11 forward > non-x11 applications such as Preview or Safari (they pop up on the console > rather than being forwarded to my remote machine). Has anyone else run into > this and have a solution? Have you tried --xpdf ? xpdf is a X11 application, and you'll be able to forward it then. You can also try gv (formerly known as ghostview). > I am having a surprisingly hard time finding a reasonably updated PDF viewer > for X11, but I do have xdvi running, so I am wondering if it is possible to > output dvi output as well as the pdf files for q quick view. You most probably wouldn't see the graphics in DVI output, as xdvi doesn't speak PDF. Cheers, Vincent From edder at tkwsping.nl Fri Mar 16 12:25:44 2007 From: edder at tkwsping.nl (edder) Date: Fri, 16 Mar 2007 17:25:44 +0100 (CET) Subject: [Tioga-users] x11forwarding & preview In-Reply-To: References: Message-ID: <53058.134.219.41.106.1174062344.squirrel@wm.tkwsping.nl> Hi, > I am having a surprisingly hard time finding a reasonably updated PDF > viewer > for X11, but I do have xdvi running The three that are actively developped are: acroread7(acrobat reader), evince and kpdf. My favourite is evince, although its rendering of figures is not that good. Acroread is the best in that aspect, but also starts very slowly (and only allows one instance per user). I have no experience with kpdf, but I think it uses the same rendering backend as evince. Edwin