On Wed, May 17, 2006 at 12:47:52AM +0200, Jean-Marc Lasgouttes wrote:
> It would be too easy :) Here is the new version that move this stuff
> to os::. I think I like it, but I have no idea whether it compiles on
> win32 and cygwin :)
It compiles on cygwin provided that the anon namespace is move
> Here is my wish list if you bother:
>
> 1. find a way to pass CCFLAGS options to gcc.
you can already pass CCFLAGS as environment variable, or in command
line, I just tried
scons CCFLAGS=-O2
and it works fine.
Bo
On Tue, May 16, 2006 at 04:58:01PM -0500, Bo Peng wrote:
> >Now, if I only could discover why that damn'd acrobat5 is used...
>
> We are all curious. :-)
Something bad happened to my win2k. When I double click on a pdf file
or use start on it, AcroRd32.exe version 7 is used. But when I check
the
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> > If your claim is right, then I have no concern.
>>
>> Yes, I tested it.
Bo> Then, the patch is perfect for me (subject to the acrobat 5/7
Bo> mystery), and ready to submit.
It would be too easy :) Here is the new version that move this stuf
On Wed, May 17, 2006 at 12:13:31AM +0200, Jean-Marc Lasgouttes wrote:
> > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
>
> >> However I cannot see (yet) a case where it will cause a problem.
> >> The case would be like 1) there is no official PDF viewer and 2)
> >> xpdf.exe is a p
On Tue, May 16, 2006 at 09:08:49PM +0200, Andre Poenitz wrote:
> On Mon, May 15, 2006 at 11:00:56PM +0200, Enrico Forestieri wrote:
> > > > BTW, in an xterm I can't CTRL+click on an URL to have it opened in
> > > > a browser.
> > >
> > > I would be surprised if one couldn't convince xsel together
> If your claim is right, then I have no concern.
Yes, I tested it.
Then, the patch is perfect for me (subject to the acrobat 5/7
mystery), and ready to submit.
Bo
On Tue, May 16, 2006 at 04:58:01PM -0500, Bo Peng wrote:
> >No need to do anything more than what JMarc did. Even if an executable
> >is picked by configure.py it will be masked by the one associated with
> >that format.
>
> Are you sure about this? I need to re-read the patch then. My
> understan
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
>> However I cannot see (yet) a case where it will cause a problem.
>> The case would be like 1) there is no official PDF viewer and 2)
>> xpdf.exe is a program that reformats the harddrive.
Enrico> You went very near it. Guess what
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> Are you sure about this?
Personnally I am.
Bo> I need to re-read the patch then.
It may be that the logic is wrong. But it was my intent anyway.
JMarc
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> The problem is also that you may miss the correctly associated
Bo> viewer (like acrobat reader, which does not change $PATH), because
Bo> of an indecent viewer.
Let me repeat again: if there is a correctly associated viewer, any
autodetected i
On Tue, May 16, 2006 at 10:06:55PM +0200, Jean-Marc Lasgouttes wrote:
> > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
> Enrico> Using your patch nothing is set to auto in lyxrc.defaults. In
> Enrico> the PDF entries I find "acroread" which is a shell script
> Enrico> calling acro
No need to do anything more than what JMarc did. Even if an executable
is picked by configure.py it will be masked by the one associated with
that format.
Are you sure about this? I need to re-read the patch then. My
understanding is that if an application is picked by configure.py, it
will not
On Tue, May 16, 2006 at 11:12:15PM +0200, Jean-Marc Lasgouttes wrote:
> > "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>
> >> Why is that? If you have nothing else associated to pdf anyway, it
> >> is better than nothing. I really do not understand your concern.
>
> Bo> Any decent windows view
On Tue, May 16, 2006 at 04:23:11PM -0500, Bo Peng wrote:
> >So you mean that, if there is no default viewer, you'd rather tell the
> >user that he cannot see the file, than display it with an undecent
> >viewer?
>
> A native windows application will do that.
>
> The problem is also that you may m
So you mean that, if there is no default viewer, you'd rather tell the
user that he cannot see the file, than display it with an undecent
viewer?
A native windows application will do that.
The problem is also that you may miss the correctly associated viewer
(like acrobat reader, which does not
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> Why is that? If you have nothing else associated to pdf anyway, it
>> is better than nothing. I really do not understand your concern.
Bo> Any decent windows viewer will associate itself with the format.
Bo> But the problem is that xpdf.exe may
Why is that? If you have nothing else associated to pdf anyway, it is
better than nothing. I really do not understand your concern.
Any decent windows viewer will associate itself with the format. But
the problem is that xpdf.exe may not be the only one, or the default
one to link with pdf, even
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> If xpdf.exe is in the $PATH, but not associated with pdf, we *do
Bo> not* want it.
Why is that? If you have nothing else associated to pdf anyway, it is
better than nothing. I really do not understand your concern.
Again, if something is ass
Bo> Minor concern: what if someone installs xpdf.exe? (is there such a
Bo> port?). xpdf will be set as view, instead of none.
If PDF is handled natively by windows, viewer will be set to "auto".
Otherwise, if it "none", it is reset to "". If it was autodetected
like "xpdf", this value is kept.
S
Dear list members,
If it is not too hard, I would really appreciate if someone could fix the
following enhancement to LyX:
In the Math Panel, under the Symbols list: Frame Decorations, I would like
to have the possibility to use the \overset and \underset commands.
See: http://bugzilla.lyx.org
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
>> This is very strange, I am not sure why the behaviour could be
>> different. Do you have one of the acrobat versions on your PATH?
Enrico> None of them is in the PATH.
>> Also, are the viewer and editor for PDF set to auto?
Enr
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> 1. configure.py get rid of win32 viewer names, but applications
Bo> are still searched and 'none' will be returned. Minor concern:
Bo> this slows down configure.py under windows.
I am not too concerned about this one.
Bo> Minor concern: what
I haven't used -lstdc++ for quite a while now, it should not be
necessary to specify it explicitly.
It really looks like some gcc vs g++ usage was messed up during
compilation/linking.
As long as things work, I do not care. I will check if I still need to
specify -lstdc++ after lyx renames .C t
On Mon, May 15, 2006 at 03:21:21PM -0500, Bo Peng wrote:
> >upgraded to this one (but stull need to comment out the re.sub line)
>
> I will have a look.
>
> >now it compiles, but fails during linking:
>
> I notice this one only after I test this by myself. Abdel seems to be
> using a more decent
On Mon, May 15, 2006 at 11:37:25PM +0200, Enrico Forestieri wrote:
> > This is just to add to the surreal part. :-D
>
> The funny thing is that once I was hard and pure as I think Andre' is...
I am not hard and pure. I just cannot convince KDE to move my
mouse pointer half a screen to the left
On Mon, May 15, 2006 at 11:00:56PM +0200, Enrico Forestieri wrote:
> > > BTW, in an xterm I can't CTRL+click on an URL to have it opened in
> > > a browser.
> >
> > I would be surprised if one couldn't convince xsel together with
> > .inputrc to do the same.
>
> But I am a tcsh fellow...
When I
Abdelrazak Younes a écrit :
Here is my wish list if you bother:
1. find a way to pass CCFLAGS options to gcc.
2. create multiple "config.h" in build directory not in the source (as
is done with autotools):
2.a. release/config.h for all general macro including
BOOST_USER_CONFIG
2.a.
forget the patch.
Bo
Index: development/scons/SConscript
===
--- development/scons/SConscript (revision 13852)
+++ development/scons/SConscript (working copy)
@@ -880,7 +880,7 @@
resources = [qt4env.Uic4(x) for x in qt4_ui_files]
> 2. qt4 adding "#include file_moc.cpp" to file.C. Abdel, I will give
> you a patch to test. If you see a clear advantage, I will complete the
> patch with autotools support.
That sounds like a good plan. Please note that the moc files are named
xxx_moc.C with autotools but I guess it's easy to c
Bo Peng a écrit :
to load an old document i needed to change
lyx2lyx_version.py.in
into
lyx2lyx_version.py
So the next big thing is this version_suffix business?
Anyway, I have on this scons TODO list,
1. remove unnecessay rebuild, since I found that adding fast_start=yes
can sometimes tri
conf.TryLink('#include ' + check_mkdir_one_arg_source, '.c')
Indeed, this is cleaner... Note though that I was just following your
advice about source_2 etc ;-)
I do remember that the idea was mine. :-) But even with that idea,
"TryLink(_source_1) or TryLink(_source_2)" is better than nested
if
OK, here is what I had in mind. The fixCommand helper looks a bit long
but this makes its intent clear I think.
I have a few questions (observations) about the patch:
1. configure.py get rid of win32 viewer names, but applications are
still searched and 'none' will be returned.
Minor concern:
Just to clarify two things, as my mail was vague.:
"it is also good to know that the
.lyx directory needs to be deleted else 1.3.7 do not enable the DVI viewer."
This is necessary if you downgrade from 1.4.x to 1.3.7. if you dont
destroy .lyx, then dvi option disappears from the view tab after
Bo Peng a écrit :
> I was not aware that scons does not handle python exceptions well so
Is that because of the low supported python version?
Also maybe because scons scans all instructions before executing any
of the real building step. Then, if a compile step fails, it does not
have to trigg
to load an old document i needed to change
lyx2lyx_version.py.in
into
lyx2lyx_version.py
So the next big thing is this version_suffix business?
Anyway, I have on this scons TODO list,
1. remove unnecessay rebuild, since I found that adding fast_start=yes
can sometimes trigger rebuild.
2. q
This appears to fix the bug in my limited testing (I couldn't reproduce the bug
in the
test file, only in the enum example)
- Martin
Index: CutAndPaste.C
===
--- CutAndPaste.C (revision 13690)
+++ CutAndPaste.C (working
> I was not aware that scons does not handle python exceptions well so
Is that because of the low supported python version?
Also maybe because scons scans all instructions before executing any
of the real building step. Then, if a compile step fails, it does not
have to trigger the try/except a
1.3.7 works just dandy thanks!
If someone does have the same problem, it is also good to know that the
.lyx directory needs to be deleted else 1.3.7 do not enable the DVI viewer.
It was only after I destroyed .lyx n my home directory that LyX worked fine.
I honestly could not find anything in t
On Tue, May 16, 2006 at 04:45:11PM +0200, Jean-Marc Lasgouttes wrote:
> > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
>
> Enrico> I would say it almost works, as it doesn't peek the correct
> Enrico> viewer for pdf files. I have both acrobat 5 and acroread 7 and
> Enrico> the la
Lv wrote:
> Do you know which LyX version would not create this error?
1.3.7 works fine. I would not use 1.4.0 (I don't know if it works there) as
it has other problems.
Georg
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Sigh. I don't want to undo anything, I only wanted to please
Georg> Bo. Now we have a different situation again and, and I'll wait
Georg> for you to commit.
OK, so if the patches do not interfere and if no new problems are
found, I'll
Jean-Marc Lasgouttes wrote:
> This one?
> http://bugzilla.lyx.org/show_bug.cgi?id=2178
Yes.
> BTW, there are many bugs assigned to 1.4.2 that will obviously not be
> fixed in this timeframe. I propose to create a new target "1.4.x" for
> bug we could/should fix in stable releases and move most o
Jean-Marc Lasgouttes wrote:
> Are we sure that the last patch does not do what Bo wanted? I think it
> makes more sense to separate the patches, unless your plan is to undo
> some of the changes in my patch.
Sigh. I don't want to undo anything, I only wanted to please Bo. Now we have
a different
Bo Peng a écrit :
>> any clue what i am missing here?
>
I was not aware that scons does not handle python exceptions well so
Is that because of the low supported python version?
the try/except tests have been removed, and a test for SOCKET_H is
added.
I have just tested, with the newest ve
> "Lv" == Lv <[EMAIL PROTECTED]> writes:
Lv> Do you know which LyX version would not create this error? I will
Lv> downgrade to that version as it used to work, but is not sure if
Lv> it is the immediate previous version. Lyx was automatically
Lv> updated with apt, so I lost track of when the
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
Enrico> I would say it almost works, as it doesn't peek the correct
Enrico> viewer for pdf files. I have both acrobat 5 and acroread 7 and
Enrico> the last is that associated with pdf files.
Enrico> I don't know what is happening, pe
Jean-Marc Lasgouttes wrote:
> That would be OK indeed. Now, who is doing it? :)
I nobody beats me to it I'll do it, but not before Thursday.
Georg
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
Enrico> I don't know why you seem to be so upset about the pollution
Enrico> of os.h. After all those declarations are #ifdef'd out for
Enrico> platforms different from cygwin.
Upset is not the word. The whole purpose of os.[Ch] was
Bo Peng a écrit :
This fixes the problem:
# Note that previously added QT_DIR/include etc is removed
# they will be added when processing for example src/qt3
- env['CPPPATH'] == ['$TOP_SRC_DIR/boost', '$TOP_SRC_DIR/src']
+ env['CPPPATH'] += ['$TOP_SRC_DIR/boost', '$TOP_SRC_DIR/src']
# TODO: ad
Bo Peng wrote:
>> any clue what i am missing here?
>
I was not aware that scons does not handle python exceptions well so
the try/except tests have been removed, and a test for SOCKET_H is
added.
I have just tested, with the newest version (just submitted), you
should be able to run scons ...
On Tue, May 16, 2006 at 09:16:26AM -0500, Bo Peng wrote:
> Patch confirms to work under win/mingw. Reading the patch now.
I would say it almost works, as it doesn't peek the correct viewer
for pdf files. I have both acrobat 5 and acroread 7 and the last
is that associated with pdf files.
I don't
On May 16, 2006, at 10:09 AM, David Green wrote:
Hi,
Thanks for the Intel OS X binary. A small nit:
The Intel binary that is linked to http://wiki.lyx.org/LyX/LyXOnMac
has a
link to a LyX.app which internally (i.e. the splash screen) says
1.4.1 but
the OS X's Get Info returns 1.4.0.
Da
On Tue, May 16, 2006 at 04:11:32PM +0200, Jean-Marc Lasgouttes wrote:
> > "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
>
> Georg> Jean-Marc Lasgouttes wrote:
> >> This is indeed a possibility. The only problem I see is that OSX
> >> uses os_unix.C. Where would you implement autoOpenFile?
>> any clue what i am missing here?
>
I was not aware that scons does not handle python exceptions well so
the try/except tests have been removed, and a test for SOCKET_H is
added.
I have just tested, with the newest version (just submitted), you
should be able to run scons ... install. (lyxcli
Do you know which LyX version would not create this error?
I will downgrade to that version as it used to work, but is not sure if
it is the immediate previous version.
Lyx was automatically updated with apt, so I lost track of when the
problem really started.
Georg Baum wrote:
Lv wrote:
On 5/16/06, Bo Peng <[EMAIL PROTECTED]> wrote:
>
> This fixes the problem:
>
> # Note that previously added QT_DIR/include etc is removed
> # they will be added when processing for example src/qt3
> - env['CPPPATH'] == ['$TOP_SRC_DIR/boost', '$TOP_SRC_DIR/src']
> + env['CPPPATH'] += ['$TOP_SRC_DI
Patch confirms to work under win/mingw. Reading the patch now.
Bo
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Jean-Marc Lasgouttes wrote:
>> This is indeed a possibility. The only problem I see is that OSX
>> uses os_unix.C. Where would you implement autoOpenFile?
Georg> Using #ifdef in os_unix.C. I don't see why this should be worse
Georg> t
Jean-Marc Lasgouttes wrote:
> This is indeed a possibility. The only problem I see is that OSX uses
> os_unix.C. Where would you implement autoOpenFile?
Using #ifdef in os_unix.C. I don't see why this should be worse than #ifdef
in filetools.C. If os_unix.C becomes too cluttered with ifdefs we co
Hi,
Thanks for the Intel OS X binary. A small nit:
The Intel binary that is linked to http://wiki.lyx.org/LyX/LyXOnMac has a
link to a LyX.app which internally (i.e. the splash screen) says 1.4.1 but
the OS X's Get Info returns 1.4.0.
Dave
--
David G. Green
UAB Electrical and Computer Engineer
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Bo Peng wrote:
>> Since JMarc's version of the patch does not solve every problem, I
>> would prefer waiting for your patch and test them together. This
>> should not cause you any trouble since your patch can be
>> developed/tested in
Bo Peng wrote:
> Since JMarc's version of the patch does not solve every problem, I
> would prefer waiting for your patch and test them together. This
> should not cause you any trouble since your patch can be
> developed/tested independent of this one.
OK, I will present a combined one, probably
This fixes the problem:
# Note that previously added QT_DIR/include etc is removed
# they will be added when processing for example src/qt3
- env['CPPPATH'] == ['$TOP_SRC_DIR/boost', '$TOP_SRC_DIR/src']
+ env['CPPPATH'] += ['$TOP_SRC_DIR/boost', '$TOP_SRC_DIR/src']
# TODO: add (more) appropriat
Jean-Marc Lasgouttes wrote:
>> "Georg" == Georg Baum
>> <[EMAIL PROTECTED]>
>> writes:
>
> Georg> I think it does. We have basicaly two groups of formats:
> Georg> Document formats (like tex, ps, dvi, pdf, ooffice etc) and
> Georg> image formats (xpm, bmp, png etc). Some formats (pdf
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Confirmed. Reason: The layout of the table cells is the default
Georg> layout of the text class. In the case of the letter class this
Georg> layout produces a \begin{letter}...\end{letter} for each cell.
Georg> Another reason to introd
Lv wrote:
> Attached two files.
>
> 1) without-tables.lyx
> 2) with-table.lyx
>
> The first (1) file produces dvi when compiled.
> The second (2) is simply (1) but adding an empty 5x5 table to
> "without-tables.lyx" using the tabletoolbar below the body text.
> LyX then refuses to display the DV
Bo Peng a écrit :
No, it's not that apparently. Commenting out the relevant code in
SConstruct (in order to use gcc) do not solve the problem.
Maybe it's related to a more general problem with environment variables
under Win/Mingw. Indeed CCFLAGS=-O3 option was never acknowledged by
Scons.
It
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> However, this pure windows path is only needed on windows, so
Georg> with some code reorganization all is well: Move autoOpenFile()
Georg> and canAutoOpenFile() to os, and provide dummy implementations
Georg> for the other OSes. Then y
Enrico Forestieri wrote:
> On Mon, May 15, 2006 at 11:55:33PM +0200, Jean-Marc Lasgouttes wrote:
>
>> OK, here is what I had in mind. The fixCommand helper looks a bit long
>> but this makes its intent clear I think.
>>
> I think that Windows remembers previous associations in the registry,
> so
Abdelrazak Younes wrote:
Edwin Leuven a écrit :
g++ -o release\common\client\client.o -c -Iboost -Isrc
src\client\client.C
src\client\client.C:44:20: sys/un.h: No such file or directory
any clue what i am missing here?
You are missing ... just kidding ;-)
one learns something everyday..
No, it's not that apparently. Commenting out the relevant code in
SConstruct (in order to use gcc) do not solve the problem.
Maybe it's related to a more general problem with environment variables
under Win/Mingw. Indeed CCFLAGS=-O3 option was never acknowledged by Scons.
It is a newly introduce
This header is not available for Mingw (it is available in the gw32
package but it is another story). In principle Scons should not try to
build the lyx client because of those missing header. Didn't you fixed
that Bo?
I continue to allow building of lyxclient, but failure to do so should
not af
Edwin Leuven a écrit :
g++ -o release\common\client\client.o -c -Iboost -Isrc src\client\client.C
src\client\client.C:44:20: sys/un.h: No such file or directory
any clue what i am missing here?
You are missing ... just kidding ;-)
This header is not available for Mingw (it is available in t
g++ -o release\common\client\client.o -c -Iboost -Isrc src\client\client.C
src\client\client.C:44:20: sys/un.h: No such file or directory
any clue what i am missing here?
thanks, edwin
Abdelrazak Younes a écrit :
Bo,
"extra_inc_path" is not appended to the CPP options after the configure
step. This is what I am doing:
D:\cygwin\home\yns\lyx\trunk\development\scons>scons CCFLAGS=-O3
qt_dir=d:/program/Qt/4.1 extra_inc_path=d:/program/Aspell-0.60.4/include
extra_lib_path=d:/
Attached two files.
1) without-tables.lyx
2) with-table.lyx
The first (1) file produces dvi when compiled.
The second (2) is simply (1) but adding an empty 5x5 table to
"without-tables.lyx" using the tabletoolbar below the body text.
LyX then refuses to display the DVI and gives a lot of LaTeX
Bo,
"extra_inc_path" is not appended to the CPP options after the configure
step. This is what I am doing:
D:\cygwin\home\yns\lyx\trunk\development\scons>scons CCFLAGS=-O3
qt_dir=d:/program/Qt/4.1 extra_inc_path=d:/program/Aspell-0.60.4/include
extra_lib_path=d:/program/Aspell-0.60.4/lib log
Jean-Marc Lasgouttes wrote:
"Hartmut" == Hartmut Haase <[EMAIL PROTECTED]> writes:
Hartmut> Jean-Marc, I had a discussion with Edwin Leuven about some
Hartmut> icons in .../images/math. Please find attached the ones he
Hartmut> sent to me. They are different from those which are in lyx141
Hartm
Bo Peng a écrit :
On 5/15/06, Edwin Leuven <[EMAIL PROTECTED]> wrote:
> The new version has just be submitted. I guess you will still have the
> re.sub problem, but linking should be fine.
it breaks here:
OK. I am discussing this with Abdel this morning. It seems that
windows/mingw does not h
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| Could a svn-enabled person tell me how to fix these files?
| Alternatively, could someone redo the screenshots?
Lars> Have you checked out www and had a look at the png files with a
Lars> viewer?
Yes, imagemagick tells me:
displ
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Mark" == Kortink, Mark A <[EMAIL PROTECTED]> writes:
|
| Mark> The screenshots don't load on
| Mark> http://www.lyx.org/about/screenshots.php
|
| You are right Mark. I think the files are damaged because they were
| not set as binary. I r
> "Mark" == Kortink, Mark A <[EMAIL PROTECTED]> writes:
Mark> The screenshots don't load on
Mark> http://www.lyx.org/about/screenshots.php
You are right Mark. I think the files are damaged because they were
not set as binary. I removed the eol-style property and added a
mime-type property to
Bo Peng a écrit :
On 5/15/06, Edwin Leuven <[EMAIL PROTECTED]> wrote:
> The new version has just be submitted. I guess you will still have the
> re.sub problem, but linking should be fine.
it breaks here:
OK. I am discussing this with Abdel this morning. It seems that
windows/mingw does not h
Bo Peng a écrit :
On 5/15/06, Edwin Leuven <[EMAIL PROTECTED]> wrote:
> The new version has just be submitted. I guess you will still have the
> re.sub problem, but linking should be fine.
it breaks here:
OK. I am discussing this with Abdel this morning. It seems that
windows/mingw does not h
Bo Peng a écrit :
upgraded to this one (but stull need to comment out the re.sub line)
I will have a look.
now it compiles, but fails during linking:
I notice this one only after I test this by myself. Abdel seems to be
using a more decent (?) g++ that is clever enough (like the linux
case)
Angus Leeming wrote:
LyX 1.4 copies all files that the dvi file references into the same temp
directory. That means that you should be able to generate the .dvi and zip up
the contents of the temp directory.
But it should not do so when using File > Export. Currently there are
never spaces in
87 matches
Mail list logo