Uwe Stöhr wrote:

> We should get rid of clean_dvi.py as it prevents many LyX-files to be
> converted to DVI (tested under MiKTeX and TeXLive). I described the
> problematic in detail in bug 2836
> http://bugzilla.lyx.org/show_bug.cgi?id=2836
> 
> The problem occured in february this year when MiKTeX changed the
> hyperref driver to dvips as this was recommended by the LaTeX people.
> (TeXLive uses dvips as driver for years). Unfortunately the dt2dv/dv2dt
> programs used by clean_dv.py stumble over this.

It would probably not be difficult to fix that, the code is simple. In fact,
it will probbaly be less work to do that than to rip out all appareances of
clean_dvi from LyX and the installer.

> As quick and dirty workaround I changed MiKTeX's hyperref configuration
> back to the old version via my LyXWinInstaller. That's the reason why
> this problem isn't yet reported and if the users update from MiKTeX 2.4
> to 2.5 hyperref's cofiguration will be untouched.
> 
> I'll no longer change the hyperref driver by the installer (the just
> released version 2.6 will be the last version doing this) because newer
> hyperref versions might have problems with this so we need a solution now.
> 
> I mean we can get rid of the clean_dvi.py script because the yap and
> dvips versions delivered with MiKTeX 2.5 should be able to handle the
> cases the script was built for.

They should not, since the created DVI without clean_dvi is not valid DVI.
clean_dvi tries to correct some problems of the TeX engine with filenames
with spaces.

> If not (I couldn't test it because I 
> don't have a testfile) we should contact the authors of yap and dvips
> for a fix instead of using this script.
> As I remember correctly this script was built especially for LyX under
> Windows. If yes removing it should be unproblematic.

It has nothing windows specific. It is used as default under windows because
windows users tend to use filenames with spaces more than others.

It is a bit funny that the request to remove the script comes especially
from you, since you have insisted on other occasions that LyX must support
all sorts of wierd file names, and now you propose to just remove parts of
this support.


Georg

Reply via email to