Re: Lyx for Win32, troubleshooting, Results

[Frédéric Wullens]

When I try to see eps picture in the Lyx window, Lyx uses convert.exe (I 
chose to do so) in order to convert the picture as either png, or bmp 
etc... formats. Having used the Lyx -dbg graphics function and having 
used by hand 'convert test.eps test', I could see that convert uses 
Ghostscript, perhaps to make the conversion. This is the message (below) 
I get and to be honest I do not understand very much of this. Could 
someone put some light on it? trying to use convertDefault.sh instead I 
kind of get the same error message as the ones discussed by Paul, Angus  
and Uwe last week. But I have to say that I do not really get the level 
of your discussion at the moment.
Thank you for your help, Frédéric

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
C:\Temp>convert temp.eps temp.png
AFPL Ghostscript 8.11 (2003-08-16)
Copyright (C) 2003 artofcode LLC, Benicia, CA.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Error: /undefinedfilename in (files\\gs\\gs8.11\\bin\\gswin32c.exe)
Operand stack:
Execution stack:
  %interp_exit   .runexec2   --nostringval--   --nostringval--   
--nostringval-
-   2   %stopped_push   --nostringval--   --nostringval--   
--nostringval--   fa
lse   1   %stopped_push
Dictionary stack:
  --dict:1104/1123(ro)(G)--   --dict:0/20(G)--   --dict:69/200(L)--
Current allocation mode is local
Last OS error: No such file or directory
AFPL Ghostscript 8.11: Unrecoverable error, exit code 1
AFPL Ghostscript 8.11 (2003-08-16)
Copyright (C) 2003 artofcode LLC, Benicia, CA.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Error: /undefinedfilename in (files\\gs\\gs8.11\\bin\\gswin32c.exe)
Operand stack:

Execution stack:
  %interp_exit   .runexec2   --nostringval--   --nostringval--   
--nostringval-
-   2   %stopped_push   --nostringval--   --nostringval--   
--nostringval--   fa
lse   1   %stopped_push
Dictionary stack:
  --dict:1104/1123(ro)(G)--   --dict:0/20(G)--   --dict:69/200(L)--
Current allocation mode is local
Last OS error: No such file or directory
AFPL Ghostscript 8.11: Unrecoverable error, exit code 1
convert: DPS library is not available (temp.eps).
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%



Angus Leeming wrote:

On Monday 27 October 2003 10:40 pm, Kayvan A. Sylvan wrote:
 

temp directory when the "Unable to find ..." message is generated.
The path and file name are correct.
       

Good. So we have probably nailed down the problem. The file is
generated correctly but LyX itself is unable to understand this
'mixed language' file name 'C:/foo/bar.ppm'.
     

Maybe it's not LyX, but LaTeX?
   

In the particular case we're discussing it's not LaTeX. The Win32 version of 
LyX is unable to display graphics files on screen if they need to first be 
converted to a 'loadable' format. It transpires that there are several bugs 
in the code when it comes to Win32 but the primary one is:

LyX calls the files stuff like 'C:/foo/bar.jpg'
It seems like the shell script and ImageMagick can handle this abuse but once 
LyX is told that the conversion has succeeded it has code:

void CacheItem::Impl::imageConverted(bool success)
{
       file_to_load_ = converter_.get() ?
               converter_->convertedFile() : string();
       success = !file_to_load_.empty() && IsFileReadable(file_to_load_);
       if (!success) {
               lyxerr[Debug::GRAPHICS] << "Unable to find converted file!"
                                       << endl;
               setStatus(ErrorConverting);
                return;
        }
        ...
}
I bet that 'IsFileReadable(file_to_load_)' can't handle 'C:/foo/bar.jpg'

Anyway, we go on from there to actually loading the file. Can Qt cope with 
such abuse? I'd be musch happier if we generated a 'reasonable' file name in 
the first place.

void QLImage::load(string const & filename)
{
       if (!pixmap_.load(toqstr(filename))) {
                lyxerr[Debug::GRAPHICS]
                        << "Unable to open image" << endl;
                return;
        }
 

I had a similar problem with the CVS lyx and had to apply the following
patch:
   

Yes, but this works around the problem rather than addresses the primary 
cause.

 

I may be right, or I may be crazy.
But it just might be a lunatic you're looking for...
   

In this case I want someone sane, but thanks for the offer ;-)
Regards,
Angus
 

--
-----------------------------------
Frédéric Wullens, PhD student
Department of Applied Acoustics
Chalmers University of Technology
41296 Göteborg, Sweden
tel: +46 (0)31 772 2203
fax: +46 (0)31 772 2212
-----------------------------------