Uwe Stöhr wrote: > LyXWin 1.3.6 version 21 doesn't install. I get the error > message: > LyXTextClassList::Read: unable to find textclass file `'. Exiting. > To reproduce this, delete the folder "lyx" in the Win folder > "Documents and settings" before you install LyX. (As if you have > never installed Lyx before).
Oh, for [EMAIL PROTECTED]'s sake! Thanks for the report. Now have you any idea why not? > If you view the DVI from within LyX yap crashes because the dvi file > uses then the path >PSfile="F:/lyxdokumente/lyx/tmp/lyx_tmpdir1060a00924/lyx_tmpbuf0/_lyxdokumente_FILENAME.eps > (where FILENAME has 220 chars) and this is too long for ghostscript > and Windows. (Yap uses ghostscript libraries to show eps-files in > dvi.) You can also see this when you use the maximal char number for > the filename in Lyx. Then convert.exe fails to convert the image to > ppm as convert also uses ghostscript. So the fault lies in ghostscript, not yap. Thanks for digging that out. However, Windows can certainly handle paths that are more than 300 characters long; this isn't an OS limitation at all. It's just a bug in the software. > But anyway, who uses such long filenames? We do. And why shouldn't we? PATH_MAX is 4096 on Linux machines and is the POSIX way to declare storage for a file path. Windows claims to be POSIX-compliant; I fail to see why apps that run on Windows have to go against perfectly sane standards. > Should we take care about this? Yes, of course we should. We don't live in a bubble and flaws in the tools that we use naturally affect us. However, if the bug has been squashed in recent versions of gs then I'm perfectly happy to say that the fix is to upgrade. > If yes, we could limit the filename length allowed for LyX to > 100 chars or so, but I don't think this solves the problem in > general. The advantage of using GetTempName() is that we get per-user temp directories which is a "good thing". However, C:\Documents and Settings\Angus\Local Settings\lyx_tmpdir1060a00924\lyx_tmpbuf0\ is already 78 characters long. Anyway, if the problem lies in ghostscript then perhaps the solution is to use a more modern version. The fact that yap crashed on Paul (and on you) and not on me suggests that my version of ghostscript is better in this regard than yours. (I'm using a fairly recent AFPL gs.) Certainly, it appears that gs has had similar problems reported (and squashed) in the recent past: http://bugs.ghostscript.com/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&field0-0-0=product&type0-0-0=substring&value0-0-0=path&field0-0-1=component&type0-0-1=substring&value0-0-1=path&field0-0-2=short_desc&type0-0-2=substring&value0-0-2=path&field0-0-3=status_whiteboard&type0-0-3=substring&value0-0-3=path Eg: http://bugs.ghostscript.com/show_bug.cgi?id=686989 More testing needed. -- Angus
