Re: Bounding box problem (not caused by LyX but ghostscript)
Dear Olivier, The dummy.eps image you provided contains some text and a frame, at least that's the only thing I see in gsview and Corel Draw. Well, it was just a dummy file to demonstrate the bounding box problem. You are right, this will not show the other problem that turned up when drawing actual schematics and trying to give them usable and correctly displayed bounding boxes in LyX perusing this approach (using a windows batch script): C:\Programme\gs\gs8.54\bin\gswin32c.exe -dBATCH -dNOPAUSE -dEPSCrop -sDEVICE=epswrite -sOutputFile=%2 %1 which renders catastrophic results quality. I tried it with adding the -r switch and values up to about 6000, which did improve, but not to the quality I was accustomed to using the bbget script and old ESP version ghostscript. And values for switch -r somewhat above 6000 cannot be rendered by the YAP anymore In the end I made a brute force attack to the problem: I bought me a second hand harddisk for my old notebook (the HD can be changed within seconds) and reinstalled a stone age Debian Sarge including stone age ESP ghostscript V7.70.x on it. Using this proven setup - only to convert the EPS files with the bbget script and a similar one for mass-conversions - I get perfectly rendering printable output as well as perfectly displayed pictures in LyX again :-) While this may sound like a primitive and brute approach to the problem, it does the job and I can concentrate on actual writing on my book using LyX again. Maybe I will re-analyse the problem somewhen, comparing actual outputs of different bounding box fixing methods using a text- or binary-based diff program, but at the moment I am just happy to be able to continue with my book. Regards and thank you again for your patience, suggestions and help, Tom Schlangen -- mailto:[EMAIL PROTECTED]
Re: Bounding box problem (not caused by LyX but ghostscript)
Dear Olivier, The dummy.eps image you provided contains some text and a frame, at least that's the only thing I see in gsview and Corel Draw. Well, it was just a dummy file to demonstrate the bounding box problem. You are right, this will not show the other problem that turned up when drawing actual schematics and trying to give them usable and correctly displayed bounding boxes in LyX perusing this approach (using a windows batch script): C:\Programme\gs\gs8.54\bin\gswin32c.exe -dBATCH -dNOPAUSE -dEPSCrop -sDEVICE=epswrite -sOutputFile=%2 %1 which renders catastrophic results quality. I tried it with adding the -r switch and values up to about 6000, which did improve, but not to the quality I was accustomed to using the bbget script and old ESP version ghostscript. And values for switch -r somewhat above 6000 cannot be rendered by the YAP anymore In the end I made a brute force attack to the problem: I bought me a second hand harddisk for my old notebook (the HD can be changed within seconds) and reinstalled a stone age Debian Sarge including stone age ESP ghostscript V7.70.x on it. Using this proven setup - only to convert the EPS files with the bbget script and a similar one for mass-conversions - I get perfectly rendering printable output as well as perfectly displayed pictures in LyX again :-) While this may sound like a primitive and brute approach to the problem, it does the job and I can concentrate on actual writing on my book using LyX again. Maybe I will re-analyse the problem somewhen, comparing actual outputs of different bounding box fixing methods using a text- or binary-based diff program, but at the moment I am just happy to be able to continue with my book. Regards and thank you again for your patience, suggestions and help, Tom Schlangen -- mailto:[EMAIL PROTECTED]
Re: Bounding box problem (not caused by LyX but ghostscript)
Dear Olivier, > The dummy.eps image you provided contains some text and a frame, at > least that's the only thing I see in gsview and Corel Draw. Well, it was just a dummy file to demonstrate the bounding box problem. You are right, this will not show the other problem that turned up when drawing actual schematics and trying to give them usable and correctly displayed bounding boxes in LyX perusing this approach (using a windows batch script): C:\Programme\gs\gs8.54\bin\gswin32c.exe -dBATCH -dNOPAUSE -dEPSCrop -sDEVICE=epswrite -sOutputFile=%2 %1 which renders catastrophic results quality. I tried it with adding the -r switch and values up to about 6000, which did improve, but not to the quality I was accustomed to using the bbget script and old ESP version ghostscript. And values for switch -r somewhat above 6000 cannot be rendered by the YAP anymore In the end I made a "brute force" attack to the problem: I bought me a second hand harddisk for my old notebook (the HD can be changed within seconds) and reinstalled a stone age Debian Sarge including stone age ESP ghostscript V7.70.x on it. Using this proven setup - only to convert the EPS files with the bbget script and a similar one for mass-conversions - I get perfectly rendering printable output as well as perfectly displayed pictures in LyX again :-) While this may sound like a primitive and brute approach to the problem, it does the job and I can concentrate on actual writing on my book using LyX again. Maybe I will re-analyse the problem somewhen, comparing actual outputs of different bounding box fixing methods using a text- or binary-based diff program, but at the moment I am just happy to be able to continue with my book. Regards and thank you again for your patience, suggestions and help, Tom Schlangen -- mailto:[EMAIL PROTECTED]
Re: Bounding box problem (not caused by LyX but ghostscript)
Tom Schlangen wrote: Dear Olivier, I did the following in Windows (one line, mail agent may wrap it): gswin32c -dBATCH -dNOPAUSE -dEPSCrop -sDEVICE=epswrite -sOutputFile=dummy2.eps dummy.eps I tried this, but ... The resulting image displays fine in LyX with or without the clipping options While this is true regarding the bounding box problem, the resulting picture quality I get (LyX display and printout) is very poor compared to the other method I used so far. I am using AFPL Ghostscript V8.54, because it is installed on the Windows machine anyway. I will try some younger Windows versions of ghostscript tomorrow and report back. This morning I tried the GPL GS V8.61 windows binary using your suggested method too, sadly also giving bad quality/resolution results. Any suggestion to improve the output quality? Regards, Tom Schlangen Sorry for not having answered before, I was away from internet. The dummy.eps image you provided contains some text and a frame, at least that's the only thing I see in gsview and Corel Draw. It is vectorial. The dummy2.eps generated by gs 8.62 on Windows is also a vectorial image (much smaller, probably because the font is not embedded any more). So, the result is resolution-independent: Even if I zoom a lot, I do not see any resolution problem in the resulting dummy2.eps. So can you describe what you mean by bad quality? Here is the output I have from the command line when converting the dummy.eps using gs 8.62 on Windows XP: GPL Ghostscript 8.62 (2008-02-29) Copyright (C) 2008 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Loading NimbusMonL-Regu font from C:\Program Files\gs\fonts/n022003l.pfb... 2566848 1084635 13472696 12176047 2 done. Wild guess: the difference could come from the font. Do you have the same message ? There is one switch related to the fonts: -dNOPLATFONTS Perhaps it could help... gs 8.62 changelog specifically mentions some changes in font location. So perhaps you should try 8.62 on Windows(*). http://ghostscript.com/doc/current/Fonts.htm also mentions the following (section6): If you don't seem to be getting nice characters on the screen under MS Windows, you can try adding aliases to Fontmap, according to the documentation you'll find in there. Best regards, Olivier (*)Not easy to find from the website, the latest ghostscript can be found at: http://sourceforge.net/projects/ghostscript/
Re: Bounding box problem (not caused by LyX but ghostscript)
Tom Schlangen wrote: Dear Olivier, I did the following in Windows (one line, mail agent may wrap it): gswin32c -dBATCH -dNOPAUSE -dEPSCrop -sDEVICE=epswrite -sOutputFile=dummy2.eps dummy.eps I tried this, but ... The resulting image displays fine in LyX with or without the clipping options While this is true regarding the bounding box problem, the resulting picture quality I get (LyX display and printout) is very poor compared to the other method I used so far. I am using AFPL Ghostscript V8.54, because it is installed on the Windows machine anyway. I will try some younger Windows versions of ghostscript tomorrow and report back. This morning I tried the GPL GS V8.61 windows binary using your suggested method too, sadly also giving bad quality/resolution results. Any suggestion to improve the output quality? Regards, Tom Schlangen Sorry for not having answered before, I was away from internet. The dummy.eps image you provided contains some text and a frame, at least that's the only thing I see in gsview and Corel Draw. It is vectorial. The dummy2.eps generated by gs 8.62 on Windows is also a vectorial image (much smaller, probably because the font is not embedded any more). So, the result is resolution-independent: Even if I zoom a lot, I do not see any resolution problem in the resulting dummy2.eps. So can you describe what you mean by bad quality? Here is the output I have from the command line when converting the dummy.eps using gs 8.62 on Windows XP: GPL Ghostscript 8.62 (2008-02-29) Copyright (C) 2008 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Loading NimbusMonL-Regu font from C:\Program Files\gs\fonts/n022003l.pfb... 2566848 1084635 13472696 12176047 2 done. Wild guess: the difference could come from the font. Do you have the same message ? There is one switch related to the fonts: -dNOPLATFONTS Perhaps it could help... gs 8.62 changelog specifically mentions some changes in font location. So perhaps you should try 8.62 on Windows(*). http://ghostscript.com/doc/current/Fonts.htm also mentions the following (section6): If you don't seem to be getting nice characters on the screen under MS Windows, you can try adding aliases to Fontmap, according to the documentation you'll find in there. Best regards, Olivier (*)Not easy to find from the website, the latest ghostscript can be found at: http://sourceforge.net/projects/ghostscript/
Re: Bounding box problem (not caused by LyX but ghostscript)
Tom Schlangen wrote: Dear Olivier, I did the following in Windows (one line, mail agent may wrap it): gswin32c -dBATCH -dNOPAUSE -dEPSCrop -sDEVICE=epswrite -sOutputFile=dummy2.eps dummy.eps I tried this, but ... The resulting image displays fine in LyX with or without the clipping options While this is true regarding the bounding box problem, the resulting picture quality I get (LyX display and printout) is very poor compared to the other method I used so far. I am using AFPL Ghostscript V8.54, because it is installed on the Windows machine anyway. I will try some younger Windows versions of ghostscript tomorrow and report back. This morning I tried the GPL GS V8.61 windows binary using your suggested method too, sadly also giving bad quality/resolution results. Any suggestion to improve the output quality? Regards, Tom Schlangen Sorry for not having answered before, I was away from internet. The dummy.eps image you provided contains some text and a frame, at least that's the only thing I see in gsview and Corel Draw. It is vectorial. The dummy2.eps generated by gs 8.62 on Windows is also a vectorial image (much smaller, probably because the font is not embedded any more). So, the result is resolution-independent: Even if I zoom a lot, I do not see any resolution problem in the resulting dummy2.eps. So can you describe what you mean by "bad quality"? Here is the output I have from the command line when converting the dummy.eps using gs 8.62 on Windows XP: GPL Ghostscript 8.62 (2008-02-29) Copyright (C) 2008 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Loading NimbusMonL-Regu font from C:\Program Files\gs\fonts/n022003l.pfb... 2566848 1084635 13472696 12176047 2 done. Wild guess: the difference could come from the font. Do you have the same message ? There is one switch related to the fonts: -dNOPLATFONTS Perhaps it could help... gs 8.62 changelog specifically mentions some changes in font location. So perhaps you should try 8.62 on Windows(*). http://ghostscript.com/doc/current/Fonts.htm also mentions the following (section6): "If you don't seem to be getting nice characters on the screen under MS Windows, you can try adding aliases to Fontmap, according to the documentation you'll find in there." Best regards, Olivier (*)Not easy to find from the website, the latest ghostscript can be found at: http://sourceforge.net/projects/ghostscript/
Re: Bounding box problem (not caused by LyX but ghostscript)
Dear Olivier, I did the following in Windows (one line, mail agent may wrap it): gswin32c -dBATCH -dNOPAUSE -dEPSCrop -sDEVICE=epswrite -sOutputFile=dummy2.eps dummy.eps I tried this, but ... The resulting image displays fine in LyX with or without the clipping options While this is true regarding the bounding box problem, the resulting picture quality I get (LyX display and printout) is very poor compared to the other method I used so far. I am using AFPL Ghostscript V8.54, because it is installed on the Windows machine anyway. I will try some younger Windows versions of ghostscript tomorrow and report back. This morning I tried the GPL GS V8.61 windows binary using your suggested method too, sadly also giving bad quality/resolution results. Any suggestion to improve the output quality? Regards, Tom Schlangen --
Re: Bounding box problem (not caused by LyX but ghostscript)
Tom, you can specify the resolution with -r300 (that's the maximun) You may also consider embedding the fonts with: -dEmbeddAllFonts=true -dSubsetFonts=true You may find this interesting: http://wiki.ljackson.us/EPS_Optimization#Convert_.26_CleanUp_EPS Nicolás Tom Schlangen wrote: Dear Olivier, I did the following in Windows (one line, mail agent may wrap it): gswin32c -dBATCH -dNOPAUSE -dEPSCrop -sDEVICE=epswrite -sOutputFile=dummy2.eps dummy.eps I tried this, but ... The resulting image displays fine in LyX with or without the clipping options While this is true regarding the bounding box problem, the resulting picture quality I get (LyX display and printout) is very poor compared to the other method I used so far. I am using AFPL Ghostscript V8.54, because it is installed on the Windows machine anyway. I will try some younger Windows versions of ghostscript tomorrow and report back. This morning I tried the GPL GS V8.61 windows binary using your suggested method too, sadly also giving bad quality/resolution results. Any suggestion to improve the output quality? Regards, Tom Schlangen
Re: Bounding box problem (not caused by LyX but ghostscript)
Dear Nicolás, Tom, you can specify the resolution with -r300 (that's the maximun) Sorry, but that renders eps files with about 1/2 the size and horrible looking results. Trying -r4000 gives about the same filesize, but still horrible looking. You may find this interesting: http://wiki.ljackson.us/EPS_Optimization#Convert_.26_CleanUp_EPS I will have a look, thank you for the link! Regards, Tom Schlangen --
Re: Bounding box problem (not caused by LyX but ghostscript)
Dear LyX users, I would like to thank all of you who helped to partly solve the problem. For now, I will use one of the workarounds that will produce correctly printable ps or pdf output (after all, that´s most most important) and just ignore the ugly view in the LyX GUI/Editor. I don´t know what´s the real cause that lets LyX display included eps pictures uncropped/unclipped, maybe it is ImageMagick, maybe it is LyX itself. At least the problems I encountered were reproducible by others. If someone is able to track the (display-) problem down to LyX, I would suggest this person to file a bug report for that problem. I offer to supply suitable .eps files to demonstrate the problem. The display problem is present in both Win and Linux LyX versions and can be reliably demostrated using: * WindowsXP: Lyx V1.55-1, gs 8.62 (and lots of others), and current Imagemagick installed as per LyX bundle installer (and many others) and MikTex 2.7 * Linux: Debian lenny, LyX 1.55, gs 8.62, Imagemagik 7:6.3.7.9 and current TexLive. (Note, all versions used as available from current Debian lenny repository) Regards, Tom --
Re: Bounding box problem (not caused by LyX but ghostscript)
Dear Olivier, I did the following in Windows (one line, mail agent may wrap it): gswin32c -dBATCH -dNOPAUSE -dEPSCrop -sDEVICE=epswrite -sOutputFile=dummy2.eps dummy.eps I tried this, but ... The resulting image displays fine in LyX with or without the clipping options While this is true regarding the bounding box problem, the resulting picture quality I get (LyX display and printout) is very poor compared to the other method I used so far. I am using AFPL Ghostscript V8.54, because it is installed on the Windows machine anyway. I will try some younger Windows versions of ghostscript tomorrow and report back. This morning I tried the GPL GS V8.61 windows binary using your suggested method too, sadly also giving bad quality/resolution results. Any suggestion to improve the output quality? Regards, Tom Schlangen --
Re: Bounding box problem (not caused by LyX but ghostscript)
Tom, you can specify the resolution with -r300 (that's the maximun) You may also consider embedding the fonts with: -dEmbeddAllFonts=true -dSubsetFonts=true You may find this interesting: http://wiki.ljackson.us/EPS_Optimization#Convert_.26_CleanUp_EPS Nicolás Tom Schlangen wrote: Dear Olivier, I did the following in Windows (one line, mail agent may wrap it): gswin32c -dBATCH -dNOPAUSE -dEPSCrop -sDEVICE=epswrite -sOutputFile=dummy2.eps dummy.eps I tried this, but ... The resulting image displays fine in LyX with or without the clipping options While this is true regarding the bounding box problem, the resulting picture quality I get (LyX display and printout) is very poor compared to the other method I used so far. I am using AFPL Ghostscript V8.54, because it is installed on the Windows machine anyway. I will try some younger Windows versions of ghostscript tomorrow and report back. This morning I tried the GPL GS V8.61 windows binary using your suggested method too, sadly also giving bad quality/resolution results. Any suggestion to improve the output quality? Regards, Tom Schlangen
Re: Bounding box problem (not caused by LyX but ghostscript)
Dear Nicolás, Tom, you can specify the resolution with -r300 (that's the maximun) Sorry, but that renders eps files with about 1/2 the size and horrible looking results. Trying -r4000 gives about the same filesize, but still horrible looking. You may find this interesting: http://wiki.ljackson.us/EPS_Optimization#Convert_.26_CleanUp_EPS I will have a look, thank you for the link! Regards, Tom Schlangen --
Re: Bounding box problem (not caused by LyX but ghostscript)
Dear LyX users, I would like to thank all of you who helped to partly solve the problem. For now, I will use one of the workarounds that will produce correctly printable ps or pdf output (after all, that´s most most important) and just ignore the ugly view in the LyX GUI/Editor. I don´t know what´s the real cause that lets LyX display included eps pictures uncropped/unclipped, maybe it is ImageMagick, maybe it is LyX itself. At least the problems I encountered were reproducible by others. If someone is able to track the (display-) problem down to LyX, I would suggest this person to file a bug report for that problem. I offer to supply suitable .eps files to demonstrate the problem. The display problem is present in both Win and Linux LyX versions and can be reliably demostrated using: * WindowsXP: Lyx V1.55-1, gs 8.62 (and lots of others), and current Imagemagick installed as per LyX bundle installer (and many others) and MikTex 2.7 * Linux: Debian lenny, LyX 1.55, gs 8.62, Imagemagik 7:6.3.7.9 and current TexLive. (Note, all versions used as available from current Debian lenny repository) Regards, Tom --
Re: Bounding box problem (not caused by LyX but ghostscript)
Dear Olivier, >> I did the following in Windows (one line, mail agent may wrap it): >> gswin32c -dBATCH -dNOPAUSE -dEPSCrop -sDEVICE=epswrite >> -sOutputFile=dummy2.eps dummy.eps > I tried this, but ... >> The resulting image displays fine in LyX with or without the >> clipping options > While this is true regarding the bounding box problem, the > resulting picture quality I get (LyX display and printout) is very > poor compared to the other method I used so far. I am using AFPL > Ghostscript V8.54, because it is installed on the Windows machine anyway. > I will try some younger Windows versions of ghostscript tomorrow and report > back. This morning I tried the GPL GS V8.61 windows binary using your suggested method too, sadly also giving bad quality/resolution results. Any suggestion to improve the output quality? Regards, Tom Schlangen --
Re: Bounding box problem (not caused by LyX but ghostscript)
Tom, you can specify the resolution with -r300 (that's the maximun) You may also consider embedding the fonts with: -dEmbeddAllFonts=true -dSubsetFonts=true You may find this interesting: http://wiki.ljackson.us/EPS_Optimization#Convert_.26_CleanUp_EPS Nicolás Tom Schlangen wrote: Dear Olivier, I did the following in Windows (one line, mail agent may wrap it): gswin32c -dBATCH -dNOPAUSE -dEPSCrop -sDEVICE=epswrite -sOutputFile=dummy2.eps dummy.eps I tried this, but ... The resulting image displays fine in LyX with or without the clipping options While this is true regarding the bounding box problem, the resulting picture quality I get (LyX display and printout) is very poor compared to the other method I used so far. I am using AFPL Ghostscript V8.54, because it is installed on the Windows machine anyway. I will try some younger Windows versions of ghostscript tomorrow and report back. This morning I tried the GPL GS V8.61 windows binary using your suggested method too, sadly also giving bad quality/resolution results. Any suggestion to improve the output quality? Regards, Tom Schlangen
Re: Bounding box problem (not caused by LyX but ghostscript)
Dear Nicolás, > Tom, you can specify the resolution with -r300 (that's the maximun) Sorry, but that renders eps files with about 1/2 the size and horrible looking results. Trying -r4000 gives about the same filesize, but still horrible looking. > You may find this interesting: > http://wiki.ljackson.us/EPS_Optimization#Convert_.26_CleanUp_EPS I will have a look, thank you for the link! Regards, Tom Schlangen --
Re: Bounding box problem (not caused by LyX but ghostscript)
Dear LyX users, I would like to thank all of you who helped to partly solve the problem. For now, I will use one of the workarounds that will produce correctly printable ps or pdf output (after all, that´s most most important) and just ignore the ugly view in the LyX GUI/Editor. I don´t know what´s the real cause that lets LyX display included eps pictures uncropped/unclipped, maybe it is ImageMagick, maybe it is LyX itself. At least the problems I encountered were reproducible by others. If someone is able to track the (display-) problem down to LyX, I would suggest this person to file a bug report for that problem. I offer to supply suitable .eps files to demonstrate the problem. The display problem is present in both Win and Linux LyX versions and can be reliably demostrated using: * WindowsXP: Lyx V1.55-1, gs 8.62 (and lots of others), and current Imagemagick installed as per LyX bundle installer (and many others) and MikTex 2.7 * Linux: Debian lenny, LyX 1.55, gs 8.62, Imagemagik 7:6.3.7.9 and current TexLive. (Note, all versions used as available from current Debian lenny repository) Regards, Tom --
Re: Bounding box problem (not caused by LyX but ghostscript)
Dear Olivier, thank you very much for your extensive answer! Now, I do not really understand why you need such a complex workflow. Why do you need to go in Linux ? That´s just because so far I didn´t know better how to deal with bounding boxes - and I have a Linux machine running anyway. I did the following in Windows (one line, mail agent may wrap it): gswin32c -dBATCH -dNOPAUSE -dEPSCrop -sDEVICE=epswrite -sOutputFile=dummy2.eps dummy.eps I tried this, but ... The resulting image displays fine in LyX with or without the clipping options While this is true regarding the bounding box problem, the resulting picture quality I get (LyX display and printout) is very poor compared to the other method I used so far. I am using AFPL Ghostscript V8.54, because it is installed on the Windows machine anyway. I will try some younger Windows versions of ghostscript tomorrow and report back. Maybe there are additional parameters that could be passed to gswin32c.exe to improve the picture quality? Thank you again, Tom Schlangen -- mailto:[EMAIL PROTECTED]
Re: Bounding box problem (not caused by LyX but ghostscript)
Dear Olivier, thank you very much for your extensive answer! Now, I do not really understand why you need such a complex workflow. Why do you need to go in Linux ? That´s just because so far I didn´t know better how to deal with bounding boxes - and I have a Linux machine running anyway. I did the following in Windows (one line, mail agent may wrap it): gswin32c -dBATCH -dNOPAUSE -dEPSCrop -sDEVICE=epswrite -sOutputFile=dummy2.eps dummy.eps I tried this, but ... The resulting image displays fine in LyX with or without the clipping options While this is true regarding the bounding box problem, the resulting picture quality I get (LyX display and printout) is very poor compared to the other method I used so far. I am using AFPL Ghostscript V8.54, because it is installed on the Windows machine anyway. I will try some younger Windows versions of ghostscript tomorrow and report back. Maybe there are additional parameters that could be passed to gswin32c.exe to improve the picture quality? Thank you again, Tom Schlangen -- mailto:[EMAIL PROTECTED]
Re: Bounding box problem (not caused by LyX but ghostscript)
Dear Olivier, thank you very much for your extensive answer! > Now, I do not really understand why you need such a > complex workflow. Why do you need to go in Linux ? That´s just because so far I didn´t know better how to deal with bounding boxes - and I have a Linux machine running anyway. > I did the following in Windows (one line, mail agent may wrap it): > gswin32c -dBATCH -dNOPAUSE -dEPSCrop -sDEVICE=epswrite > -sOutputFile=dummy2.eps dummy.eps I tried this, but ... > The resulting image displays fine in LyX with or without the > clipping options While this is true regarding the bounding box problem, the resulting picture quality I get (LyX display and printout) is very poor compared to the other method I used so far. I am using AFPL Ghostscript V8.54, because it is installed on the Windows machine anyway. I will try some younger Windows versions of ghostscript tomorrow and report back. Maybe there are additional parameters that could be passed to gswin32c.exe to improve the picture quality? Thank you again, Tom Schlangen -- mailto:[EMAIL PROTECTED]
Re: Bounding box problem (not caused by LyX but ghostscript)
Well, it seems that I have a lucky configuration/installation in my machine. As I already said, I have LyX 1.5.5, ImageMagick-6.2.7-Q16, AFPL Ghostscript 8.14 and GSview 4.6, Miktex 2.7 and Acrobat Reader 7. For me, all images except dummy_bbget_gs862.eps (which GsView reports errors when trying to open it) are correctly visualized in LyX and in pdf, with and w/o the clipping option selected. Could someone explain what LyX really does when the cclipping option is selected? Nicolás Olivier Ripoll wrote: Hi, I tried your eps files in LyX 1.6 beta3 under windows XP. I use Adobe reader 8 for pdf (generated by pdflatex IIRC) and gsview 4.9 / ghostscript 8.62 for postscript viewing. It does work better for me that for you it seems (you may suffer from an outdated/buggy imagemagick). I tried the images without checking the option to clip to the bounding box, and with it (ion that case, also with clicking on the button to get the size from the file). Tom Schlangen wrote: Okay, I have prepared some files to illustrate the problem, so other have a chance to verify. Output from bbget, using esp-gs v7.70.x: http://www.ines.mynetcologne.de/dummy_bbget_espgs770.eps (64k) (works!) displays fine in LyX with or without the clipping options pdf/ps/dvi output is fine Output from bbget, using gs v8.62: http://www.ines.mynetcologne.de/dummy_bbget_gs862.eps (64k) (doesn´t work) gsview 4.9 cannot even open this file... it reports errors. displays wrong in LyX with and without the clipping options. LyX cannot actually read the bounding box at all. does not display in pdf (blank pages), result in errors in gsview and dvi viewer. Output from gsview v4.7, using option PS to EPS, also checkmarked Automatically calculate Baounding Box. BTW, using gsview v4.9 gives the same result. http://www.ines.mynetcologne.de/dummy_gsview47.eps (64k) (doesn´t work) displays wrong (full page) in LyX with or without the clipping options pdf/ps/dvi is fine though Output from ps2eps v1.64 utility, parameters as suggested by http://www.tm.uka.de/~bless/ps2eps.html: http://www.ines.mynetcologne.de/dummy_ps2eps164.eps (64k) (doesn´t work) displays wrong (full page) in LyX without the clipping options and fine with it. ps/dvi are correct pdf is correct without the clipping option, but the figure is missing when using the clipping option (yep... it works without and _not_ with). Now, I do not really understand why you need such a complex workflow. Why do you need to go in Linux ? I did the following in Windows (one line, mail agent may wrap it): gswin32c -dBATCH -dNOPAUSE -dEPSCrop -sDEVICE=epswrite -sOutputFile=dummy2.eps dummy.eps (You need to have gs in your path) The resulting image displays fine in LyX with or without the clipping options, and ps/pdf/dvi is fine also. So my conclusion is : don't care about what LyX displays, care about the final result, and most encapsulated postscripts (eps) are fine there. And also, use ghostscript 8.62 on windows. Regards, Tom Schlangen Regards, Olivier PS: personally, I use pdf instead of eps: it takes less disc space, you can edit easily with inkscape, everyone can view them, and last but not least, it is the base format for pdf(La)TeX which is nicer (pdf bookmarks).
Re: Bounding box problem (not caused by LyX but ghostscript)
Well, it seems that I have a lucky configuration/installation in my machine. As I already said, I have LyX 1.5.5, ImageMagick-6.2.7-Q16, AFPL Ghostscript 8.14 and GSview 4.6, Miktex 2.7 and Acrobat Reader 7. For me, all images except dummy_bbget_gs862.eps (which GsView reports errors when trying to open it) are correctly visualized in LyX and in pdf, with and w/o the clipping option selected. Could someone explain what LyX really does when the cclipping option is selected? Nicolás Olivier Ripoll wrote: Hi, I tried your eps files in LyX 1.6 beta3 under windows XP. I use Adobe reader 8 for pdf (generated by pdflatex IIRC) and gsview 4.9 / ghostscript 8.62 for postscript viewing. It does work better for me that for you it seems (you may suffer from an outdated/buggy imagemagick). I tried the images without checking the option to clip to the bounding box, and with it (ion that case, also with clicking on the button to get the size from the file). Tom Schlangen wrote: Okay, I have prepared some files to illustrate the problem, so other have a chance to verify. Output from bbget, using esp-gs v7.70.x: http://www.ines.mynetcologne.de/dummy_bbget_espgs770.eps (64k) (works!) displays fine in LyX with or without the clipping options pdf/ps/dvi output is fine Output from bbget, using gs v8.62: http://www.ines.mynetcologne.de/dummy_bbget_gs862.eps (64k) (doesn´t work) gsview 4.9 cannot even open this file... it reports errors. displays wrong in LyX with and without the clipping options. LyX cannot actually read the bounding box at all. does not display in pdf (blank pages), result in errors in gsview and dvi viewer. Output from gsview v4.7, using option PS to EPS, also checkmarked Automatically calculate Baounding Box. BTW, using gsview v4.9 gives the same result. http://www.ines.mynetcologne.de/dummy_gsview47.eps (64k) (doesn´t work) displays wrong (full page) in LyX with or without the clipping options pdf/ps/dvi is fine though Output from ps2eps v1.64 utility, parameters as suggested by http://www.tm.uka.de/~bless/ps2eps.html: http://www.ines.mynetcologne.de/dummy_ps2eps164.eps (64k) (doesn´t work) displays wrong (full page) in LyX without the clipping options and fine with it. ps/dvi are correct pdf is correct without the clipping option, but the figure is missing when using the clipping option (yep... it works without and _not_ with). Now, I do not really understand why you need such a complex workflow. Why do you need to go in Linux ? I did the following in Windows (one line, mail agent may wrap it): gswin32c -dBATCH -dNOPAUSE -dEPSCrop -sDEVICE=epswrite -sOutputFile=dummy2.eps dummy.eps (You need to have gs in your path) The resulting image displays fine in LyX with or without the clipping options, and ps/pdf/dvi is fine also. So my conclusion is : don't care about what LyX displays, care about the final result, and most encapsulated postscripts (eps) are fine there. And also, use ghostscript 8.62 on windows. Regards, Tom Schlangen Regards, Olivier PS: personally, I use pdf instead of eps: it takes less disc space, you can edit easily with inkscape, everyone can view them, and last but not least, it is the base format for pdf(La)TeX which is nicer (pdf bookmarks).
Re: Bounding box problem (not caused by LyX but ghostscript)
Well, it seems that I have a lucky configuration/installation in my machine. As I already said, I have LyX 1.5.5, ImageMagick-6.2.7-Q16, AFPL Ghostscript 8.14 and GSview 4.6, Miktex 2.7 and Acrobat Reader 7. For me, all images except dummy_bbget_gs862.eps (which GsView reports errors when trying to open it) are correctly visualized in LyX and in pdf, with and w/o the clipping option selected. Could someone explain what LyX really does when the cclipping option is selected? Nicolás Olivier Ripoll wrote: Hi, I tried your eps files in LyX 1.6 beta3 under windows XP. I use Adobe reader 8 for pdf (generated by pdflatex IIRC) and gsview 4.9 / ghostscript 8.62 for postscript viewing. It does work better for me that for you it seems (you may suffer from an outdated/buggy imagemagick). I tried the images without checking the option to clip to the bounding box, and with it (ion that case, also with clicking on the button to get the size from the file). Tom Schlangen wrote: Okay, I have prepared some files to illustrate the problem, so other have a chance to verify. Output from bbget, using esp-gs v7.70.x: http://www.ines.mynetcologne.de/dummy_bbget_espgs770.eps (64k) (works!) displays fine in LyX with or without the clipping options pdf/ps/dvi output is fine Output from bbget, using gs v8.62: http://www.ines.mynetcologne.de/dummy_bbget_gs862.eps (64k) (doesn´t work) gsview 4.9 cannot even open this file... it reports errors. displays wrong in LyX with and without the clipping options. LyX cannot actually read the bounding box at all. does not display in pdf (blank pages), result in errors in gsview and dvi viewer. Output from gsview v4.7, using option PS to EPS, also checkmarked "Automatically calculate Baounding Box". BTW, using gsview v4.9 gives the same result. http://www.ines.mynetcologne.de/dummy_gsview47.eps (64k) (doesn´t work) displays wrong (full page) in LyX with or without the clipping options pdf/ps/dvi is fine though Output from ps2eps v1.64 utility, parameters as suggested by http://www.tm.uka.de/~bless/ps2eps.html: http://www.ines.mynetcologne.de/dummy_ps2eps164.eps (64k) (doesn´t work) displays wrong (full page) in LyX without the clipping options and fine with it. ps/dvi are correct pdf is correct without the clipping option, but the figure is missing when using the clipping option (yep... it works without and _not_ with). Now, I do not really understand why you need such a complex workflow. Why do you need to go in Linux ? I did the following in Windows (one line, mail agent may wrap it): gswin32c -dBATCH -dNOPAUSE -dEPSCrop -sDEVICE=epswrite -sOutputFile=dummy2.eps dummy.eps (You need to have gs in your path) The resulting image displays fine in LyX with or without the clipping options, and ps/pdf/dvi is fine also. So my conclusion is : don't care about what LyX displays, care about the final result, and most encapsulated postscripts (eps) are fine there. And also, use ghostscript 8.62 on windows. Regards, Tom Schlangen Regards, Olivier PS: personally, I use pdf instead of eps: it takes less disc space, you can edit easily with inkscape, everyone can view them, and last but not least, it is the base format for pdf(La)TeX which is nicer (pdf bookmarks).
Re: Bounding box problem (not caused by LyX but ghostscript)
Hi, I tried your eps files in LyX 1.6 beta3 under windows XP. I use Adobe reader 8 for pdf (generated by pdflatex IIRC) and gsview 4.9 / ghostscript 8.62 for postscript viewing. It does work better for me that for you it seems (you may suffer from an outdated/buggy imagemagick). I tried the images without checking the option to clip to the bounding box, and with it (ion that case, also with clicking on the button to get the size from the file). Tom Schlangen wrote: Okay, I have prepared some files to illustrate the problem, so other have a chance to verify. Output from bbget, using esp-gs v7.70.x: http://www.ines.mynetcologne.de/dummy_bbget_espgs770.eps (64k) (works!) displays fine in LyX with or without the clipping options pdf/ps/dvi output is fine Output from bbget, using gs v8.62: http://www.ines.mynetcologne.de/dummy_bbget_gs862.eps (64k) (doesn´t work) gsview 4.9 cannot even open this file... it reports errors. displays wrong in LyX with and without the clipping options. LyX cannot actually read the bounding box at all. does not display in pdf (blank pages), result in errors in gsview and dvi viewer. Output from gsview v4.7, using option PS to EPS, also checkmarked Automatically calculate Baounding Box. BTW, using gsview v4.9 gives the same result. http://www.ines.mynetcologne.de/dummy_gsview47.eps (64k) (doesn´t work) displays wrong (full page) in LyX with or without the clipping options pdf/ps/dvi is fine though Output from ps2eps v1.64 utility, parameters as suggested by http://www.tm.uka.de/~bless/ps2eps.html: http://www.ines.mynetcologne.de/dummy_ps2eps164.eps (64k) (doesn´t work) displays wrong (full page) in LyX without the clipping options and fine with it. ps/dvi are correct pdf is correct without the clipping option, but the figure is missing when using the clipping option (yep... it works without and _not_ with). Now, I do not really understand why you need such a complex workflow. Why do you need to go in Linux ? I did the following in Windows (one line, mail agent may wrap it): gswin32c -dBATCH -dNOPAUSE -dEPSCrop -sDEVICE=epswrite -sOutputFile=dummy2.eps dummy.eps (You need to have gs in your path) The resulting image displays fine in LyX with or without the clipping options, and ps/pdf/dvi is fine also. So my conclusion is : don't care about what LyX displays, care about the final result, and most encapsulated postscripts (eps) are fine there. And also, use ghostscript 8.62 on windows. Regards, Tom Schlangen Regards, Olivier PS: personally, I use pdf instead of eps: it takes less disc space, you can edit easily with inkscape, everyone can view them, and last but not least, it is the base format for pdf(La)TeX which is nicer (pdf bookmarks).
Re: Bounding box problem (not caused by LyX but ghostscript)
Hi, I tried your eps files in LyX 1.6 beta3 under windows XP. I use Adobe reader 8 for pdf (generated by pdflatex IIRC) and gsview 4.9 / ghostscript 8.62 for postscript viewing. It does work better for me that for you it seems (you may suffer from an outdated/buggy imagemagick). I tried the images without checking the option to clip to the bounding box, and with it (ion that case, also with clicking on the button to get the size from the file). Tom Schlangen wrote: Okay, I have prepared some files to illustrate the problem, so other have a chance to verify. Output from bbget, using esp-gs v7.70.x: http://www.ines.mynetcologne.de/dummy_bbget_espgs770.eps (64k) (works!) displays fine in LyX with or without the clipping options pdf/ps/dvi output is fine Output from bbget, using gs v8.62: http://www.ines.mynetcologne.de/dummy_bbget_gs862.eps (64k) (doesn´t work) gsview 4.9 cannot even open this file... it reports errors. displays wrong in LyX with and without the clipping options. LyX cannot actually read the bounding box at all. does not display in pdf (blank pages), result in errors in gsview and dvi viewer. Output from gsview v4.7, using option PS to EPS, also checkmarked Automatically calculate Baounding Box. BTW, using gsview v4.9 gives the same result. http://www.ines.mynetcologne.de/dummy_gsview47.eps (64k) (doesn´t work) displays wrong (full page) in LyX with or without the clipping options pdf/ps/dvi is fine though Output from ps2eps v1.64 utility, parameters as suggested by http://www.tm.uka.de/~bless/ps2eps.html: http://www.ines.mynetcologne.de/dummy_ps2eps164.eps (64k) (doesn´t work) displays wrong (full page) in LyX without the clipping options and fine with it. ps/dvi are correct pdf is correct without the clipping option, but the figure is missing when using the clipping option (yep... it works without and _not_ with). Now, I do not really understand why you need such a complex workflow. Why do you need to go in Linux ? I did the following in Windows (one line, mail agent may wrap it): gswin32c -dBATCH -dNOPAUSE -dEPSCrop -sDEVICE=epswrite -sOutputFile=dummy2.eps dummy.eps (You need to have gs in your path) The resulting image displays fine in LyX with or without the clipping options, and ps/pdf/dvi is fine also. So my conclusion is : don't care about what LyX displays, care about the final result, and most encapsulated postscripts (eps) are fine there. And also, use ghostscript 8.62 on windows. Regards, Tom Schlangen Regards, Olivier PS: personally, I use pdf instead of eps: it takes less disc space, you can edit easily with inkscape, everyone can view them, and last but not least, it is the base format for pdf(La)TeX which is nicer (pdf bookmarks).
Re: Bounding box problem (not caused by LyX but ghostscript)
Hi, I tried your eps files in LyX 1.6 beta3 under windows XP. I use Adobe reader 8 for pdf (generated by pdflatex IIRC) and gsview 4.9 / ghostscript 8.62 for postscript viewing. It does work better for me that for you it seems (you may suffer from an outdated/buggy imagemagick). I tried the images without checking the option to clip to the bounding box, and with it (ion that case, also with clicking on the button to get the size from the file). Tom Schlangen wrote: Okay, I have prepared some files to illustrate the problem, so other have a chance to verify. Output from bbget, using esp-gs v7.70.x: http://www.ines.mynetcologne.de/dummy_bbget_espgs770.eps (64k) (works!) displays fine in LyX with or without the clipping options pdf/ps/dvi output is fine Output from bbget, using gs v8.62: http://www.ines.mynetcologne.de/dummy_bbget_gs862.eps (64k) (doesn´t work) gsview 4.9 cannot even open this file... it reports errors. displays wrong in LyX with and without the clipping options. LyX cannot actually read the bounding box at all. does not display in pdf (blank pages), result in errors in gsview and dvi viewer. Output from gsview v4.7, using option PS to EPS, also checkmarked "Automatically calculate Baounding Box". BTW, using gsview v4.9 gives the same result. http://www.ines.mynetcologne.de/dummy_gsview47.eps (64k) (doesn´t work) displays wrong (full page) in LyX with or without the clipping options pdf/ps/dvi is fine though Output from ps2eps v1.64 utility, parameters as suggested by http://www.tm.uka.de/~bless/ps2eps.html: http://www.ines.mynetcologne.de/dummy_ps2eps164.eps (64k) (doesn´t work) displays wrong (full page) in LyX without the clipping options and fine with it. ps/dvi are correct pdf is correct without the clipping option, but the figure is missing when using the clipping option (yep... it works without and _not_ with). Now, I do not really understand why you need such a complex workflow. Why do you need to go in Linux ? I did the following in Windows (one line, mail agent may wrap it): gswin32c -dBATCH -dNOPAUSE -dEPSCrop -sDEVICE=epswrite -sOutputFile=dummy2.eps dummy.eps (You need to have gs in your path) The resulting image displays fine in LyX with or without the clipping options, and ps/pdf/dvi is fine also. So my conclusion is : don't care about what LyX displays, care about the final result, and most encapsulated postscripts (eps) are fine there. And also, use ghostscript 8.62 on windows. Regards, Tom Schlangen Regards, Olivier PS: personally, I use pdf instead of eps: it takes less disc space, you can edit easily with inkscape, everyone can view them, and last but not least, it is the base format for pdf(La)TeX which is nicer (pdf bookmarks).
Re: Bounding box problem (not caused by LyX but ghostscript)
Dear Mukhtar, Since I have got a working ps2eps, you could send me one example eps file so Thank you for offering! Meanwhile I tested ps2eps V1.64 myself. While it calculates the bounding box exactly (great!) the clipping to bounding box option as per the Lyx dialogue doesn´t work correctly anymore: While the bbox values can be read from the file by Lyx, the picture doesn´t get clipped to the tile but the whole page is shown. I am really stuck with this problem Tom Schlangen --
Re: Bounding box problem (not caused by LyX but ghostscript)
Okay, I have prepared some files to illustrate the problem, so other have a chance to verify. .EPS output file of the circuit drawing program I use: http://www.ines.mynetcologne.de/dummy.eps (64k) bbget script from http://silas.psfc.mit.edu/elec_fig/ : http://www.ines.mynetcologne.de/bbget Output from bbget, using esp-gs v7.70.x: http://www.ines.mynetcologne.de/dummy_bbget_espgs770.eps (64k) (works!) Output from bbget, using gs v8.62: http://www.ines.mynetcologne.de/dummy_bbget_gs862.eps (64k) (doesn´t work) Output from gsview v4.7, using option PS to EPS, also checkmarked Automatically calculate Baounding Box. BTW, using gsview v4.9 gives the same result. http://www.ines.mynetcologne.de/dummy_gsview47.eps (64k) (doesn´t work) Output from ps2eps v1.64 utility, parameters as suggested by http://www.tm.uka.de/~bless/ps2eps.html: http://www.ines.mynetcologne.de/dummy_ps2eps164.eps (64k) (doesn´t work) Just import those example eps files dummy_bbget_espgs770.eps (64k) (works!) dummy_bbget_gs862.eps (64k) (doesn´t work) dummy_gsview47.eps (64k) (doesn´t work) dummy_ps2eps164.eps (64k) (doesn´t work) to LyX always using the Clip to bounding box and Read from file options in the dialog, and have a look at the output. You will see the only file giving correct clipping is the one with the bounding box values generated by bbget and an old, discontinued ESP ghostscript version. Now, everybody can say that is not a problem of LyX, but on the other hand, the LyX image import dialogue is left pretty useless if there is only some certain script/program combination being able to generate bounding boxes that LyX is able to deal with? Regards, Tom Schlangen --
Re: Bounding box problem (not caused by LyX but ghostscript)
I you select the Clip to bounding box option and get the bounding box from the file, the result will be the same as if you simply do not select the Clip to bounding box option (in my experience, at least). Now, regarding your eps files, are the last two or three eps files really useless? I can see that the only difference with the ok file is that their bounding box is one point bigger in both th evertical and horizontal dimensions. Is that really a problem? What you get is a white frame of less than 1mm of thickness, and since I assume your paper is white... no one will notice such fame! Just my opinion. Cheers, Nicolás Tom Schlangen wrote: Okay, I have prepared some files to illustrate the problem, so other have a chance to verify. .EPS output file of the circuit drawing program I use: http://www.ines.mynetcologne.de/dummy.eps (64k) bbget script from http://silas.psfc.mit.edu/elec_fig/ : http://www.ines.mynetcologne.de/bbget Output from bbget, using esp-gs v7.70.x: http://www.ines.mynetcologne.de/dummy_bbget_espgs770.eps (64k) (works!) Output from bbget, using gs v8.62: http://www.ines.mynetcologne.de/dummy_bbget_gs862.eps (64k) (doesn´t work) Output from gsview v4.7, using option PS to EPS, also checkmarked Automatically calculate Baounding Box. BTW, using gsview v4.9 gives the same result. http://www.ines.mynetcologne.de/dummy_gsview47.eps (64k) (doesn´t work) Output from ps2eps v1.64 utility, parameters as suggested by http://www.tm.uka.de/~bless/ps2eps.html: http://www.ines.mynetcologne.de/dummy_ps2eps164.eps (64k) (doesn´t work) Just import those example eps files dummy_bbget_espgs770.eps (64k) (works!) dummy_bbget_gs862.eps (64k) (doesn´t work) dummy_gsview47.eps (64k) (doesn´t work) dummy_ps2eps164.eps (64k) (doesn´t work) to LyX always using the Clip to bounding box and Read from file options in the dialog, and have a look at the output. You will see the only file giving correct clipping is the one with the bounding box values generated by bbget and an old, discontinued ESP ghostscript version. Now, everybody can say that is not a problem of LyX, but on the other hand, the LyX image import dialogue is left pretty useless if there is only some certain script/program combination being able to generate bounding boxes that LyX is able to deal with? Regards, Tom Schlangen
Re: Bounding box problem (not caused by LyX but ghostscript)
Dear Nicolás, Now, regarding your eps files, are the last two or three eps files really useless? I can see that the only difference with the ok file is that their bounding box is one point bigger in both th evertical and horizontal dimensions. Is that really a problem? Good point - I must admit I didn´t check DVI output (which is correct) before, because it looks wrong already in the LyX GUI editor - both my installed Windows and Linux LyX versions (V1.55 for both OS) still show the wide border around the bounding box in the LyX GUI/Editor for both files. That is not a big Problem, but just a nuisance in the LyX GUI editor - which is not the case when bounding boxes are computed by the bbget/ESP-gs combo. Now I am wondering who is the transgressor regarding the wrong display (with white borders): ImageMagick or LyX itself? Anyway, thank you for the workaround regarding the old ghostscript version and let´s hope the LyX GUI display problem will be solved soon. Regards, Tom Schlangen --
Re: Bounding box problem (not caused by LyX but ghostscript)
Dear Tom, I checked your figures in LyX and could verify your problem. It seems that imagemagick is culprit. I converted your eps files to pdf and included that in LyX. That was shown perfectly clipped. So you could consider switchin gto pdflatex, converting all your eps files by a script using epstopdf command from MiKTeX. That, ofcourse, will only be possible if you are not using pstricks. Mukhtar
Re: Bounding box problem (not caused by LyX but ghostscript)
Do you mean that when the eps is displayed in LyX is not clipped, as it would happen if it was opened with Gsview? In my machine I can see the clipped figure both in LyX and in the generated pdf/ps/dvi. I have LyX 1.5.5, ImageMagick-6.2.7-Q16, AFPL Ghostscript 8.14 and GSview 4.6. Nicolás Mukhtar Ullah wrote: Dear Tom, I checked your figures in LyX and could verify your problem. It seems that imagemagick is culprit. I converted your eps files to pdf and included that in LyX. That was shown perfectly clipped. So you could consider switchin gto pdflatex, converting all your eps files by a script using epstopdf command from MiKTeX. That, ofcourse, will only be possible if you are not using pstricks. Mukhtar
Re: Bounding box problem (not caused by LyX but ghostscript)
Dear Mukhtar, Since I have got a working ps2eps, you could send me one example eps file so Thank you for offering! Meanwhile I tested ps2eps V1.64 myself. While it calculates the bounding box exactly (great!) the clipping to bounding box option as per the Lyx dialogue doesn´t work correctly anymore: While the bbox values can be read from the file by Lyx, the picture doesn´t get clipped to the tile but the whole page is shown. I am really stuck with this problem Tom Schlangen --
Re: Bounding box problem (not caused by LyX but ghostscript)
Okay, I have prepared some files to illustrate the problem, so other have a chance to verify. .EPS output file of the circuit drawing program I use: http://www.ines.mynetcologne.de/dummy.eps (64k) bbget script from http://silas.psfc.mit.edu/elec_fig/ : http://www.ines.mynetcologne.de/bbget Output from bbget, using esp-gs v7.70.x: http://www.ines.mynetcologne.de/dummy_bbget_espgs770.eps (64k) (works!) Output from bbget, using gs v8.62: http://www.ines.mynetcologne.de/dummy_bbget_gs862.eps (64k) (doesn´t work) Output from gsview v4.7, using option PS to EPS, also checkmarked Automatically calculate Baounding Box. BTW, using gsview v4.9 gives the same result. http://www.ines.mynetcologne.de/dummy_gsview47.eps (64k) (doesn´t work) Output from ps2eps v1.64 utility, parameters as suggested by http://www.tm.uka.de/~bless/ps2eps.html: http://www.ines.mynetcologne.de/dummy_ps2eps164.eps (64k) (doesn´t work) Just import those example eps files dummy_bbget_espgs770.eps (64k) (works!) dummy_bbget_gs862.eps (64k) (doesn´t work) dummy_gsview47.eps (64k) (doesn´t work) dummy_ps2eps164.eps (64k) (doesn´t work) to LyX always using the Clip to bounding box and Read from file options in the dialog, and have a look at the output. You will see the only file giving correct clipping is the one with the bounding box values generated by bbget and an old, discontinued ESP ghostscript version. Now, everybody can say that is not a problem of LyX, but on the other hand, the LyX image import dialogue is left pretty useless if there is only some certain script/program combination being able to generate bounding boxes that LyX is able to deal with? Regards, Tom Schlangen --
Re: Bounding box problem (not caused by LyX but ghostscript)
I you select the Clip to bounding box option and get the bounding box from the file, the result will be the same as if you simply do not select the Clip to bounding box option (in my experience, at least). Now, regarding your eps files, are the last two or three eps files really useless? I can see that the only difference with the ok file is that their bounding box is one point bigger in both th evertical and horizontal dimensions. Is that really a problem? What you get is a white frame of less than 1mm of thickness, and since I assume your paper is white... no one will notice such fame! Just my opinion. Cheers, Nicolás Tom Schlangen wrote: Okay, I have prepared some files to illustrate the problem, so other have a chance to verify. .EPS output file of the circuit drawing program I use: http://www.ines.mynetcologne.de/dummy.eps (64k) bbget script from http://silas.psfc.mit.edu/elec_fig/ : http://www.ines.mynetcologne.de/bbget Output from bbget, using esp-gs v7.70.x: http://www.ines.mynetcologne.de/dummy_bbget_espgs770.eps (64k) (works!) Output from bbget, using gs v8.62: http://www.ines.mynetcologne.de/dummy_bbget_gs862.eps (64k) (doesn´t work) Output from gsview v4.7, using option PS to EPS, also checkmarked Automatically calculate Baounding Box. BTW, using gsview v4.9 gives the same result. http://www.ines.mynetcologne.de/dummy_gsview47.eps (64k) (doesn´t work) Output from ps2eps v1.64 utility, parameters as suggested by http://www.tm.uka.de/~bless/ps2eps.html: http://www.ines.mynetcologne.de/dummy_ps2eps164.eps (64k) (doesn´t work) Just import those example eps files dummy_bbget_espgs770.eps (64k) (works!) dummy_bbget_gs862.eps (64k) (doesn´t work) dummy_gsview47.eps (64k) (doesn´t work) dummy_ps2eps164.eps (64k) (doesn´t work) to LyX always using the Clip to bounding box and Read from file options in the dialog, and have a look at the output. You will see the only file giving correct clipping is the one with the bounding box values generated by bbget and an old, discontinued ESP ghostscript version. Now, everybody can say that is not a problem of LyX, but on the other hand, the LyX image import dialogue is left pretty useless if there is only some certain script/program combination being able to generate bounding boxes that LyX is able to deal with? Regards, Tom Schlangen
Re: Bounding box problem (not caused by LyX but ghostscript)
Dear Nicolás, Now, regarding your eps files, are the last two or three eps files really useless? I can see that the only difference with the ok file is that their bounding box is one point bigger in both th evertical and horizontal dimensions. Is that really a problem? Good point - I must admit I didn´t check DVI output (which is correct) before, because it looks wrong already in the LyX GUI editor - both my installed Windows and Linux LyX versions (V1.55 for both OS) still show the wide border around the bounding box in the LyX GUI/Editor for both files. That is not a big Problem, but just a nuisance in the LyX GUI editor - which is not the case when bounding boxes are computed by the bbget/ESP-gs combo. Now I am wondering who is the transgressor regarding the wrong display (with white borders): ImageMagick or LyX itself? Anyway, thank you for the workaround regarding the old ghostscript version and let´s hope the LyX GUI display problem will be solved soon. Regards, Tom Schlangen --
Re: Bounding box problem (not caused by LyX but ghostscript)
Dear Tom, I checked your figures in LyX and could verify your problem. It seems that imagemagick is culprit. I converted your eps files to pdf and included that in LyX. That was shown perfectly clipped. So you could consider switchin gto pdflatex, converting all your eps files by a script using epstopdf command from MiKTeX. That, ofcourse, will only be possible if you are not using pstricks. Mukhtar
Re: Bounding box problem (not caused by LyX but ghostscript)
Do you mean that when the eps is displayed in LyX is not clipped, as it would happen if it was opened with Gsview? In my machine I can see the clipped figure both in LyX and in the generated pdf/ps/dvi. I have LyX 1.5.5, ImageMagick-6.2.7-Q16, AFPL Ghostscript 8.14 and GSview 4.6. Nicolás Mukhtar Ullah wrote: Dear Tom, I checked your figures in LyX and could verify your problem. It seems that imagemagick is culprit. I converted your eps files to pdf and included that in LyX. That was shown perfectly clipped. So you could consider switchin gto pdflatex, converting all your eps files by a script using epstopdf command from MiKTeX. That, ofcourse, will only be possible if you are not using pstricks. Mukhtar
Re: Bounding box problem (not caused by LyX but ghostscript)
Dear Mukhtar, > Since I have got a working ps2eps, you could send me > one example eps file so Thank you for offering! Meanwhile I tested ps2eps V1.64 myself. While it calculates the bounding box exactly (great!) the clipping to bounding box option as per the Lyx dialogue doesn´t work correctly anymore: While the bbox values can be read from the file by Lyx, the picture doesn´t get clipped to the tile but the whole page is shown. I am really stuck with this problem Tom Schlangen --
Re: Bounding box problem (not caused by LyX but ghostscript)
Okay, I have prepared some files to illustrate the problem, so other have a chance to verify. .EPS output file of the circuit drawing program I use: http://www.ines.mynetcologne.de/dummy.eps (64k) bbget script from http://silas.psfc.mit.edu/elec_fig/ : http://www.ines.mynetcologne.de/bbget Output from bbget, using esp-gs v7.70.x: http://www.ines.mynetcologne.de/dummy_bbget_espgs770.eps (64k) (works!) Output from bbget, using gs v8.62: http://www.ines.mynetcologne.de/dummy_bbget_gs862.eps (64k) (doesn´t work) Output from gsview v4.7, using option PS to EPS, also checkmarked "Automatically calculate Baounding Box". BTW, using gsview v4.9 gives the same result. http://www.ines.mynetcologne.de/dummy_gsview47.eps (64k) (doesn´t work) Output from ps2eps v1.64 utility, parameters as suggested by http://www.tm.uka.de/~bless/ps2eps.html: http://www.ines.mynetcologne.de/dummy_ps2eps164.eps (64k) (doesn´t work) Just import those example eps files dummy_bbget_espgs770.eps (64k) (works!) dummy_bbget_gs862.eps (64k) (doesn´t work) dummy_gsview47.eps (64k) (doesn´t work) dummy_ps2eps164.eps (64k) (doesn´t work) to LyX always using the "Clip to bounding box" and "Read from file" options in the dialog, and have a look at the output. You will see the only file giving correct clipping is the one with the bounding box values generated by bbget and an old, discontinued ESP ghostscript version. Now, everybody can say "that is not a problem of LyX", but on the other hand, the LyX image import dialogue is left pretty useless if there is only some certain script/program combination being able to generate bounding boxes that LyX is able to deal with? Regards, Tom Schlangen --
Re: Bounding box problem (not caused by LyX but ghostscript)
I you select the "Clip to bounding box" option and get the bounding box from the file, the result will be the same as if you simply do not select the "Clip to bounding box" option (in my experience, at least). Now, regarding your eps files, are the last two or three eps files really useless? I can see that the only difference with the ok file is that their bounding box is one point bigger in both th evertical and horizontal dimensions. Is that really a problem? What you get is a white frame of less than 1mm of thickness, and since I assume your paper is white... no one will notice such fame! Just my opinion. Cheers, Nicolás Tom Schlangen wrote: Okay, I have prepared some files to illustrate the problem, so other have a chance to verify. .EPS output file of the circuit drawing program I use: http://www.ines.mynetcologne.de/dummy.eps (64k) bbget script from http://silas.psfc.mit.edu/elec_fig/ : http://www.ines.mynetcologne.de/bbget Output from bbget, using esp-gs v7.70.x: http://www.ines.mynetcologne.de/dummy_bbget_espgs770.eps (64k) (works!) Output from bbget, using gs v8.62: http://www.ines.mynetcologne.de/dummy_bbget_gs862.eps (64k) (doesn´t work) Output from gsview v4.7, using option PS to EPS, also checkmarked "Automatically calculate Baounding Box". BTW, using gsview v4.9 gives the same result. http://www.ines.mynetcologne.de/dummy_gsview47.eps (64k) (doesn´t work) Output from ps2eps v1.64 utility, parameters as suggested by http://www.tm.uka.de/~bless/ps2eps.html: http://www.ines.mynetcologne.de/dummy_ps2eps164.eps (64k) (doesn´t work) Just import those example eps files dummy_bbget_espgs770.eps (64k) (works!) dummy_bbget_gs862.eps (64k) (doesn´t work) dummy_gsview47.eps (64k) (doesn´t work) dummy_ps2eps164.eps (64k) (doesn´t work) to LyX always using the "Clip to bounding box" and "Read from file" options in the dialog, and have a look at the output. You will see the only file giving correct clipping is the one with the bounding box values generated by bbget and an old, discontinued ESP ghostscript version. Now, everybody can say "that is not a problem of LyX", but on the other hand, the LyX image import dialogue is left pretty useless if there is only some certain script/program combination being able to generate bounding boxes that LyX is able to deal with? Regards, Tom Schlangen
Re: Bounding box problem (not caused by LyX but ghostscript)
Dear Nicolás, > Now, regarding your eps files, are the last two or three eps files > really useless? I can see that the only difference with the ok file > is that their bounding box is one point bigger in both th evertical > and horizontal dimensions. Is that really a problem? Good point - I must admit I didn´t check DVI output (which is correct) before, because it looks wrong already in the LyX GUI editor - both my installed Windows and Linux LyX versions (V1.55 for both OS) still show the wide border around the bounding box in the LyX GUI/Editor for both files. That is not a big Problem, but just a nuisance in the LyX GUI editor - which is not the case when bounding boxes are computed by the bbget/ESP-gs combo. Now I am wondering who is the transgressor regarding the wrong display (with white borders): ImageMagick or LyX itself? Anyway, thank you for the workaround regarding the old ghostscript version and let´s hope the LyX GUI display problem will be solved soon. Regards, Tom Schlangen --
Re: Bounding box problem (not caused by LyX but ghostscript)
Dear Tom, I checked your figures in LyX and could verify your problem. It seems that imagemagick is culprit. I converted your eps files to pdf and included that in LyX. That was shown perfectly clipped. So you could consider switchin gto pdflatex, converting all your eps files by a script using epstopdf command from MiKTeX. That, ofcourse, will only be possible if you are not using pstricks. Mukhtar
Re: Bounding box problem (not caused by LyX but ghostscript)
Do you mean that when the eps is displayed in LyX is not clipped, as it would happen if it was opened with Gsview? In my machine I can see the clipped figure both in LyX and in the generated pdf/ps/dvi. I have LyX 1.5.5, ImageMagick-6.2.7-Q16, AFPL Ghostscript 8.14 and GSview 4.6. Nicolás Mukhtar Ullah wrote: Dear Tom, I checked your figures in LyX and could verify your problem. It seems that imagemagick is culprit. I converted your eps files to pdf and included that in LyX. That was shown perfectly clipped. So you could consider switchin gto pdflatex, converting all your eps files by a script using epstopdf command from MiKTeX. That, ofcourse, will only be possible if you are not using pstricks. Mukhtar
Bounding box problem (not caused by LyX but ghostscript)
Hello Lyx Users, first of all I have to apologize for asking here about a problem not caused by LyX itself, but at least it is related since I am writing a rather extensive technical book using LyX (several hundred pages done already) which contains a lot of schematics/.eps files imported to LyX, so I hope I am not too off topic and someone hopefully can help me out. I generate those schematics from a circuit drawing program as .eps (extended postscript) files. Sadly that drawing program cannot generate bounding box information suitable for the LyX graphics import cut to boundig box dialogue, so I have to run those .eps files through the bbget script which is described here: http://silas.psfc.mit.edu/elec_fig/ (BTW, I tried to contact Mr. Hutcchinson on the problem, but sadly didn´t succeed to get an answer so far). Using ESP ghostscript V7.07.1 as present/used in (old) Debian V3.1r2, everything works fine, the bounding box information is generated correctly, for example with a result like: 60 214 348 379 Now, that certain old ESP ghostscript version is not present with many current/modern Linux versions, but usually and likely you will find GPL ghostscript V8.62 instead. Sadly, this current ghostview version extracts different numbers for the bounding box than the old version, using the same input file: 63 214 342 377 which is a smaller box, which in turn cuts small parts off the schematic/.eps-file to be imported by LyX :-( There might be several solutions to this problem: 1) manually changing/upping the bounding box values in the LyX bounding box dialogue, which is cumbersome 2) trying to get the old ESP ghostscript to port/run somehow on current Linux distributions together with the bbget script 3) finding a functional alternative to the bbget + ghostview method of generating bounding box information for .eps files Especially 3) would be of high interest to me concearning the LyX Windows version I do the most work with, because the current process of: - drawing schematics using a Windows program, exporting to .eps - moving the .eps to a Linux machine to run the bbget utility - moving the changed .eps back to a Windows machine to be imported to LyX (Windows version) is a really cumbersome workflow to do with lots of dozens of .eps file. So, ideally I would be looking for a Windows based method to replace the bbget/ghostscript stuff, also getting correct bounding boxes again. The second choice would be to get the bbget script working again with current GPL ghostscript version. Any ideas/help appreciated, and sorry again for being only slightly LyX-related ... Regards, Tom Schlangen --
Re: Bounding box problem (not caused by LyX but ghostscript)
Hmmm, searching the 'net for the problem, the need of generating new bounding boxes to exclude the excessive white frame around the actual picture in an .eps file seems to be rather common. What about a new/additional LyX graphics menue/dialog option, like Auto bounding box, means, having the bbget script functionality integrated (and working) in the LyX GUI somehow? Regards, Tom Schlangen -- mailto:[EMAIL PROTECTED]
Re: Bounding box problem (not caused by LyX but ghostscript)
Tom Schlangen, If you are using MiKTeX (which is most likely), then you can use eps2eps with -dNOCACHE option like this: eps2eps -dNOCACHE input.eps output.eps This will convert all the fonts to outlines. If you don't want that, then a better option is to use ps2eps on the link http://www.tm.uka.de/~bless/ps2eps which requires perl. Mukhtar
Re: Bounding box problem (not caused by LyX but ghostscript)
Some further digging the 'net for related information reveals that several quite current ghostscript (GS-GPL and other) versions beginning with V8.60 show bbox related bugs :-( Any other idea/method _not_ using ghostscript to crop the white frame from the actual information in an .eps file to be imported to LyX? Regards, Tom Schlangen -- mailto:[EMAIL PROTECTED]
Re: Bounding box problem (not caused by LyX but ghostscript)
Dear Mukhtar, If you are using MiKTeX (which is most likely), then you can use eps2eps with -dNOCACHE option like this: eps2eps -dNOCACHE input.eps output.eps This will convert all the fonts to outlines. Maybe, but unfortunately it does not compute any bounding box values around the actual picture tile within a page - that is what I am looking for. Thank you very much, Tom Schlangen --
Re: Bounding box problem (not caused by LyX but ghostscript)
Tom Schlangen [EMAIL PROTECTED] writes: Dear Mukhtar, If you are using MiKTeX (which is most likely), then you can use eps2eps with -dNOCACHE option like this: eps2eps -dNOCACHE input.eps output.eps This will convert all the fonts to outlines. Maybe, but unfortunately it does not compute any bounding box values around the actual picture tile within a page - that is what I am looking for. Thank you very much, Tom Schlangen Dear Tom, Then you can try the ps2eps on http://www.tm.uka.de/~bless/ps2eps which also has its own bbox executable. Maybe that can compute the correct bounding box for you. Best regards, Mukhtar
Re: Bounding box problem (not caused by LyX but ghostscript)
Dear Mukhtar, to clarify the problem at hand: 1. I do have .eps files already (generated by a circuit drawing program plus an .eps driver), 2. but they contain bounding box information that relates to the _page_ size, not the actual drawing _tile_ size 3. the usual method to import something like this into LyX is to render the .eps using ghostscript to get the actual drawing _tile_ size bounding box values and having that information written back to the .eps file, then import it to LyX using the get bounding box from file option. Now, with broken ghostscript giving back wrong tile size bounding box information when rendering because of a bug as it unfortunately seems to be the case with current versions = 8.60, an alternate method to get the correct _tile_ size bounding box information (without broken ghostscripz) would be of great help to import those .eps drawings into LyX. As I see it, your suggestions of using eps2eps and ps2eps wouldn´t help with this problem. Unfortunately, most tools dealing with bounding box information within an .eps or ps file depend on working but not broken ghostscript, because most of them only are wrappers around ghostscript to make it somewhat user friendly. Actually, the bbget utility I used so far and pointed to in my first article on this problem is just such wrapper, depending on a not-broken ghostscript to do its work. Kind regards, Tom Schlangen -- mailto:[EMAIL PROTECTED]
Re: Bounding box problem (not caused by LyX but ghostscript)
Tom Schlangen [EMAIL PROTECTED] writes: Dear Mukhtar, to clarify the problem at hand: 1. I do have .eps files already (generated by a circuit drawing program plus an .eps driver), 2. but they contain bounding box information that relates to the _page_ size, not the actual drawing _tile_ size 3. the usual method to import something like this into LyX is to render the .eps using ghostscript to get the actual drawing _tile_ size bounding box values and having that information written back to the .eps file, then import it to LyX using the get bounding box from file option. Now, with broken ghostscript giving back wrong tile size bounding box information when rendering because of a bug as it unfortunately seems to be the case with current versions = 8.60, an alternate method to get the correct _tile_ size bounding box information (without broken ghostscripz) would be of great help to import those .eps drawings into LyX. As I see it, your suggestions of using eps2eps and ps2eps wouldn´t help with this problem. Unfortunately, most tools dealing with bounding box information within an .eps or ps file depend on working but not broken ghostscript, because most of them only are wrappers around ghostscript to make it somewhat user friendly. Actually, the bbget utility I used so far and pointed to in my first article on this problem is just such wrapper, depending on a not-broken ghostscript to do its work. Kind regards, Tom Schlangen Dear Tom, The tool ps2eps I suggested has its own bbox.exe which claims to be compute the correct bounding box (without using ghostscript). That is why I suggest that is worth a try. The ps2eps by default uses its own bbox, however you can force it to use ghostscript by an option. Best wishes, Mukhtar
Re: Bounding box problem (not caused by LyX but ghostscript)
In continuation with my last post... Since I have got a working ps2eps, you could send me one example eps file so that I can check if it works. Mukhtar
Bounding box problem (not caused by LyX but ghostscript)
Hello Lyx Users, first of all I have to apologize for asking here about a problem not caused by LyX itself, but at least it is related since I am writing a rather extensive technical book using LyX (several hundred pages done already) which contains a lot of schematics/.eps files imported to LyX, so I hope I am not too off topic and someone hopefully can help me out. I generate those schematics from a circuit drawing program as .eps (extended postscript) files. Sadly that drawing program cannot generate bounding box information suitable for the LyX graphics import cut to boundig box dialogue, so I have to run those .eps files through the bbget script which is described here: http://silas.psfc.mit.edu/elec_fig/ (BTW, I tried to contact Mr. Hutcchinson on the problem, but sadly didn´t succeed to get an answer so far). Using ESP ghostscript V7.07.1 as present/used in (old) Debian V3.1r2, everything works fine, the bounding box information is generated correctly, for example with a result like: 60 214 348 379 Now, that certain old ESP ghostscript version is not present with many current/modern Linux versions, but usually and likely you will find GPL ghostscript V8.62 instead. Sadly, this current ghostview version extracts different numbers for the bounding box than the old version, using the same input file: 63 214 342 377 which is a smaller box, which in turn cuts small parts off the schematic/.eps-file to be imported by LyX :-( There might be several solutions to this problem: 1) manually changing/upping the bounding box values in the LyX bounding box dialogue, which is cumbersome 2) trying to get the old ESP ghostscript to port/run somehow on current Linux distributions together with the bbget script 3) finding a functional alternative to the bbget + ghostview method of generating bounding box information for .eps files Especially 3) would be of high interest to me concearning the LyX Windows version I do the most work with, because the current process of: - drawing schematics using a Windows program, exporting to .eps - moving the .eps to a Linux machine to run the bbget utility - moving the changed .eps back to a Windows machine to be imported to LyX (Windows version) is a really cumbersome workflow to do with lots of dozens of .eps file. So, ideally I would be looking for a Windows based method to replace the bbget/ghostscript stuff, also getting correct bounding boxes again. The second choice would be to get the bbget script working again with current GPL ghostscript version. Any ideas/help appreciated, and sorry again for being only slightly LyX-related ... Regards, Tom Schlangen --
Re: Bounding box problem (not caused by LyX but ghostscript)
Hmmm, searching the 'net for the problem, the need of generating new bounding boxes to exclude the excessive white frame around the actual picture in an .eps file seems to be rather common. What about a new/additional LyX graphics menue/dialog option, like Auto bounding box, means, having the bbget script functionality integrated (and working) in the LyX GUI somehow? Regards, Tom Schlangen -- mailto:[EMAIL PROTECTED]
Re: Bounding box problem (not caused by LyX but ghostscript)
Tom Schlangen, If you are using MiKTeX (which is most likely), then you can use eps2eps with -dNOCACHE option like this: eps2eps -dNOCACHE input.eps output.eps This will convert all the fonts to outlines. If you don't want that, then a better option is to use ps2eps on the link http://www.tm.uka.de/~bless/ps2eps which requires perl. Mukhtar
Re: Bounding box problem (not caused by LyX but ghostscript)
Some further digging the 'net for related information reveals that several quite current ghostscript (GS-GPL and other) versions beginning with V8.60 show bbox related bugs :-( Any other idea/method _not_ using ghostscript to crop the white frame from the actual information in an .eps file to be imported to LyX? Regards, Tom Schlangen -- mailto:[EMAIL PROTECTED]
Re: Bounding box problem (not caused by LyX but ghostscript)
Dear Mukhtar, If you are using MiKTeX (which is most likely), then you can use eps2eps with -dNOCACHE option like this: eps2eps -dNOCACHE input.eps output.eps This will convert all the fonts to outlines. Maybe, but unfortunately it does not compute any bounding box values around the actual picture tile within a page - that is what I am looking for. Thank you very much, Tom Schlangen --
Re: Bounding box problem (not caused by LyX but ghostscript)
Tom Schlangen [EMAIL PROTECTED] writes: Dear Mukhtar, If you are using MiKTeX (which is most likely), then you can use eps2eps with -dNOCACHE option like this: eps2eps -dNOCACHE input.eps output.eps This will convert all the fonts to outlines. Maybe, but unfortunately it does not compute any bounding box values around the actual picture tile within a page - that is what I am looking for. Thank you very much, Tom Schlangen Dear Tom, Then you can try the ps2eps on http://www.tm.uka.de/~bless/ps2eps which also has its own bbox executable. Maybe that can compute the correct bounding box for you. Best regards, Mukhtar
Re: Bounding box problem (not caused by LyX but ghostscript)
Dear Mukhtar, to clarify the problem at hand: 1. I do have .eps files already (generated by a circuit drawing program plus an .eps driver), 2. but they contain bounding box information that relates to the _page_ size, not the actual drawing _tile_ size 3. the usual method to import something like this into LyX is to render the .eps using ghostscript to get the actual drawing _tile_ size bounding box values and having that information written back to the .eps file, then import it to LyX using the get bounding box from file option. Now, with broken ghostscript giving back wrong tile size bounding box information when rendering because of a bug as it unfortunately seems to be the case with current versions = 8.60, an alternate method to get the correct _tile_ size bounding box information (without broken ghostscripz) would be of great help to import those .eps drawings into LyX. As I see it, your suggestions of using eps2eps and ps2eps wouldn´t help with this problem. Unfortunately, most tools dealing with bounding box information within an .eps or ps file depend on working but not broken ghostscript, because most of them only are wrappers around ghostscript to make it somewhat user friendly. Actually, the bbget utility I used so far and pointed to in my first article on this problem is just such wrapper, depending on a not-broken ghostscript to do its work. Kind regards, Tom Schlangen -- mailto:[EMAIL PROTECTED]
Re: Bounding box problem (not caused by LyX but ghostscript)
Tom Schlangen [EMAIL PROTECTED] writes: Dear Mukhtar, to clarify the problem at hand: 1. I do have .eps files already (generated by a circuit drawing program plus an .eps driver), 2. but they contain bounding box information that relates to the _page_ size, not the actual drawing _tile_ size 3. the usual method to import something like this into LyX is to render the .eps using ghostscript to get the actual drawing _tile_ size bounding box values and having that information written back to the .eps file, then import it to LyX using the get bounding box from file option. Now, with broken ghostscript giving back wrong tile size bounding box information when rendering because of a bug as it unfortunately seems to be the case with current versions = 8.60, an alternate method to get the correct _tile_ size bounding box information (without broken ghostscripz) would be of great help to import those .eps drawings into LyX. As I see it, your suggestions of using eps2eps and ps2eps wouldn´t help with this problem. Unfortunately, most tools dealing with bounding box information within an .eps or ps file depend on working but not broken ghostscript, because most of them only are wrappers around ghostscript to make it somewhat user friendly. Actually, the bbget utility I used so far and pointed to in my first article on this problem is just such wrapper, depending on a not-broken ghostscript to do its work. Kind regards, Tom Schlangen Dear Tom, The tool ps2eps I suggested has its own bbox.exe which claims to be compute the correct bounding box (without using ghostscript). That is why I suggest that is worth a try. The ps2eps by default uses its own bbox, however you can force it to use ghostscript by an option. Best wishes, Mukhtar
Re: Bounding box problem (not caused by LyX but ghostscript)
In continuation with my last post... Since I have got a working ps2eps, you could send me one example eps file so that I can check if it works. Mukhtar
Bounding box problem (not caused by LyX but ghostscript)
Hello Lyx Users, first of all I have to apologize for asking here about a problem not caused by LyX itself, but at least it is related since I am writing a rather extensive technical book using LyX (several hundred pages done already) which contains a lot of schematics/.eps files imported to LyX, so I hope I am not too off topic and someone hopefully can help me out. I generate those schematics from a circuit drawing program as .eps (extended postscript) files. Sadly that drawing program cannot generate bounding box information suitable for the LyX graphics import "cut to boundig box" dialogue, so I have to run those .eps files through the "bbget" script which is described here: http://silas.psfc.mit.edu/elec_fig/ (BTW, I tried to contact Mr. Hutcchinson on the problem, but sadly didn´t succeed to get an answer so far). Using ESP ghostscript V7.07.1 as present/used in (old) Debian V3.1r2, everything works fine, the bounding box information is generated correctly, for example with a result like: 60 214 348 379 Now, that certain old ESP ghostscript version is not present with many current/modern Linux versions, but usually and likely you will find GPL ghostscript V8.62 instead. Sadly, this current ghostview version extracts different numbers for the bounding box than the old version, using the same input file: 63 214 342 377 which is a smaller box, which in turn cuts small parts off the schematic/.eps-file to be imported by LyX :-( There might be several solutions to this problem: 1) manually changing/upping the bounding box values in the LyX bounding box dialogue, which is cumbersome 2) trying to get the old ESP ghostscript to port/run somehow on current Linux distributions together with the bbget script 3) finding a functional alternative to the bbget + ghostview method of generating bounding box information for .eps files Especially 3) would be of high interest to me concearning the LyX Windows version I do the most work with, because the current process of: - drawing schematics using a Windows program, exporting to .eps - moving the .eps to a Linux machine to run the bbget utility - moving the changed .eps back to a Windows machine to be imported to LyX (Windows version) is a really cumbersome workflow to do with lots of dozens of .eps file. So, ideally I would be looking for a Windows based method to replace the bbget/ghostscript stuff, also getting correct bounding boxes again. The second choice would be to get the bbget script working again with current GPL ghostscript version. Any ideas/help appreciated, and sorry again for being only slightly LyX-related ... Regards, Tom Schlangen --
Re: Bounding box problem (not caused by LyX but ghostscript)
Hmmm, searching the 'net for the problem, the need of generating new bounding boxes to exclude the excessive white "frame" around the actual picture in an .eps file seems to be rather common. What about a new/additional LyX graphics menue/dialog option, like "Auto bounding box", means, having the bbget script functionality integrated (and working) in the LyX GUI somehow? Regards, Tom Schlangen -- mailto:[EMAIL PROTECTED]
Re: Bounding box problem (not caused by LyX but ghostscript)
Tom Schlangen, If you are using MiKTeX (which is most likely), then you can use eps2eps with -dNOCACHE option like this: eps2eps -dNOCACHE input.eps output.eps This will convert all the fonts to outlines. If you don't want that, then a better option is to use ps2eps on the link http://www.tm.uka.de/~bless/ps2eps which requires perl. Mukhtar
Re: Bounding box problem (not caused by LyX but ghostscript)
Some further digging the 'net for related information reveals that several quite current ghostscript (GS-GPL and other) versions beginning with V8.60 show bbox related bugs :-( Any other idea/method _not_ using ghostscript to crop the white "frame" from the actual information in an .eps file to be imported to LyX? Regards, Tom Schlangen -- mailto:[EMAIL PROTECTED]
Re: Bounding box problem (not caused by LyX but ghostscript)
Dear Mukhtar, > If you are using MiKTeX (which is most likely), then you can use > eps2eps with -dNOCACHE option like this: > eps2eps -dNOCACHE input.eps output.eps > This will convert all the fonts to outlines. Maybe, but unfortunately it does not compute any bounding box values around the actual picture tile within a page - that is what I am looking for. Thank you very much, Tom Schlangen --
Re: Bounding box problem (not caused by LyX but ghostscript)
Tom Schlangen <[EMAIL PROTECTED]> writes: > > Dear Mukhtar, > > > If you are using MiKTeX (which is most likely), then you can use > > eps2eps with -dNOCACHE option like this: > > eps2eps -dNOCACHE input.eps output.eps > > This will convert all the fonts to outlines. > > Maybe, but unfortunately it does not compute any bounding box values around the actual picture tile within > a page - that is what I am looking for. > > Thank you very much, > > Tom Schlangen Dear Tom, Then you can try the ps2eps on http://www.tm.uka.de/~bless/ps2eps which also has its own bbox executable. Maybe that can compute the correct bounding box for you. Best regards, Mukhtar
Re: Bounding box problem (not caused by LyX but ghostscript)
Dear Mukhtar, to clarify the problem at hand: 1. I do have .eps files already (generated by a circuit drawing program plus an .eps driver), 2. but they contain bounding box information that relates to the _page_ size, not the actual drawing _tile_ size 3. the usual method to import something like this into LyX is to render the .eps using ghostscript to get the actual drawing _tile_ size bounding box values and having that information written back to the .eps file, then import it to LyX using the "get bounding box from file" option. Now, with broken ghostscript giving back wrong tile size bounding box information when rendering because of a bug as it unfortunately seems to be the case with current versions >= 8.60, an alternate method to get the correct _tile_ size bounding box information (without broken ghostscripz) would be of great help to import those .eps drawings into LyX. As I see it, your suggestions of using eps2eps and ps2eps wouldn´t help with this problem. Unfortunately, most tools dealing with bounding box information within an .eps or ps file depend on working but not broken ghostscript, because most of them only are "wrappers" around ghostscript to make it somewhat user friendly. Actually, the "bbget" utility I used so far and pointed to in my first article on this problem is just such "wrapper", depending on a not-broken ghostscript to do its work. Kind regards, Tom Schlangen -- mailto:[EMAIL PROTECTED]
Re: Bounding box problem (not caused by LyX but ghostscript)
Tom Schlangen <[EMAIL PROTECTED]> writes: > > Dear Mukhtar, > > to clarify the problem at hand: > > 1. I do have .eps files already (generated by a circuit drawing program plus an .eps driver), > > 2. but they contain bounding box information that relates to the _page_ size, not the actual drawing _tile_ size > > 3. the usual method to import something like this into LyX is to render the .eps using ghostscript to get the > actual drawing _tile_ size bounding box values and having that information written back to the .eps file, > then import it to LyX using the "get bounding box from file" option. > > Now, with broken ghostscript giving back wrong tile size bounding box information when rendering because > of a bug as it unfortunately seems to be the case with current versions >= 8.60, an alternate method to get > the correct _tile_ size bounding box information (without broken ghostscripz) would be of great help to > import those .eps drawings into LyX. > > As I see it, your suggestions of using eps2eps and ps2eps wouldn´t help with this problem. > > Unfortunately, most tools dealing with bounding box information within an .eps or ps file depend on > working but not broken ghostscript, because most of them only are "wrappers" around ghostscript to make > it somewhat user friendly. > > Actually, the "bbget" utility I used so far and pointed to in my first article on this problem is just such > "wrapper", depending on a not-broken ghostscript to do its work. > > Kind regards, > > Tom Schlangen > Dear Tom, The tool ps2eps I suggested has its own bbox.exe which claims to be compute the correct bounding box (without using ghostscript). That is why I suggest that is worth a try. The ps2eps by default uses its own bbox, however you can force it to use ghostscript by an option. Best wishes, Mukhtar
Re: Bounding box problem (not caused by LyX but ghostscript)
In continuation with my last post... Since I have got a working ps2eps, you could send me one example eps file so that I can check if it works. Mukhtar
