Re: Fw: Postscript preview
Why don't you make the Matlab copy of GS the same as the system? I tried that unsuccessfully already. Matlab generates the ps file even when I remove its GS directory completely. When I substitute Matlab GS with "official" GS, the figures still misbehave after I regenerate them from scratch with the "official" GS located in Matlab directory. Another thing to look at is to invoke GSview, under Start-> All programs. After it loads, at the top under Options, choose Advanced Configure. I was once shocked to discover that my gs.dll and gs include path pointed to gs 7.07 which was long gone; you want your current which in your case is 8.14 I think. Anyway, I think those entries are generated from reading the registry. And sometimes GS doesn't uninstall properly and leaves old traces in the registry which are erroneously detected & used. It points to 8.14 as needed. I give up. Preview works most of the time, I can survive this one document without having the preview. Leo
Re: Fw: Postscript preview
TechTonics wrote: LB wrote: This problem with preview is still not 100% gone. I have to change the PATH to point to a different copy of GS (Matlab copy or "official" copy) depending on which Lyx document I open. At this time, only the document that first exhibit this problem needs PATH to point to Matlab copy of GS for preview to work. All other documents I have opened so far work fine with the "official" version but show preview problem with Matlab copy of GS. Confused, Leo Why don't you make the Matlab copy of GS the same as the system? Don't forget to generate a new version of the problematic image(s) from Matlab again using the system gs 8.14. This idea isn't intended to fix the problem with the original mutant image created by the matlab gs, but to correct the current bad file(s) by making a new one and to fix future problems. Right-clicking in the taskbar(bottom)cascade = = Regards, Stephen
Re: Fw: Postscript preview
LB wrote: Which would not explain why futzing with the environment variables cured (or at least moved) the bug. Then again, perhaps I'm asking too much of the bug as far as consistency goes. This brings me back to my thesis that somewhere there is a buffer overflow. How/why it would involve both the file paths/names and environment variables beats me, but I'll take another shot on the developer list and see what shakes. This problem with preview is still not 100% gone. I have to change the PATH to point to a different copy of GS (Matlab copy or "official" copy) depending on which Lyx document I open. At this time, only the document that first exhibit this problem needs PATH to point to Matlab copy of GS for preview to work. All other documents I have opened so far work fine with the "official" version but show preview problem with Matlab copy of GS. Confused, Leo Why don't you make the Matlab copy of GS the same as the system? I open two instances of Windows Explorer to do this kind of work. In one Window, navigate to Matlab and note the name of the Gs directory. Right-click on the gs directory and delete it. It will be safe in the Recycle bin as long as you don't "empty the recycle bin". In the other window navigate to the system gs directory. Right-click on it and choose copy. Then paste it into the Matlab directory where the old matlab gs used to reside. Rename it to the same name as the old matlab gs. I suggest this because I don't know the matlab menu or command line just to change it to point to the system-wide gs. If for some reason Matlab doesn't make eps images, change it back. Rename the newly made gs directory which has been renamed to match the original matlab gs to something else. Then right-click and delete it. Otherwise you will have two gs directories in the Recycle bin and not know which one to "Restore" if they both have the same name. This is the way to do it if you don't know some technical syntax or deep matlab menu option. Remember not to use illegal characters when you create filenames for the .eps images. Do ordinary. Another thing to look at is to invoke GSview, under Start-> All programs. After it loads, at the top under Options, choose Advanced Configure. I was once shocked to discover that my gs.dll and gs include path pointed to gs 7.07 which was long gone; you want your current which in your case is 8.14 I think. Anyway, I think those entries are generated from reading the registry. And sometimes GS doesn't uninstall properly and leaves old traces in the registry which are erroneously detected & used. The idea here is that if 8.14 is making the eps then when LyX uses 8.14 it should be able to decipher them. This should work unless some command line switches/snytax invoking ghostscript has been changed from what worked with the old version but could be different in the newer gs version. That doesn't happen all that often so your chances should be good. This will avoid you having to edit the Path prefix in lyx back and forth, in order to change versions to accomodate the creating gs version. Good luck, Stephen
Re: Fw: Postscript preview
Which would not explain why futzing with the environment variables cured (or at least moved) the bug. Then again, perhaps I'm asking too much of the bug as far as consistency goes. This brings me back to my thesis that somewhere there is a buffer overflow. How/why it would involve both the file paths/names and environment variables beats me, but I'll take another shot on the developer list and see what shakes. This problem with preview is still not 100% gone. I have to change the PATH to point to a different copy of GS (Matlab copy or "official" copy) depending on which Lyx document I open. At this time, only the document that first exhibit this problem needs PATH to point to Matlab copy of GS for preview to work. All other documents I have opened so far work fine with the "official" version but show preview problem with Matlab copy of GS. Confused, Leo
Re: Fw: Postscript preview
TechTonics wrote: LB wrote: I have changed the names (decreased by one character) of the figures that were given me problems and they are now previewing fine!!! Great! One of the great Presidents said persistence is a far better quality than talent or genius. Still seems like a surprising way to fix it unless the 1 character decrease was removing a forbidden character used in the filenames. Which would not explain why futzing with the environment variables cured (or at least moved) the bug. Then again, perhaps I'm asking too much of the bug as far as consistency goes. This brings me back to my thesis that somewhere there is a buffer overflow. How/why it would involve both the file paths/names and environment variables beats me, but I'll take another shot on the developer list and see what shakes. /Paul
Re: Fw: Postscript preview
LB wrote: I have changed the names (decreased by one character) of the figures that were given me problems and they are now previewing fine!!! Thanks Leo Great! One of the great Presidents said persistence is a far better quality than talent or genius. Still seems like a surprising way to fix it unless the 1 character decrease was removing a forbidden character used in the filenames. - Stephen "Nothing in the world can take the place of persistence. Talent will not; nothing is more common than unsuccessful people with talent. Genius will not; unrewarded genius is almost a proverb. Education will not; the world is full of educated derelicts. Persistence and determination alone are omnipotent. The slogan "press on" has solved and always will solve the problems of the human race." Calvin Coolidge
Re: Fw: Postscript preview
I have changed the names (decreased by one character) of the figures that were given me problems and they are now previewing fine!!! Clarification: it works when Lyx path points to Matlab gs. When I change path to the "official" gs the preview stops working. I have installed matlab after my original version of gs was installed. However, I think I have updated gs at the time I installed 1.4.2. It looks like with the old versions of lyx, Matlab's gs was always used as it was installed later, while with 1.4.2 the new version of gs is the default and that version is not compatible with the matlab for some reason. Leo
Re: Fw: Postscript preview
I have changed the names (decreased by one character) of the figures that were given me problems and they are now previewing fine!!! Thanks Leo
Re: Fw: Postscript preview
Your starting idea seems the easiest place to start. LyX was configured with the system GS. It is now going to use the matlab gs. Does the matlab gs need to be put in the beginning of Path_prefix? Reconfigure/Restart? [SET LC_ALL=en_EN] I think that stands for Locale. I suggested changing that entry in the 1.4.2 lyx.bat to SET LANG=en_EN because I think Leo said both Lyx.exe and lyx.bat work for all images in 1.4.1 I set PATH in lyx to point to Matlab gs. I renamed gs.exe files in Cygwin and gswin32 files in gs8.14 directories, so that the only gs I have is in Matlab directory. After reconfigure and restart, I get the same preview problem (also when lyx.bat has LANG=en_EN). I have tried this with lyx.bat and lyx.exe. The only difference between lyx.bat and lyx.exe is that the preview problem jumps to different figures (all generated in Matlab). This idea and your first approach seem to be less complex, faster, and just as likely to be revealing? We are expecting the matlab gs to work in all cases?! I'm not sure whether Matlab uses gs.exe to generate the ps files because after renaming gs.exe in the Matlab directory, Matlab still managed to genereate the ps file. BTW in Matlab I use commands: print -depsc2 -r300 -f6 C:\figname.ps print -depsc -r300 -f6 C:\figname.ps to generate ps files. I also changed the .ps to .eps. Another way of generating figures in Matlab is by using File menu. All of these methods seem to make no difference as far as preview of the figures is concerned. I have renamed all gs*.exe programs I could find on my computer (including the once in the hidden directories) with old_gs*.exe. Lyx still previews most figures (.ps and .bmp) ok with the exception of the once that give me grief. Can the system track changes to the files names??? I did not think so. But if it does not, how can Lyx preview figures? I'm tired of this random problem. I think I have to live with it until something else I install in the future that will make things either better or worse... Leo
Re: Postscript preview
On Aug 9, 2006, at 2:28 PM, TechTonics wrote: LB wrote: Having already generated the image files in MATLAB, try temporarily hiding all the Cygwin and Matlab copies of the GS executable (say by adding a $ to the start of their names, which is easy to undo afterward). Then run LyX and see if the images load properly. No they don't. Leo I haven't been following this thread so I'm not sure what the original problem was, but I saw Matlab and preview in the above posting. Make sure you are saving your Matlab graphics as eps _without_ the tiff preview. LyX makes its own preview with gs. The embedded tiff preview does not work with LyX, or plain old LaTeX.
Re: Fw: Postscript preview
LB wrote: Having already generated the image files in MATLAB, try temporarily hiding all the Cygwin and Matlab copies of the GS executable (say by adding a $ to the start of their names, which is easy to undo afterward). Then run LyX and see if the images load properly. No they don't. Leo No they don't... and you tried with both lyx.exe and lyx.bat? IOW, has forcing LyX to use the system-wide GS created a change in behavior; like lyx.exe no longer works the same. I think lyx.exe now failing would mean that it had been using the matlab gs and can no longer do so. Matlab gs creates the file so one would expect it to load the file when LyX uses it. LyX.bat would be using the system gs and working in cases where the matlab gs file creation held no incompatibilities. Which is why I ask if you tested both lyx.exe and lyx.bat. If nothing has changed then we have gained no information. You could have changed system gs to a $ and tested LyX using matlab gs to render the image (after renaming). Or if lyx.exe fails, then this step should enable lyx.bat and the fix would be to put the matlab gs at beginning of LyX Path_prefix. Maybe changing LC to Lang is equivalent. Too many maybes bring Bats to the Belfry, Stephen
Re: Fw: Postscript preview
Paul A. Rubin wrote: LB wrote: I think this supports the possibility of a Ghostscript conflict and that Matlab comes with its own version of Gs. I actually have three versions of gs.exe. Cygwin has two. One in cygwin\bin directory and one in cygwin\usr\X11R6\bin directory. Matlab has its own version as well. My install of gs (8.14) has two files in bin directory: gswin32.exe and gswin32c.exe Please suggest what I can do to investigate this further. Leo Oops, forgot something. If I understood Stephen's concerns correctly, a second experiment might be in order -- having renamed the "unofficial" GS executables, try reproducing the images from Matlab using the "official" version of GS. (I'm not a Matlab user, so I don't know exactly what this would entail, but you might have to modify some setting in Matlab that holds the path to GS, or you might need the official GS bin directory on the command path, or worst case you might need to copy the official GS files, both executable and library, into the Matlab directory where the Matlab-installed GS currently lives.) /Paul Your starting idea seems the easiest place to start. LyX was configured with the system GS. It is now going to use the matlab gs. Does the matlab gs need to be put in the beginning of Path_prefix? Reconfigure/Restart? [SET LC_ALL=en_EN] I think that stands for Locale. I suggested changing that entry in the 1.4.2 lyx.bat to SET LANG=en_EN because I think Leo said both Lyx.exe and lyx.bat work for all images in 1.4.1 This idea and your first approach seem to be less complex, faster, and just as likely to be revealing? We are expecting the matlab gs to work in all cases?! Maybe change the batfile and test on an ornery critter. If it fails, change it back. Then rename the other gs versions and test with matlab gs exclusively. If that fails we know it is likely just the batfile. Change the batfile content again to set lang=en_EN and test with exclusive matlab gs. Since cygwin gs is not used and this method rules out a version conflict this had just better work! To test system gs *and* with system gs substituted for matlab gs also eliminates version GS conflict but the testing procedure may be convoluted and I don't know if there is a Grothendieck dimensional+. +meaning I will have run out of ideas and will recluse, Stephen c Best regards,
Re: Fw: Postscript preview
Having already generated the image files in MATLAB, try temporarily hiding all the Cygwin and Matlab copies of the GS executable (say by adding a $ to the start of their names, which is easy to undo afterward). Then run LyX and see if the images load properly. No they don't. Leo
Re: Fw: Postscript preview
LB wrote: I think this supports the possibility of a Ghostscript conflict and that Matlab comes with its own version of Gs. I actually have three versions of gs.exe. Cygwin has two. One in cygwin\bin directory and one in cygwin\usr\X11R6\bin directory. Matlab has its own version as well. My install of gs (8.14) has two files in bin directory: gswin32.exe and gswin32c.exe Please suggest what I can do to investigate this further. Leo So far you reported that lyx.exe will always display the images but that lyx.bat will display some and not others and this is for Lyx1.4.2; that the test.ps you sent us now displays but you have another(s) which don't. LyX1.4.1 will display all images with either lyx.exe or lyx.bat. How about with Cygwin LyX? Check to see if changing the lyx1.4.2 bat with this line SET LC_ALL=en_EN to the lyx1.4.1 bat with this line SET LANG=en_EN and then test on the transgressing eps file. That is a quick first step. When I rename files which I'm going to rename later, I do it with 2 Windows Search: find file g*.exe in C:\cygwin, and then g*.exe in C:\GS?\ It makes it easy to keep visual track of the files you've changed for when you want to rename them back. Right-click on the filename with the mouse and rename by *prepending* a $ to the file. You know CygLyX1.4.2 is available. :-) Regards, Stephen
Re: Fw: Postscript preview
LB wrote: I think this supports the possibility of a Ghostscript conflict and that Matlab comes with its own version of Gs. I actually have three versions of gs.exe. Cygwin has two. One in cygwin\bin directory and one in cygwin\usr\X11R6\bin directory. Matlab has its own version as well. My install of gs (8.14) has two files in bin directory: gswin32.exe and gswin32c.exe Please suggest what I can do to investigate this further. Leo Oops, forgot something. If I understood Stephen's concerns correctly, a second experiment might be in order -- having renamed the "unofficial" GS executables, try reproducing the images from Matlab using the "official" version of GS. (I'm not a Matlab user, so I don't know exactly what this would entail, but you might have to modify some setting in Matlab that holds the path to GS, or you might need the official GS bin directory on the command path, or worst case you might need to copy the official GS files, both executable and library, into the Matlab directory where the Matlab-installed GS currently lives.) /Paul
Re: Fw: Postscript preview
LB wrote: I think this supports the possibility of a Ghostscript conflict and that Matlab comes with its own version of Gs. I actually have three versions of gs.exe. Cygwin has two. One in cygwin\bin directory and one in cygwin\usr\X11R6\bin directory. Matlab has its own version as well. My install of gs (8.14) has two files in bin directory: gswin32.exe and gswin32c.exe Please suggest what I can do to investigate this further. Leo Having already generated the image files in MATLAB, try temporarily hiding all the Cygwin and Matlab copies of the GS executable (say by adding a $ to the start of their names, which is easy to undo afterward). Then run LyX and see if the images load properly. I'm not positive that ImageMagick runs the GS executable (as opposed to accessing a GS library directly), but I think it does. /Paul
Re: Fw: Postscript preview
I think this supports the possibility of a Ghostscript conflict and that Matlab comes with its own version of Gs. I actually have three versions of gs.exe. Cygwin has two. One in cygwin\bin directory and one in cygwin\usr\X11R6\bin directory. Matlab has its own version as well. My install of gs (8.14) has two files in bin directory: gswin32.exe and gswin32c.exe Please suggest what I can do to investigate this further. Leo
Re: Fw: Postscript preview
Paul A. Rubin wrote: Stephen Harris wrote: "The MATLAB Component Runtime (MCR) 7.0 and 7.1 do not contain a copy of the GhostScript program included with MATLAB. Therefore, applications deployed on a target machine rely on a locally- installed version of GhostScript, if one exists, for exporting some graphics. Since the version of GhostScript installed on the target machine may be different than the one included with MATLAB, the command line parameters potentially may be different as well. This difference causes an error in some instances." I think this supports the possibility of a Ghostscript conflict and that Matlab comes with its own version of Gs. It does indeed. So I agree that hypothetically Leo's MATLAB installation could be generating PS files (using it's own copy of GS) that would be indigestible to LyX->ImageMagick->GS (using a different copy of GS in the last step). That still raises the question of why those images would be successfully displayed in LyX (same LyX->ImageMagick->GS sequence) if an environment variable is deleted ... unless deletion of the environment variable affected which copy of GS was used (both on the command path?) ... in which case the bug would disappear, not switch to a different image. All that said, this bug is clearly not playing fair, so it would be a good idea for Leo to check into this just to rule it out. /Paul Yes there has to be another dimension to this. Recall he reinstalled LyX to C:\Lyx\lyx14 and the original problem files, I think it was test.ps, displayed Ok, but then another figure reared its ugly wolverine head. I would think that means that only some files are produced with the problem--either the same gs executable produces files which vary in compatibility or maybe system gs is producing the eps and it sometimes can't be read by an older matlab gs executable. Well, that is getting pretty thin. Maybe he could use the 1.4.1 lyx.bat and put Python at the beginning of the Path_prefix and try it and if it doesn't work, then try ghostscript at the beginning of Path_prefix also, but I think it is already. It would seem that the set variables in lyx1.4.2 batfile would have to part of it, but I don't know what they mean and they don't show up LC_ALL I will google one more time matlab and aikasaurus but I think that is just for Aspell. I'm not feeling well and can't concentrate. I've been up for two days fighting with a virus and am tired and have lost one partition on my hard drive. I guess its a trojan. Nope, I got a hit on allosaurus and matlab, but no aikasaurus. It's a Linux critter anyway. Regards, Stephen
Re: Fw: Postscript preview
Stephen Harris wrote: "The MATLAB Component Runtime (MCR) 7.0 and 7.1 do not contain a copy of the GhostScript program included with MATLAB. Therefore, applications deployed on a target machine rely on a locally- installed version of GhostScript, if one exists, for exporting some graphics. Since the version of GhostScript installed on the target machine may be different than the one included with MATLAB, the command line parameters potentially may be different as well. This difference causes an error in some instances." I think this supports the possibility of a Ghostscript conflict and that Matlab comes with its own version of Gs. It does indeed. So I agree that hypothetically Leo's MATLAB installation could be generating PS files (using it's own copy of GS) that would be indigestible to LyX->ImageMagick->GS (using a different copy of GS in the last step). That still raises the question of why those images would be successfully displayed in LyX (same LyX->ImageMagick->GS sequence) if an environment variable is deleted ... unless deletion of the environment variable affected which copy of GS was used (both on the command path?) ... in which case the bug would disappear, not switch to a different image. All that said, this bug is clearly not playing fair, so it would be a good idea for Leo to check into this just to rule it out. /Paul
Re: Fw: Postscript preview
Paul A. Rubin wrote: LB wrote: Ok, it tried this. I commented out SET LC_ALL=en_EN. This resulted in a different image having the preview problem. I placed SET XX=Y in lyx.bat and the preview problem moved back to the original image. The same happens when I comment out the other line in the lyx.bat. I also added extra lines in lyx.bat such as SET XX=Y this however did not make any difference as far as image preview is concerned. This is again confusing, though perhaps no more confusing than the fact that deleting unneeded environment variables (other than LC_ALL and the aiksaurus one) did not help. Another puzzling thing is that the preview problem jumps between two specific figures eventhough I have many figures in the document and many of them are generated with Matlab. The preview problem however never affects figures generated with other programs. Is there anything that the names/paths of the two affected figures have in common which is not shared by the other files. For instance, are they the longest paths, do they lie deeper in the directory tree than other figures, ... ? Stephen's idea of a second Ghostscript installation strikes me as possible but unlikely (and unlikely to be the culprit), since there would need to be something causing ImageMagick to alternate between the two GS installations on a figure-by-figure basis within the document (meaning that something in the figure names/paths would have to be triggering the switching). Also, Mathematica exports EPS without using GS and without installing its own GS, so I suspect the same might be true of MATLAB. Still, the whole bug is unlikely, so we shouldn't presume anything. It would be nice if we could intercept the call from IM to GS and see what's being passed, but so far I have not figured out how. /Paul - http://www.mathworks.com/support/solutions/data/1-ZBALJ.html?solution=1-ZBALJ "The MATLAB Component Runtime (MCR) 7.0 and 7.1 do not contain a copy of the GhostScript program included with MATLAB. Therefore, applications deployed on a target machine rely on a locally- installed version of GhostScript, if one exists, for exporting some graphics. Since the version of GhostScript installed on the target machine may be different than the one included with MATLAB, the command line parameters potentially may be different as well. This difference causes an error in some instances." I think this supports the possibility of a Ghostscript conflict and that Matlab comes with its own version of Gs. With an earlier distro of LyX I also had XemTeX installed which comes with its own Gs. It had a different version of Gs and the .dlls conflicted with LyX which was solved by moving Xemtex to the end of Windows Path. I'm pretty sure that lyx.exe checks the LyX directory for various executables because Enrico's batfiles seem to use this principle. I'm not so sure about lyx.bat because I thought it was possible that those set commands could change which Gs was invoked. I don't know what they do, the consequences of their mechanism. One major difference in the our environments and Leo's is that he has Matlab installed and we don't. I'm pretty sure that Matlab has Gs installed since I've googled and seen it listed as a sub-dir of Matlab's directory structure (though only for Linux). It should take Leo less than thirty seconds to find out with Win Explorer. I 've a hunch that his Matlab Gs version is earlier than his system Gs, supposing that there are two instances. My troubleshooting idea was to eliminate both ways a Gs version conflict could happen and to use lyx.exe first before lyx.bat to see if the .eps file itself (command line parameters used) perhaps had a version glitch and I thought it would take about 5 minutes (without Matlab running) to see if this affected the problem. I think the Matlab doc I just reported upon supports this possibility. We also have a more recent version of system Ghostscript. My Sherlock Holmes sig, (inmates on death row tell jokes by #) Stephen
Re: Fw: Postscript preview
LB wrote: Ok, it tried this. I commented out SET LC_ALL=en_EN. This resulted in a different image having the preview problem. I placed SET XX=Y in lyx.bat and the preview problem moved back to the original image. The same happens when I comment out the other line in the lyx.bat. I also added extra lines in lyx.bat such as SET XX=Y this however did not make any difference as far as image preview is concerned. This is again confusing, though perhaps no more confusing than the fact that deleting unneeded environment variables (other than LC_ALL and the aiksaurus one) did not help. Another puzzling thing is that the preview problem jumps between two specific figures eventhough I have many figures in the document and many of them are generated with Matlab. The preview problem however never affects figures generated with other programs. Is there anything that the names/paths of the two affected figures have in common which is not shared by the other files. For instance, are they the longest paths, do they lie deeper in the directory tree than other figures, ... ? Stephen's idea of a second Ghostscript installation strikes me as possible but unlikely (and unlikely to be the culprit), since there would need to be something causing ImageMagick to alternate between the two GS installations on a figure-by-figure basis within the document (meaning that something in the figure names/paths would have to be triggering the switching). Also, Mathematica exports EPS without using GS and without installing its own GS, so I suspect the same might be true of MATLAB. Still, the whole bug is unlikely, so we shouldn't presume anything. It would be nice if we could intercept the call from IM to GS and see what's being passed, but so far I have not figured out how. /Paul
Re: Fw: Postscript preview
LB wrote: One more little experiment, if you don't mind, just to confirm symptoms: if you comment out one of the SET commands in lyx.bat, but replace it with a line of equal length (SET XXX=Y... with enough Xs and Ys to match the line you commented out), does the bug move to a different image (or disappear)? Ok, it tried this. I commented out SET LC_ALL=en_EN. This resulted in a different image having the preview problem. I placed SET XX=Y in lyx.bat and the preview problem moved back to the original image. The same happens when I comment out the other line in the lyx.bat. I also added extra lines in lyx.bat such as SET XX=Y this however did not make any difference as far as image preview is concerned. Another puzzling thing is that the preview problem jumps between two specific figures eventhough I have many figures in the document and many of them are generated with Matlab. The preview problem however never affects figures generated with other programs. Thanks Leo Do you have two installations of ghostscript on your machine? One in a sub-directory for Matlab and another one in a sub-dir of LyX or maybe a system-wide Ghostscript? If so, that means if you rename the ghostscript executables, maybe they are gs.exe and gswin32.exe, to gs.bak and gswin32.bak, under the Matlab install of Ghostscript, then lyx.exe and lyx.bat should work the same. Try it first with lyx.exe which you know works and if it still works then the correct gs executable has been renamed. Then lyx.bat will have to use the same gs executable since the one under Matlab has been renamed and won't answer the call. It dawned on me that Matlab might have its own gs to make eps' Stephen -- An ambient confluence of mapped coherence ~ Stephen
Re: Fw: Postscript preview
One more little experiment, if you don't mind, just to confirm symptoms: if you comment out one of the SET commands in lyx.bat, but replace it with a line of equal length (SET XXX=Y... with enough Xs and Ys to match the line you commented out), does the bug move to a different image (or disappear)? Ok, it tried this. I commented out SET LC_ALL=en_EN. This resulted in a different image having the preview problem. I placed SET XX=Y in lyx.bat and the preview problem moved back to the original image. The same happens when I comment out the other line in the lyx.bat. I also added extra lines in lyx.bat such as SET XX=Y this however did not make any difference as far as image preview is concerned. Another puzzling thing is that the preview problem jumps between two specific figures eventhough I have many figures in the document and many of them are generated with Matlab. The preview problem however never affects figures generated with other programs. Thanks Leo
Re: Fw: Postscript preview
LB wrote: I want to make sure I'm understanding this correctly: in a single document with multiple images, GS will get stuck on image with the original lyx.bat file, then process that image correctly but get stuck on a later one if you comment something out of lyx.bat? (And how far it gets depends on what you comment out?) This is what I'm seeing. Why does 1.4.1 work all the time? What changed? Good question. Another good question is: why only on your machine. There must be something specific to your setup interacting with something specific to version 1.4.2. One more little experiment, if you don't mind, just to confirm symptoms: if you comment out one of the SET commands in lyx.bat, but replace it with a line of equal length (SET XXX=Y... with enough Xs and Ys to match the line you commented out), does the bug move to a different image (or disappear)? This reminds me of a bug I ran into in a computer science class back when mainframes ruled. It made no sense, and was hard to pin down. So I turned in a heap of line printer output showing what was going on, and my instructor looked at it and closed the matter by blithely stating "This can't happen." (Turned out the computer was subtracting incorrectly in an emulation mode.) So if all else fails, just tell yourself that "This can't happen" and therefore the display is actually correct, sensory evidence to the contrary notwithstanding. /Paul
Re: Fw: Postscript preview
I want to make sure I'm understanding this correctly: in a single document with multiple images, GS will get stuck on image with the original lyx.bat file, then process that image correctly but get stuck on a later one if you comment something out of lyx.bat? (And how far it gets depends on what you comment out?) This is what I'm seeing. Why does 1.4.1 work all the time? What changed? Leo
Re: Fw: Postscript preview
LB wrote: Lyx (or GS) gets "stuck" at different figures depending on what I comment out in lyx.bat. I want to make sure I'm understanding this correctly: in a single document with multiple images, GS will get stuck on image with the original lyx.bat file, then process that image correctly but get stuck on a later one if you comment something out of lyx.bat? (And how far it gets depends on what you comment out?) If so, that really points to a memory buffer issue someplace (but who knows where). /Paul
Re: Fw: Postscript preview
Does it display the same old symptoms; it works with lyx.exe or if you delete one of the "set" commands in lyx.bat? Lyx (or GS) gets "stuck" at different figures depending on what I comment out in lyx.bat. If the figure doesn't work with lyx.exe then it is the file. Try it with both (the old one which now works and the broken new one) in the same directory. A rather inexplicable matter. The old versions display all figures fine. I have been suspecting the figure files themselves for a while but I don't really understand what the problem could possibly be. Leo
Re: Fw: Postscript preview
LB wrote: I uninstalled Lyx and reinstalled it into c:\lyx\lyx14. This solved my figure problem!!! Thank you. I can now use 1.4.2 Looks like I spoke too soon. Now a different figure does not want to be displayed. Leo Does it display the same old symptoms; it works with lyx.exe or if you delete one of the "set" commands in lyx.bat? If the figure doesn't work with lyx.exe then it is the file. Try it with both (the old one which now works and the broken new one) in the same directory. A rather inexplicable matter. Perplexed, Stephen
Re: Fw: Postscript preview
On 8/1/06, LB <[EMAIL PROTECTED]> wrote: > I uninstalled Lyx and reinstalled it into c:\lyx\lyx14. This solved my > figure problem!!! > > Thank you. I can now use 1.4.2 Looks like I spoke too soon. Now a different figure does not want to be displayed. I do not know what have gone wrong, just want to say that lyx 1.4.3 will use a python script to do the conversion and your problem may or may not go away. Right now, your best bet may be 1.4.1, if it works well for you. Cheers, Bo
Re: Fw: Postscript preview
LB wrote: I uninstalled Lyx and reinstalled it into c:\lyx\lyx14. This solved my figure problem!!! Thank you. I can now use 1.4.2 Looks like I spoke too soon. Now a different figure does not want to be displayed. Leo But the original one does display, even when loaded from its original (deep) directory? Have you considered offering a small sacrifice (perhaps a wolverine) to the gods of computing? /Paul
Re: Fw: Postscript preview
I uninstalled Lyx and reinstalled it into c:\lyx\lyx14. This solved my figure problem!!! Thank you. I can now use 1.4.2 Looks like I spoke too soon. Now a different figure does not want to be displayed. Leo
Re: Postscript preview
LB wrote: When I start lyx1.4.2 I see two black windows (shell windows???) pop-up and dissapear before Lyx actually appears. Lyx1.4.1 only flashes one black window. Does that mean anything? Normal behavior. The first window is lyx.bat; as soon as it starts lyx.exe, it exits. The second window is lyx.exe, which has a DOS background window temporarily until it dismisses/kills that window. I think. /Paul
Re: Fw: Postscript preview
Hi Stephen I uninstalled Lyx and reinstalled it into c:\lyx\lyx14. This solved my figure problem!!! Thank you. I can now use 1.4.2 Leo LB wrote: The paths are not supposed to be the same. LyX 1.4.1 did not install a python directory under LyX. Also the batfiles are not the same. This usually happens when the preferences files under c:\documents and settings\yourusername~~~\~ are not deleted during the uninstall. Then the next version picks up the old preferences and sometimes doesn't work right. Maybe you have more than just two copies of LyX installed, 1.4.1 and 1.4.2. You can do a Windows Search for the filename lyx.exe and see if if reports more than two instances on your C drive. Also do a search for "preferences". Ok. I did not uninstall old versions of Lyx because I'm always worried about upgrading to a new version when an old one is working fine and not being able to open older documents with the new versions. So I have in the Lyx directory four subdirectories Lyx1.3.3, Lyx1.3.5, Lyx1.4.1 and Lyx1.4.2 that contain the four different installs. I only have one "preferences" file in .lyx directory though. Leo C:\Documents and Settings\Stephen\Application Data\LyX I have a preference file (your^username) and lyxrc.defaults in this directory. WinXP hides some directories; so your ~\Application Data directory contains no LyX* sub-directory? I have CygwinLyX1.4.1 and native Windows Lyx1.4.2 both installed without conflict. In the past I've had trouble with Cygwin's version of Ghostscript conflicting with the Windows version of Ghostscript. And when I tried to install TexLive2005 which is very much like Miktex, I had to fix a conflict with environmental variables, Texmfdir, I think. Your files test OK on my system. I think you should try uninstalling LyX1.4.2 (there is a Cygwin1.4.2 available) and installing it to the default C:\LyX\lyx14 directory, it is designed not to conflict with concurrent versions. Windows doesn't like a dot, . , prefix to directories and you can't make them in Windows Explorer, just Dos. If you do, remember to put the system Python installation at the front of Path_prefix, the local lyx one is tired. You've noticed the batfiles are different, 141 to 142... I don't understand what the 142 batfile does well enough to suggest using the 141 batfile instead of the 142 bat. SET LC_ALL=en_EN versus SET LANG=en_EN which used to work. Stephen
Re: Fw: Postscript preview
LB wrote: The paths are not supposed to be the same. LyX 1.4.1 did not install a python directory under LyX. Also the batfiles are not the same. This usually happens when the preferences files under c:\documents and settings\yourusername~~~\~ are not deleted during the uninstall. Then the next version picks up the old preferences and sometimes doesn't work right. Maybe you have more than just two copies of LyX installed, 1.4.1 and 1.4.2. You can do a Windows Search for the filename lyx.exe and see if if reports more than two instances on your C drive. Also do a search for "preferences". Ok. I did not uninstall old versions of Lyx because I'm always worried about upgrading to a new version when an old one is working fine and not being able to open older documents with the new versions. So I have in the Lyx directory four subdirectories Lyx1.3.3, Lyx1.3.5, Lyx1.4.1 and Lyx1.4.2 that contain the four different installs. I only have one "preferences" file in .lyx directory though. Leo C:\Documents and Settings\Stephen\Application Data\LyX I have a preference file (your^username) and lyxrc.defaults in this directory. WinXP hides some directories; so your ~\Application Data directory contains no LyX* sub-directory? I have CygwinLyX1.4.1 and native Windows Lyx1.4.2 both installed without conflict. In the past I've had trouble with Cygwin's version of Ghostscript conflicting with the Windows version of Ghostscript. And when I tried to install TexLive2005 which is very much like Miktex, I had to fix a conflict with environmental variables, Texmfdir, I think. Your files test OK on my system. I think you should try uninstalling LyX1.4.2 (there is a Cygwin1.4.2 available) and installing it to the default C:\LyX\lyx14 directory, it is designed not to conflict with concurrent versions. Windows doesn't like a dot, . , prefix to directories and you can't make them in Windows Explorer, just Dos. If you do, remember to put the system Python installation at the front of Path_prefix, the local lyx one is tired. You've noticed the batfiles are different, 141 to 142... I don't understand what the 142 batfile does well enough to suggest using the 141 batfile instead of the 142 bat. SET LC_ALL=en_EN versus SET LANG=en_EN which used to work. Stephen
Re: Fw: Postscript preview
The paths are not supposed to be the same. LyX 1.4.1 did not install a python directory under LyX. Also the batfiles are not the same. This usually happens when the preferences files under c:\documents and settings\yourusername~~~\~ are not deleted during the uninstall. Then the next version picks up the old preferences and sometimes doesn't work right. Maybe you have more than just two copies of LyX installed, 1.4.1 and 1.4.2. You can do a Windows Search for the filename lyx.exe and see if if reports more than two instances on your C drive. Also do a search for "preferences". Ok. I did not uninstall old versions of Lyx because I'm always worried about upgrading to a new version when an old one is working fine and not being able to open older documents with the new versions. So I have in the Lyx directory four subdirectories Lyx1.3.3, Lyx1.3.5, Lyx1.4.1 and Lyx1.4.2 that contain the four different installs. I only have one "preferences" file in .lyx directory though. Leo
Re: Fw: Postscript preview
LB wrote: Hi one more idea: if this is really a PATH problem and things worked normally under lyx 1.4.1, then I would do the following simple steps (unless you already tried this and I didn't see it in the earlier messages): (a) Revert to LyX 1.4.1 and open the Preferences dialog to find out EXACTLY what your PATH setting is in that program. The path in 1.4.1: C:\LyX\Python24;C:\LyX\msys\1.0\bin;C:\LyX\texmf\miktex\bin;c:\lyx\gs\gs8.14\bin;C:\LyX\ImageMagick (b) Copy that string. (c) Re-install LyX 1.4.2 and open the Prefs dialog there to see its PATH settings. I would strongly suspect that this is somehow different from 1.4.1. Reinstalled Lyx 1.4.2 Its PATH is: C:\LyX\Python24;C:\LyX\msys\1.0\bin;C:\LyX\texmf\miktex\bin;c:\lyx\gs\gs8.14\bin;C:\LyX\ImageMagick>>> (d)>> Enter the previously copied PATH from 1.4.1 into the PATH box in 1.4.2.> The paths are exactly the same;>>> (e)>> Restart LyX 1.4.2 (just to be safe), and see if the preview works now.>This also did not work.Thank youLeo The paths are not supposed to be the same. LyX 1.4.1 did not install a python directory under LyX. Also the batfiles are not the same. This usually happens when the preferences files under c:\documents and settings\yourusername~~~\~ are not deleted during the uninstall. Then the next version picks up the old preferences and sometimes doesn't work right. Maybe you have more than just two copies of LyX installed, 1.4.1 and 1.4.2. You can do a Windows Search for the filename lyx.exe and see if if reports more than two instances on your C drive. Also do a search for "preferences". Regards, Stephen
Re: Postscript preview
When I start lyx1.4.2 I see two black windows (shell windows???) pop-up and dissapear before Lyx actually appears. Lyx1.4.1 only flashes one black window. Does that mean anything? Leo
Fw: Postscript preview
Hi one more idea: if this is really a PATH problem and things worked normally under lyx 1.4.1, then I would do the following simple steps (unless you already tried this and I didn't see it in the earlier messages): (a) Revert to LyX 1.4.1 and open the Preferences dialog to find out EXACTLY what your PATH setting is in that program. The path in 1.4.1: C:\LyX\Python24;C:\LyX\msys\1.0\bin;C:\LyX\texmf\miktex\bin;c:\lyx\gs\gs8.14\bin;C:\LyX\ImageMagick (b) Copy that string. (c) Re-install LyX 1.4.2 and open the Prefs dialog there to see its PATH settings. I would strongly suspect that this is somehow different from 1.4.1. Reinstalled Lyx 1.4.2 Its PATH is: C:\LyX\Python24;C:\LyX\msys\1.0\bin;C:\LyX\texmf\miktex\bin;c:\lyx\gs\gs8.14\bin;C:\LyX\ImageMagick>>> (d)>> Enter the previously copied PATH from 1.4.1 into the PATH box in 1.4.2.> The paths are exactly the same;>>> (e)>> Restart LyX 1.4.2 (just to be safe), and see if the preview works now.>This also did not work.Thank youLeo
Re: Postscript preview
Hello I didn't have any bright ideas. But since it seems you are close to giving up, I thought I would toss out some longshots. " PROGRA~1\MENTOR~1\PADS\2005_1\Programs;c:\lyx\ly " (from 7/28/2006 12:03 pm, PATH report) SH: Maybe that is a typo the "ly" looks wrong. This was not a typo. That's what my path is set to. I'm not sure what sets the path to LyX but that clearly did not work although fixing this did not solve the problem with the figure. As Jose mentions, upgrading Ghostscript might help, because version 7.07 had a bug with paths with spaces. I have GS 8.14 installed. A very longshot is that the local LyX Python is buggy with utf8 support but those files don't cure it. Do you have the full Python installed? If so put it at the front of Path_prefix statement in LyX and it will supersede the local partial version of Python. I have Python 2.4.3 installed. I put it in front of Path_prefix but that did not help. Vaguely, the locale might connect to the set commands. I said it was a longshot. The set command used to say set lang=en_US if one used English. I couldn't find info on what LC does... This also did not make any difference. Thanks Leo
Re: Postscript preview
On Jul 29, 2006, at 9:09 PM, Stephen Harris wrote: LB wrote: When you added the GS path in lyx.bat, did you add the path to the lib directory as well as to the bin directory? Yes I did. I'm giving up and going back to use version 1.4.1. Well, I can't say I blame you ... 1.4.1 worked pretty well for me. I just hope this problem does not recur when we get to 1.5 and there is some "must have" new feature. BTW, I generated another figure with Matlab that has the same problem. It looks like when I generate figures with Matlab I run into trouble with previewing figure with 1.4.2 but not with any other versions. I have tried 1.4.1, 1.3.7 and 1.3.5. Cheers Leo I didn't have any bright ideas. But since it seems you are close to giving up, I thought I would toss out some longshots. " PROGRA~1\MENTOR~1\PADS\2005_1\Programs;c:\lyx\ly " (from 7/28/2006 12:03 pm, PATH report) SH: Maybe that is a typo the "ly" looks wrong. As Jose mentions, upgrading Ghostscript might help, because version 7.07 had a bug with paths with spaces. A very longshot is that the local LyX Python is buggy with utf8 support but those files don't cure it. Do you have the full Python installed? If so put it at the front of Path_prefix statement in LyX and it will supersede the local partial version of Python. Vaguely, the locale might connect to the set commands. I said it was a longshot. The set command used to say set lang=en_US if one used English. I couldn't find info on what LC does... Anyway replacing GS is a good idea, and if you already have the full Python, it is easy to *_prepend_* C:\Python243 to the LyX Path_prefix and have a fully functioning Python, since the extent of the local Python, mostly successful, may have other gaps. I've had a problem with set environmental variables once before. Another departed version of *tex had left its value behind and conflicted with the new version which wanted to set the same variable to a new place. (Cygwin and TexLive2005). Well, that was just rambling. Hi, one more idea: if this is really a PATH problem and things worked normally under lyx 1.4.1, then I would do the following simple steps (unless you already tried this and I didn't see it in the earlier messages): (a) Revert to LyX 1.4.1 and open the Preferences dialog to find out EXACTLY what your PATH setting is in that program. (b) Copy that string. (c) Re-install LyX 1.4.2 and open the Prefs dialog there to see its PATH settings. I would strongly suspect that this is somehow different from 1.4.1. (d) Enter the previously copied PATH from 1.4.1 into the PATH box in 1.4.2. (e) Restart LyX 1.4.2 (just to be safe), and see if the preview works now. Hope that helps, Jens
Re: Postscript preview
LB wrote: When you added the GS path in lyx.bat, did you add the path to the lib directory as well as to the bin directory? Yes I did. I'm giving up and going back to use version 1.4.1. Well, I can't say I blame you ... 1.4.1 worked pretty well for me. I just hope this problem does not recur when we get to 1.5 and there is some "must have" new feature. BTW, I generated another figure with Matlab that has the same problem. It looks like when I generate figures with Matlab I run into trouble with previewing figure with 1.4.2 but not with any other versions. I have tried 1.4.1, 1.3.7 and 1.3.5. Cheers Leo I didn't have any bright ideas. But since it seems you are close to giving up, I thought I would toss out some longshots. " PROGRA~1\MENTOR~1\PADS\2005_1\Programs;c:\lyx\ly " (from 7/28/2006 12:03 pm, PATH report) SH: Maybe that is a typo the "ly" looks wrong. As Jose mentions, upgrading Ghostscript might help, because version 7.07 had a bug with paths with spaces. A very longshot is that the local LyX Python is buggy with utf8 support but those files don't cure it. Do you have the full Python installed? If so put it at the front of Path_prefix statement in LyX and it will supersede the local partial version of Python. Vaguely, the locale might connect to the set commands. I said it was a longshot. The set command used to say set lang=en_US if one used English. I couldn't find info on what LC does... Anyway replacing GS is a good idea, and if you already have the full Python, it is easy to *_prepend_* C:\Python243 to the LyX Path_prefix and have a fully functioning Python, since the extent of the local Python, mostly successful, may have other gaps. I've had a problem with set environmental variables once before. Another departed version of *tex had left its value behind and conflicted with the new version which wanted to set the same variable to a new place. (Cygwin and TexLive2005). Well, that was just rambling. -- An ambient confluence of mapped coherence ~ Stephen
Re: Postscript preview
> When you added the GS path in lyx.bat, did you add the path to the lib > directory as well as to the bin directory? Yes I did. > > I'm giving up and going back to use version 1.4.1. > > Well, I can't say I blame you ... 1.4.1 worked pretty well for me. I > just hope this problem does not recur when we get to 1.5 and there is > some "must have" new feature. BTW, I generated another figure with Matlab that has the same problem. It looks like when I generate figures with Matlab I run into trouble with previewing figure with 1.4.2 but not with any other versions. I have tried 1.4.1, 1.3.7 and 1.3.5. Cheers Leo
Re: Postscript preview
LB wrote: Thank you Paul for all your help. Adding path to GS in lyx.bat did not solved the problem. I have this feeling that the problem is somehow related to the postscript commands inside the figure... I don't know much about Postscript, but I looked in your test.ps file a few days ago and did not see anything that looked like it had the potential to conflict with anything in the environment. When you added the GS path in lyx.bat, did you add the path to the lib directory as well as to the bin directory? The path to the bin directory would not seem to be an issue, since GS runs (enough to hang open, at any rate). I thought maybe if the lib directory were not on the path, GS might have trouble finding a library file. (Seems unlikely, but then the entire bug passed through 'unlikely' on its way to 'impossible' a while ago.) I'm giving up and going back to use version 1.4.1. Well, I can't say I blame you ... 1.4.1 worked pretty well for me. I just hope this problem does not recur when we get to 1.5 and there is some "must have" new feature. I'm going to post this to the developer list, just in case someone recognizes what's going on. /Paul
Re: Postscript preview
Thank you Paul for all your help. Adding path to GS in lyx.bat did not solved the problem. I have this feeling that the problem is somehow related to the postscript commands inside the figure... I'm giving up and going back to use version 1.4.1. Cheers Leo One other difference I notices is that I have the Ghostscript bin and lib directories on my system command path, and you don't. You must have them (as do I) in LyX Tools->Preferences...->Paths->PATH prefix, which LyX attaches to the command path when it shells out to a script. (In my case, they end up on the path twice, which is harmless.) I don't suppose that adding them to your path fixes the bug? (An easy way to try this on a temporary basis would be to add the line SET PATH=C:\\bin;C:\\lib;%PATH% to the lyx.bat file, prior to the start command.) I have no idea how a couple of environment variables and the length of the path to the target file can be interacting, other than if they're both being written to a common buffer somewhere (which is overflowing), and that seems rather unlikely given that I would be putting more stuff in the buffer and not seeing the problem. /Paul
Re: Postscript preview
LB wrote: Yes, moving the file test.lyx to C:\ solves the problem. The path to test.lyx is fairly long. It's located five directories deep. The path consists of 68 characters, including C: and "\", plus the file name. I have changed figure name to be only one character long, but that did not help. Hmm. I moved it to a directory seven levels below C:\ with a total path length of 159 characters, and it worked for me. This is what I get when I run "set" from command line: [...] Does not look like a lot of variables? No. In fact, it's about 935 characters total; my environment (also Win XP) is over 1800 characters. I saw your other post that this worked in 1.4.1 (presumably from the same deep directory). So there is something in the way LyX 1.4.2 shells to the graphics conversion script that has changed and is related to the problem. We also know that it works on my system and not on yours, and my environment and command path are both a lot messier than yours. One other difference I notices is that I have the Ghostscript bin and lib directories on my system command path, and you don't. You must have them (as do I) in LyX Tools->Preferences...->Paths->PATH prefix, which LyX attaches to the command path when it shells out to a script. (In my case, they end up on the path twice, which is harmless.) I don't suppose that adding them to your path fixes the bug? (An easy way to try this on a temporary basis would be to add the line SET PATH=C:\\bin;C:\\lib;%PATH% to the lyx.bat file, prior to the start command.) I have no idea how a couple of environment variables and the length of the path to the target file can be interacting, other than if they're both being written to a common buffer somewhere (which is overflowing), and that seems rather unlikely given that I would be putting more stuff in the buffer and not seeing the problem. /Paul
Re: Postscript preview
BTW, Lyx 1.4.1 displays the figure correctly. Leo LB wrote: I mentioned that editing out aiksaurus line in lyx.bat fixed the problem. It turns out that removing "SET LC_ALL=en_EN" also fixes the problem. Renaming aiksaurus directory however does not fix it. Starting Lyx.exe directly also fixes the problem. It the lyx.bat that causes this problem somehow. Ok, this makes me return to my theory that you are somehow running out of environment space. That would be consistent with the batch file symptoms, although why it would affect just the one Postscript image is a mystery, as is why freeing space by eliminating some of the other environment variables did not fix things. Is the path to test.ps fairly long? If so, do you cure the problem by copying test.ps to a directory with a shorter path (say C:\temp) and pointing test.lyx at the copy? I tried the -debug All option in ImageMagick. Amazingly enough, it gives no information I can see about calls to Ghostscript, let alone what arguments are being passed. /Paul
Re: Postscript preview
Yes, moving the file test.lyx to C:\ solves the problem. The path to test.lyx is fairly long. It's located five directories deep. The path consists of 68 characters, including C: and "\", plus the file name. I have changed figure name to be only one character long, but that did not help. This is what I get when I run "set" from command line: Microsoft(R) Windows DOS (C)Copyright Microsoft Corp 1990-2001. C:\DOCUME~1\LEOBEL~1>set COMSPEC=C:\WINDOWS\SYSTEM32\COMMAND.COM ALLUSERSPROFILE=C:\DOCUME~1\ALLUSE~1 APPDATA=C:\DOCUME~1\LEOBEL~1\APPLIC~1 CLIENTNAME=Console COMMONPROGRAMFILES=C:\PROGRA~1\COMMON~1 COMPUTERNAME=LEO FP_NO_HOST_CHECK=NO HOMEDRIVE=C: HOMEPATH=\Documents and Settings\Leo LOGONSERVER=\\LEO NUMBER_OF_PROCESSORS=2 OS=Windows_NT PADS_PROGRAMS=Programs PADS_ROOT=C:\Program Files\Mentor Graphics\PADS\2005_1 PATH=c:\lyx\IMAGEM~1;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\ PROGRA~1\MENTOR~1\PADS\2005_1\Programs;c:\lyx\ly PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH PROCESSOR_ARCHITECTURE=x86 PROCESSOR_IDENTIFIER=x86 Family 15 Model 3 Stepping 3, GenuineIntel PROCESSOR_LEVEL=15 PROCESSOR_REVISION=0303 PROGRAMFILES=C:\PROGRA~1 PROMPT=$P$G SESSIONNAME=Console SYSTEMDRIVE=C: SYSTEMROOT=C:\WINDOWS TEMP=C:\WINDOWS\TEMP TMP=C:\WINDOWS\TEMP USERDOMAIN=LEO USERNAME=Leo USERPROFILE=C:\DOCUME~1\LEOBEL~1 BLASTER=A220 I5 D1 P330 T3 Does not look like a lot of variables? Thank you Leo Ok, this makes me return to my theory that you are somehow running out of environment space. That would be consistent with the batch file symptoms, although why it would affect just the one Postscript image is a mystery, as is why freeing space by eliminating some of the other environment variables did not fix things. Is the path to test.ps fairly long? If so, do you cure the problem by copying test.ps to a directory with a shorter path (say C:\temp) and pointing test.lyx at the copy? I tried the -debug All option in ImageMagick. Amazingly enough, it gives no information I can see about calls to Ghostscript, let alone what arguments are being passed. /Paul
Re: Postscript preview
LB wrote: I mentioned that editing out aiksaurus line in lyx.bat fixed the problem. It turns out that removing "SET LC_ALL=en_EN" also fixes the problem. Renaming aiksaurus directory however does not fix it. Starting Lyx.exe directly also fixes the problem. It the lyx.bat that causes this problem somehow. Ok, this makes me return to my theory that you are somehow running out of environment space. That would be consistent with the batch file symptoms, although why it would affect just the one Postscript image is a mystery, as is why freeing space by eliminating some of the other environment variables did not fix things. Is the path to test.ps fairly long? If so, do you cure the problem by copying test.ps to a directory with a shorter path (say C:\temp) and pointing test.lyx at the copy? I tried the -debug All option in ImageMagick. Amazingly enough, it gives no information I can see about calls to Ghostscript, let alone what arguments are being passed. /Paul
Re: Postscript preview
Hi Other than that one missing separator, everything looked good right up to the point where Ghostscript went stupid on you. I'm assuming that the path is correct (i.e., that C:\\test.ps is really where test.ps is located). I don't know enough about ImageMagick and Ghostscript to know if there's any way to put either into a debug mode where we could see what was being passed to Ghostscript. The path is correct and the missing separator was my mistake made while editing the debug output. You said that commenting out the line in lyx.bat that set the aiksaurus environment variable fixed the problem, right? What happens if you leave that line in, and use lyx.bat, but hide the Lyx\aiksaurus folder? (An easy way to do this is to rename it to aiksaurus$.) That would tell us whether the bug actually involved any files in the aiksaurus folder. I mentioned that editing out aiksaurus line in lyx.bat fixed the problem. It turns out that removing "SET LC_ALL=en_EN" also fixes the problem. Renaming aiksaurus directory however does not fix it. Starting Lyx.exe directly also fixes the problem. It the lyx.bat that causes this problem somehow. Also, have you experienced this with any other Postscript image files? Not yet. Very mysterious. Indeed. Leo
Re: Postscript preview
LB wrote: Hello I added the "echo" line in convertDefault.sh script. The following are the error message that I see: filetools(getFormatFromContents) File type not recognised before EOF! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) File type not recognised before EOF! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) File type not recognised before EOF! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) File type not recognised before EOF! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) File type not recognised before EOF! filetools(getFormatFromContents) Couldn't find a known format! Token: 'filename' Token: '\end_inset' LoaderQueue: waking up The font scaling factor is 129.6 LoaderQueue: 1 items in the queue Recognised Fileformat: eps [GrahicsCacheItem::convertToDisplayFormat] Attempting to convert image file: C://test.ps with displayed filename: C:\\test.ps Recognised Fileformat: eps The file contains eps format data. Unable to convert from eps to bmp Unable to convert from eps to jpg Unable to convert from eps to pbm Unable to convert from eps to pgm Unable to convert from eps to png Unable to convert from eps to ppm Unable to convert from eps to xbm Unable to convert from eps to xpm Converting it to ppm format. Converter c-tor: from_file: C://test.ps to_file_base: C:/Documents and Settings/here>/Temp/lyx_tmpdir2744a03372/test2744a03372 from_format: eps to_format:ppm build_script ... ready (edgepath.empty()) No converter defined! I use convertDefault.sh sh "C:/LyX/LyX1.4.2/Resources/scripts/convertDefault.sh" "eps:C://test.ps" "ppm:C:/Documents and Settings/here>/Temp/lyx_tmpdir2744a03372/test2744a03372.ppm" ForkedCallQueue: waking up LoaderQueue: I'm going to sleep Converting eps:C:/test.ps ^ There's a missing separator (/) here. I'm guessing that's just a typo when you transcribed the output, but if not, it might be a clue. to ppm:C:/Documents and Settings/ id here>/Temp/lyx_tmpdir2744a03372/test2744a03372.ppm ... AFPL Ghostscript 8.14 (2004-02-20) Copyright (C) 2004 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. GS> Any clues? Other than that one missing separator, everything looked good right up to the point where Ghostscript went stupid on you. I'm assuming that the path is correct (i.e., that C:\\test.ps is really where test.ps is located). I don't know enough about ImageMagick and Ghostscript to know if there's any way to put either into a debug mode where we could see what was being passed to Ghostscript. You said that commenting out the line in lyx.bat that set the aiksaurus environment variable fixed the problem, right? What happens if you leave that line in, and use lyx.bat, but hide the Lyx\aiksaurus folder? (An easy way to do this is to rename it to aiksaurus$.) That would tell us whether the bug actually involved any files in the aiksaurus folder. Also, have you experienced this with any other Postscript image files? Very mysterious. /Paul
Re: Postscript preview
Hello I added the "echo" line in convertDefault.sh script. The following are the error message that I see: filetools(getFormatFromContents) File type not recognised before EOF! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) File type not recognised before EOF! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) File type not recognised before EOF! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) File type not recognised before EOF! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) File type not recognised before EOF! filetools(getFormatFromContents) Couldn't find a known format! Token: 'filename' Token: '\end_inset' LoaderQueue: waking up The font scaling factor is 129.6 LoaderQueue: 1 items in the queue Recognised Fileformat: eps [GrahicsCacheItem::convertToDisplayFormat] Attempting to convert image file: C://test.ps with displayed filename: C:\\test.ps Recognised Fileformat: eps The file contains eps format data. Unable to convert from eps to bmp Unable to convert from eps to jpg Unable to convert from eps to pbm Unable to convert from eps to pgm Unable to convert from eps to png Unable to convert from eps to ppm Unable to convert from eps to xbm Unable to convert from eps to xpm Converting it to ppm format. Converter c-tor: from_file: C://test.ps to_file_base: C:/Documents and Settings/here>/Temp/lyx_tmpdir2744a03372/test2744a03372 from_format: eps to_format:ppm build_script ... ready (edgepath.empty()) No converter defined! I use convertDefault.sh sh "C:/LyX/LyX1.4.2/Resources/scripts/convertDefault.sh" "eps:C://test.ps" "ppm:C:/Documents and Settings/here>/Temp/lyx_tmpdir2744a03372/test2744a03372.ppm" ForkedCallQueue: waking up LoaderQueue: I'm going to sleep Converting eps:C:/test.ps to ppm:C:/Documents and Settings/here>/Temp/lyx_tmpdir2744a03372/test2744a03372.ppm ... AFPL Ghostscript 8.14 (2004-02-20) Copyright (C) 2004 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. GS> Any clues? Thank you Leo LB wrote: Hi When the image does not preview, the last a few lines in the debug window are: ForkedCallQueue: waking up LoaderQueue: I'm going to sleep AFPL Ghostscript 8.14 (2004-02-20) Copyright (C) 2004 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. GS> I need to "quit" Ghostscript at this time to get: convert.exe: no decode delegate for this image format `here>.ps'. convert.exe: missing an image filename `ppm:.ppm'. C:/LyX/LyX1.4.2/Resources/scripts/convertDefault.sh ERROR Execution of "convert" failed. Whereas when the image previews ok the last few lines in the debug window are: ForkedCallQueue: waking up LoaderQueue: I'm going to sleep ForkedCallQueue: I'm going to sleep Image conversion succeeded. Loading image. Image loading succeeded. GraphicsImage::getScaledDImensions() params.scale : 100 width : 497 height : 404 It appears that "Image conversion succeeded" does not appear when the image does not show in Lyx. It also look like that having the file deep in a long tree of subdirectories contributes to this problem as the same file work fine when placed in C:\ directory. Why I only have this problem with one particular figure is still very puzzling. When LyX needs to display your image, it calls the convertDefault.sh script, which in turn calls ImageMagick's convert.exe program to convert test.ps to test.ppm. ImageMagick then uses Ghostscript to read the .ps file. Judging by the fact that Ghostscript "hangs open" until you close it, and the "missing filename" bit later on, it looks to me as if the ImageMagick-to-Ghostscript call might somehow have lost or mangled the file name (?!). There's some relevant output just above the first line you quoted that would help. If you want to investigate this possibility, try the following. In the LyX
Re: Postscript preview
LB wrote:
Hi
When the image does not preview, the last a few lines in the debug
window are:
ForkedCallQueue: waking up
LoaderQueue: I'm going to sleep
AFPL Ghostscript 8.14 (2004-02-20)
Copyright (C) 2004 artofcode LLC, Benicia, CA. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
GS>
I need to "quit" Ghostscript at this time to get:
convert.exe: no decode delegate for this image format `here>.ps'.
convert.exe: missing an image filename `ppm:.ppm'.
C:/LyX/LyX1.4.2/Resources/scripts/convertDefault.sh ERROR
Execution of "convert" failed.
Whereas when the image previews ok the last few lines in the debug
window are:
ForkedCallQueue: waking up
LoaderQueue: I'm going to sleep
ForkedCallQueue: I'm going to sleep
Image conversion succeeded.
Loading image.
Image loading succeeded.
GraphicsImage::getScaledDImensions()
params.scale : 100
width : 497
height : 404
It appears that "Image conversion succeeded" does not appear when the
image does not show in Lyx. It also look like that having the file deep
in a long tree of subdirectories contributes to this problem as the same
file work fine when placed in C:\ directory.
Why I only have this problem with one particular figure is still very
puzzling.
When LyX needs to display your image, it calls the convertDefault.sh
script, which in turn calls ImageMagick's convert.exe program to convert
test.ps to test.ppm. ImageMagick then uses Ghostscript to read the .ps
file. Judging by the fact that Ghostscript "hangs open" until you close
it, and the "missing filename" bit later on, it looks to me as if the
ImageMagick-to-Ghostscript call might somehow have lost or mangled the
file name (?!). There's some relevant output just above the first line
you quoted that would help.
If you want to investigate this possibility, try the following. In the
LyX Resources\scripts, find convertDefault.sh and open it with a text
editor (e.g., notepad). Find the lines
# converts an image from $1 to $2 format
convert -depth 8 "$1" "$2" || {
and insert
echo "Converting $1 to $2 ..."
between them. Then run with -dbg graphics again. You should get output
similar to what I got (albeit with different paths):
No converter defined! I use convertDefault.sh
sh "C:/Program
Files/LyX142/Resources/scripts/convertDefault.sh" "eps:C:
/Documents and Settings//Desktop/test.ps"
"ppm:C:/Temp/lyx_tmpdir5
620a03976/test5620a03976.ppm"
ForkedCallQueue: waking up
LoaderQueue: I'm going to sleep
Converting eps:C:/Documents and Settings//Desktop/test.ps
to ppm:C
:/Temp/lyx_tmpdir5620a03976/test5620a03976.ppm ...
ForkedCallQueue: I'm going to sleep
Image conversion succeeded.
Do the file names and paths look right when you do this?
/Paul
Re: Postscript preview
Hi When the image does not preview, the last a few lines in the debug window are: ForkedCallQueue: waking up LoaderQueue: I'm going to sleep AFPL Ghostscript 8.14 (2004-02-20) Copyright (C) 2004 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. GS> I need to "quit" Ghostscript at this time to get: convert.exe: no decode delegate for this image format `here>.ps'. convert.exe: missing an image filename `ppm:.ppm'. C:/LyX/LyX1.4.2/Resources/scripts/convertDefault.sh ERROR Execution of "convert" failed. Whereas when the image previews ok the last few lines in the debug window are: ForkedCallQueue: waking up LoaderQueue: I'm going to sleep ForkedCallQueue: I'm going to sleep Image conversion succeeded. Loading image. Image loading succeeded. GraphicsImage::getScaledDImensions() params.scale : 100 width : 497 height : 404 It appears that "Image conversion succeeded" does not appear when the image does not show in Lyx. It also look like that having the file deep in a long tree of subdirectories contributes to this problem as the same file work fine when placed in C:\ directory. Why I only have this problem with one particular figure is still very puzzling. Leo LB wrote: I tried that with no success. When starting LyX.exe without the lyx.bat, the figure works every time though. How do I display the shell windows that shows the debug messages? So I can see if there are any. Make a copy of lyx.bat, change the last line to lyx.exe -dbg graphics and then run the new batch file. (You can try -dbg any to get every message LyX spews, but be warned that is spews quite a few.) /Paul
Re: Postscript preview
LB wrote: I tried that with no success. When starting LyX.exe without the lyx.bat, the figure works every time though. How do I display the shell windows that shows the debug messages? So I can see if there are any. Make a copy of lyx.bat, change the last line to lyx.exe -dbg graphics and then run the new batch file. (You can try -dbg any to get every message LyX spews, but be warned that is spews quite a few.) /Paul
Re: Postscript preview
Hi I tried that with no success. When starting LyX.exe without the lyx.bat, the figure works every time though. How do I display the shell windows that shows the debug messages? So I can see if there are any. Leo - Original Message - From: "Paul A. Rubin" <[EMAIL PROTECTED]> To: Sent: Wednesday, July 26, 2006 6:42 PM Subject: Re: Postscript preview LB wrote: I think I'm getting somewhere with this. It turns out that when I start lyx by using lyx.bat file from bin directory I get the problem with the figure. However if I run lyx.exe the problem disappears. This is what my lyx.bat looks like: @echo off SET LC_ALL=en_EN SET AIK_DATA_DIR=C:\LyX\LyX1.4.2\aiksaurus start "LyX" "C:\LyX\LyX1.4.2\bin\lyx.exe" %* When I comment out line "SET AIK_DATA_DIR=C:\LyX\LyX1.4.2\aiksaurus" the figure gets displayed fine. Why is this line causing the problem? It shouldn't be (and on my system it doesn't). I have the same directory and the same batch file (give or take the exact path to the LyX directories), and when I load your test document the image previews just fine. Aiksaurus is the thesaurus program used by LyX 1.4.2 (and new to this version), and on my system the aiksaurus folder contains two data files and nothing else. Given their names (meanings.dat, words.dat), I'm hard-pressed to believe that ImageMagick would be mistaking them for some sort of input to the graphic conversion process. One possibility comes to mind, but it's a real long-shot. Windows has some overall character limit for the environment. Back in the days of Win 3.x, this was a royal PITA, although there were ways to tweak it. I haven't had to mess with it in years, so my impression is that XP and 2K have gobs of environment space. However, if you have enough environment variables set (and a long enough command path), maybe possibly conceivably you're pushing the character limit. If you're maxed out, maybe the line you're commenting out ate up so enough space that the command line for converting your image ran out of room. (For this to make sense, given your ability to display other images, I suspect this particular image would need to have a longer than usual name+path.) Off-hand, the easiest way I can see to test this theory is as follows: Revert to the original batch file (i.e., don't comment out the aiksaurus line). Open a command shell and type 'set' to see all the environment variables. Pick a few that don't have anything to do with LyX or ImageMagick and get rid of them (by executing 'set =' with nothing to the right of the equal sign). Then run lyx.bat, load your document and see if the image displays. To repeat myself, this is a bit of a grope in the dark. /Paul
Re: Postscript preview
LB wrote: I think I'm getting somewhere with this. It turns out that when I start lyx by using lyx.bat file from bin directory I get the problem with the figure. However if I run lyx.exe the problem disappears. This is what my lyx.bat looks like: @echo off SET LC_ALL=en_EN SET AIK_DATA_DIR=C:\LyX\LyX1.4.2\aiksaurus start "LyX" "C:\LyX\LyX1.4.2\bin\lyx.exe" %* When I comment out line "SET AIK_DATA_DIR=C:\LyX\LyX1.4.2\aiksaurus" the figure gets displayed fine. Why is this line causing the problem? It shouldn't be (and on my system it doesn't). I have the same directory and the same batch file (give or take the exact path to the LyX directories), and when I load your test document the image previews just fine. Aiksaurus is the thesaurus program used by LyX 1.4.2 (and new to this version), and on my system the aiksaurus folder contains two data files and nothing else. Given their names (meanings.dat, words.dat), I'm hard-pressed to believe that ImageMagick would be mistaking them for some sort of input to the graphic conversion process. One possibility comes to mind, but it's a real long-shot. Windows has some overall character limit for the environment. Back in the days of Win 3.x, this was a royal PITA, although there were ways to tweak it. I haven't had to mess with it in years, so my impression is that XP and 2K have gobs of environment space. However, if you have enough environment variables set (and a long enough command path), maybe possibly conceivably you're pushing the character limit. If you're maxed out, maybe the line you're commenting out ate up so enough space that the command line for converting your image ran out of room. (For this to make sense, given your ability to display other images, I suspect this particular image would need to have a longer than usual name+path.) Off-hand, the easiest way I can see to test this theory is as follows: Revert to the original batch file (i.e., don't comment out the aiksaurus line). Open a command shell and type 'set' to see all the environment variables. Pick a few that don't have anything to do with LyX or ImageMagick and get rid of them (by executing 'set =' with nothing to the right of the equal sign). Then run lyx.bat, load your document and see if the image displays. To repeat myself, this is a bit of a grope in the dark. /Paul
Re: Postscript preview
I think I'm getting somewhere with this. It turns out that when I start lyx by using lyx.bat file from bin directory I get the problem with the figure. However if I run lyx.exe the problem disappears. This is what my lyx.bat looks like: @echo off SET LC_ALL=en_EN SET AIK_DATA_DIR=C:\LyX\LyX1.4.2\aiksaurus start "LyX" "C:\LyX\LyX1.4.2\bin\lyx.exe" %* When I comment out line "SET AIK_DATA_DIR=C:\LyX\LyX1.4.2\aiksaurus" the figure gets displayed fine. Why is this line causing the problem? Leo LB wrote: Ok, this means it has something to do with my setup. I'm just surprised that this one particular figure causes the problem while all others figures work just fine. How can I run Lyx in debug mode to see what is happening? Leo From a command shell (either in the LyX bin directory or with it on your command path) run 'lyx.exe -dbg any'. (That produces a ton of output -- you might want to try just 'lyx.exe -dbg graphics' first.) Adjust 'lyx.exe' to whatever the binary is called on your system. /Paul
Re: Postscript preview
LB wrote: Ok, this means it has something to do with my setup. I'm just surprised that this one particular figure causes the problem while all others figures work just fine. How can I run Lyx in debug mode to see what is happening? Leo From a command shell (either in the LyX bin directory or with it on your command path) run 'lyx.exe -dbg any'. (That produces a ton of output -- you might want to try just 'lyx.exe -dbg graphics' first.) Adjust 'lyx.exe' to whatever the binary is called on your system. /Paul
Re: Postscript preview
Am Mittwoch, 26. Juli 2006 15:51 schrieb LB: > Ok, this means it has something to do with my setup. I'm just surprised > that this one particular figure causes the problem while all others figures > work just fine. > How can I run Lyx in debug mode to see what is happening? export a .tex file and run it 2-3 times with latex .tex Wolfgang
Re: Postscript preview
Ok, this means it has something to do with my setup. I'm just surprised that this one particular figure causes the problem while all others figures work just fine. How can I run Lyx in debug mode to see what is happening? Leo Bo Peng wrote: The Lyx document and the postscript file are attached. I can view the figure (converted successfully) under windows, using lyx 1.4.2. Bo Same here (LyX 1.4.2, WinXP). It takes a couple of seconds on my laptop for the image to convert, but convert it does. /Paul
Re: Postscript preview
Bo Peng wrote: The Lyx document and the postscript file are attached. I can view the figure (converted successfully) under windows, using lyx 1.4.2. Bo Same here (LyX 1.4.2, WinXP). It takes a couple of seconds on my laptop for the image to convert, but convert it does. /Paul
Re: ***SPAM*** Postscript preview
The Lyx document and the postscript file are attached. I can view the figure (converted successfully) under windows, using lyx 1.4.2. Bo
Postscript preview
Hello I have been inserting figures in Lyx (1.4.2 Windows XP) dozens of times and never had any problems with their previews. Until this time... I created a PostScript figure in Matlab ( the same procedure as I always use) and this figure would not get displayed in Lyx. The place holder for the figure shows "Converting to loadable format..." and does not proceed from there. This stops all the other figures to be shown. When I kill "convert.exe" process the rest of the document figures get displayed. The figure displays fine when the full document is displayed as a pdf or postscript. I ran "convert figure.ps figure.pgn" outside Lyx. That worked fine.When I open the file Lyx document with Lyx 1.4.1 the image is previewed fine also. The Lyx document and the postscript file are attached. Any suggestions? Thank you very much Leo test.ps Description: PostScript document test.lyx Description: application/lyx
Long lines are trimmed in the Postscript preview !!!
Hello all, I have to write some documentation and I have to insert a report example inside. The report example has very long lines (245 characters/line). I set the paper size to A3 orientation landscape. The report example lines I have defined them with "typewriter" font and "smaller". In DVI preview I can see very fine those long lines but when I want to see the Postscript preview the lines are cut ar 75% (I cannot see the whole line). It's not a Lyx problem, it's a dvips problem but can you help me somehow ? Please cc:me to [EMAIL PROTECTED] I someone is interested, I can send him as attachment a small file containing the example. Or, take the following lines , unwrap them (make a whole single line of them) and put it into a Lyx document. Set the page to A3 landscape and set the fonts for that line "typewriter" "smaller" and check if yu can see it with dvi preview. You should see the whole line. Check then the Postscript preview. You cannot see the last number (277.915.533) 1Capital... 110.779.526 329.297.681 11.463.388.344 11.435.820.024 2.006.877.388 2.093.843.106 13.470.265.732 13.529.663.130 13.581.045.258 13.858.960.811 0 277.915.553 (the line is begining with 1 and it is ending with 277.915.553) Thanks in advance, -- Constantin Teodorescu FLEX Consulting Braila, ROMANIA
