On Tue, Nov 02, 2004 at 10:28:33AM +, Andreas Vox wrote:
Which, by the way, is now conceptually very easy. Just write a
postscript parser and away you go...
Shouldn't be as hard as parsing LaTeX, don't you think so? :-)
Not at all. Ghostscript can do it just fine and provides enough
On Tue, Nov 02, 2004 at 10:28:33AM +, Andreas Vox wrote:
> < Which, by the way, is now conceptually very easy. Just write a
> < postscript parser and away you go...
>
> Shouldn't be as hard as parsing LaTeX, don't you think so? :-)
Not at all. Ghostscript can do it just fine and provides
Georg Baum wrote:
BTW, am I correct that LyX does not support EPS files which
reference other files ... yet ;-) ?
Yes. But this is something that only very few programs support. Do
you want to create a .eps mover?
Which, by the way, is now conceptually very easy. Just write a
postscript
Angus Leeming [EMAIL PROTECTED] writes:
Georg Baum wrote:
BTW, am I correct that LyX does not support EPS files which
reference other files ... yet ?
Yes. But this is something that only very few programs support. Do
you want to create a .eps mover?
Which, by the way, is now
Am Dienstag, 2. November 2004 11:28 schrieb Andreas Vox:
Angus Leeming [EMAIL PROTECTED] writes:
Which, by the way, is now conceptually very easy. Just write a
postscript parser and away you go...
Shouldn't be as hard as parsing LaTeX, don't you think so? :-)
I am not so sure ;-)
Georg Baum wrote:
>
>> BTW, am I correct that LyX does not support EPS files which
>> reference other files ... yet ;-) ?
>
> Yes. But this is something that only very few programs support. Do
> you want to create a .eps mover?
Which, by the way, is now conceptually very easy. Just write a
Angus Leeming <[EMAIL PROTECTED]> writes:
< Georg Baum wrote:
<
< >
< >> BTW, am I correct that LyX does not support EPS files which
< >> reference other files ... yet ?
< >
< > Yes. But this is something that only very few programs support. Do
< > you want to create a .eps mover?
<
< Which,
Am Dienstag, 2. November 2004 11:28 schrieb Andreas Vox:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> < Which, by the way, is now conceptually very easy. Just write a
> < postscript parser and away you go...
>
> Shouldn't be as hard as parsing LaTeX, don't you think so? :-)
I am not so sure
On Sat, Oct 30, 2004 at 01:48:47PM +, Andreas Vox wrote:
Unfortunately it also resolves all contained file references
relative to the directory of the symlink, not relative to the
original file. So there's no real advantage to copying,
Okay, then I'm confused and don't understand what it
John Weiss wrote:
BTW: While Windoze doesn't have native symlinks, it does have
shortcuts. Additionally, with the Cygwin libraries, you can have
symlinks under Windoze. They work only with the Cygwin programs, but
that's a non-issue since (I assume) we need Cygwin for the Win-version
of
John Weiss [EMAIL PROTECTED] writes:
Okay, then I'm confused and don't understand what it is you're doing.
I was under the impression that the files in question weren't
generated, but were pre-existing EPS files. I was also under the
impression that you were moving everything to a
Andreas Vox wrote:
If I understand correctly, it' s not the problem with EPS files themselves
but with XFig files which reference EPS files, and TeX files which
reference EPS files which are either pre-existing or generated from XFig,
and about the resulting DVI files which have the same
On Sat, Oct 30, 2004 at 01:48:47PM +, Andreas Vox wrote:
> Unfortunately it also resolves all contained file references
> relative to the directory of the symlink, not relative to the
> original file. So there's no real advantage to copying,
Okay, then I'm confused and don't understand what
John Weiss wrote:
> BTW: While Windoze doesn't have native symlinks, it does have
> shortcuts. Additionally, with the Cygwin libraries, you can have
> symlinks under Windoze. They work only with the Cygwin programs, but
> that's a non-issue since (I assume) we need Cygwin for the Win-version
>
John Weiss <[EMAIL PROTECTED]> writes:
> Okay, then I'm confused and don't understand what it is you're doing.
> I was under the impression that the files in question weren't
> generated, but were pre-existing EPS files. I was also under the
> impression that you were "moving" everything to a
Andreas Vox wrote:
> If I understand correctly, it' s not the problem with EPS files themselves
> but with XFig files which reference EPS files, and TeX files which
> reference EPS files which are either pre-existing or generated from XFig,
> and about the resulting DVI files which have the same
John Weiss wrote:
On Fri, Oct 22, 2004 at 09:59:40PM +0100, Angus Leeming wrote:
The attached patch enables us to move XFig files to the temp directory
and continue to generate DVI files, etc that show any included picture
files.
Question:
Why move the files? Will LaTeX not respect
John Weiss [EMAIL PROTECTED] writes:
On Fri, Oct 22, 2004 at 09:59:40PM +0100, Angus Leeming wrote:
The attached patch enables us to move XFig files to the temp directory and
continue to generate DVI files, etc that show any included picture files.
Question:
Why move the files? Will
Am Freitag, 29. Oktober 2004 19:49 schrieb Angus Leeming:
It looks very clever. Didn't realise I'd helped write tex_copy.py.
I used lyxpreview2bitmap.py as a base, and this really helped!
I see why the $$l stuff is necessary, but... Well done anyway, for
working
it all out. You clearly have
John Weiss wrote:
> On Fri, Oct 22, 2004 at 09:59:40PM +0100, Angus Leeming wrote:
>> The attached patch enables us to move XFig files to the temp directory
>> and continue to generate DVI files, etc that show any included picture
>> files.
>
> Question:
>
> Why move the files? Will LaTeX not
John Weiss <[EMAIL PROTECTED]> writes:
>
> On Fri, Oct 22, 2004 at 09:59:40PM +0100, Angus Leeming wrote:
> > The attached patch enables us to move XFig files to the temp directory and
> > continue to generate DVI files, etc that show any included picture files.
>
> Question:
>
> Why move the
Am Freitag, 29. Oktober 2004 19:49 schrieb Angus Leeming:
> It looks very clever. Didn't realise I'd helped write tex_copy.py.
I used lyxpreview2bitmap.py as a base, and this really helped!
> I see why the $$l stuff is necessary, but... Well done anyway, for
working
> it all out. You clearly
Georg Baum wrote:
I did, and I could not break it, but I found another reason to use this
mover stuff: Bug 605 is still not completely fixed. Consider the
following situation:
master.lyx includes sub/child.lyx
sub/child.lyx includes sub/pic.fig (external material, relative file name)
Georg Baum wrote:
Here comes an updated patch. It is basically the same plus Changelogs and
documentation. Does anybody have objections?
It is really necessary to document the new external template fetaures in
Customization.lyx now. I started to do this, but it is not finished yet.
It looks
On Fri, Oct 22, 2004 at 09:59:40PM +0100, Angus Leeming wrote:
The attached patch enables us to move XFig files to the temp directory and
continue to generate DVI files, etc that show any included picture files.
Question:
Why move the files? Will LaTeX not respect symlinks?
(Moving ... as in
Georg Baum wrote:
> I did, and I could not break it, but I found another reason to use this
> mover stuff: Bug 605 is still not completely fixed. Consider the
> following situation:
>
> master.lyx includes sub/child.lyx
> sub/child.lyx includes sub/pic.fig (external material, relative file name)
Georg Baum wrote:
> Here comes an updated patch. It is basically the same plus Changelogs and
> documentation. Does anybody have objections?
>
> It is really necessary to document the new external template fetaures in
> Customization.lyx now. I started to do this, but it is not finished yet.
It
On Fri, Oct 22, 2004 at 09:59:40PM +0100, Angus Leeming wrote:
> The attached patch enables us to move XFig files to the temp directory and
> continue to generate DVI files, etc that show any included picture files.
Question:
Why move the files? Will LaTeX not respect symlinks?
(Moving ... as
Andreas Vox wrote:
If you care about overwriting files you could test for
existence of $2.
This is not necessary here. Either $2 is in a temp dir, was previously
created by the very same script and needs to be updated. Or it is not in
the temp dir, and the caller of the script checked for its
Andreas Vox wrote:
> If you care about overwriting files you could test for
> existence of $2.
This is not necessary here. Either $2 is in a temp dir, was previously
created by the very same script and needs to be updated. Or it is not in
the temp dir, and the caller of the script checked for
Alfredo Braunstein wrote:
Andreas Vox wrote:
Alfredo Braunstein [EMAIL PROTECTED] writes:
what about [ `dirname $1` -ef `dirname $2` ] ?
No idea about portability and such.
Works on MacOSX (bash).
forgot to mention, bash too ;-)
Apparently the default on MacOSX is pwd -L
Georg Baum wrote:
Am Freitag, 22. Oktober 2004 22:59 schrieb Angus Leeming:
I won't apply this until I've finished the stuff above, but it now works
as-is. Perhaps someone else would like to test it out?
I did, and I could not break it, but I found another reason to use this
mover stuff:
Alfredo Braunstein wrote:
Incidentaly, is there a more elegant (shell script) way to ascertain
whether two directories are the same than:
# If the to and the from files are in the same directory,
# then we're done.
PRESENT_DIR=`pwd`
cd `dirname $1`
FROM_DIR=`pwd`
cd `dirname $2`
Angus Leeming [EMAIL PROTECTED] writes:
what about [ `dirname $1` -ef `dirname $2` ] ?
test -e FOO is a bash extension.
Also, dirname does nothing more than strip everything after the final '/'
character. /foo/bar/../baz.cpp and /foo/baz.cpp will appear to be in
different directories.
Andreas Vox wrote:
Angus Leeming [EMAIL PROTECTED] writes:
what about [ `dirname $1` -ef `dirname $2` ] ?
test -e FOO is a bash extension.
Also, dirname does nothing more than strip everything after the final '/'
character. /foo/bar/../baz.cpp and /foo/baz.cpp will appear to be in
different
Stephan Witt wrote:
Andreas Vox wrote:
Angus Leeming [EMAIL PROTECTED] writes:
what about [ `dirname $1` -ef `dirname $2` ] ?
test -e FOO is a bash extension.
Also, dirname does nothing more than strip everything after the final
'/' character. /foo/bar/../baz.cpp and /foo/baz.cpp will
Angus Leeming [EMAIL PROTECTED] writes:
I think we're getting a little too involved with generics here, given that
this script is to be used to move .fig files into the temp directory only.
I think that the test below should do the job and should be portable.
PRESENT_DIR=$PWD
cd `dirname
Andreas Vox wrote:
I think we're getting a little too involved with generics here, given
that this script is to be used to move .fig files into the temp
directory only. I think that the test below should do the job and
should be portable.
PRESENT_DIR=$PWD
cd `dirname $1` || exit $?
Angus Leeming [EMAIL PROTECTED] writes:
Andreas Vox wrote:
Doesn't resolve symlinks on Mac
and I repeat: this script is to be used to move .fig files into the temp
directory only. The worst case is that the directories are flagged as
different and so 'sed' is used rather than 'cp'.
Andreas Vox wrote:
Doesn't resolve symlinks on Mac
and I repeat: this script is to be used to move .fig files into the
temp directory only. The worst case is that the directories are flagged
as different and so 'sed' is used rather than 'cp'. Explain to me why
that is a problem in real
Angus Leeming wrote:
Doesn't resolve symlinks on Mac
and I repeat: this script is to be used to move .fig files into the
temp directory only. The worst case is that the directories are flagged
as different and so 'sed' is used rather than 'cp'. Explain to me why
that is a problem in real
Angus Leeming [EMAIL PROTECTED] writes:
... I thought it was
about not accidently overwriting some files.
Ach! Should I test for that? Hmmm. As it stands the script will overwrite
an existing $2 if 'sed' is used and will not if 'cp' is used. I guess
I'll change that to
'cp'
Alfredo Braunstein wrote:
> Andreas Vox wrote:
>
>> Alfredo Braunstein <[EMAIL PROTECTED]> writes:
>>
>>> what about [ `dirname "$1"` -ef `dirname "$2"` ] ?
>>>
>>> No idea about portability and such.
>>
>> Works on MacOSX (bash).
>
> forgot to mention, bash too ;-)
>
>> Apparently the
Georg Baum wrote:
> Am Freitag, 22. Oktober 2004 22:59 schrieb Angus Leeming:
>> I won't apply this until I've finished the stuff above, but it now works
>> as-is. Perhaps someone else would like to test it out?
>
> I did, and I could not break it, but I found another reason to use this
> mover
Alfredo Braunstein wrote:
>> Incidentaly, is there a more elegant (shell script) way to ascertain
>> whether two directories are the same than:
>>
>> # If the "to" and the "from" files are in the same directory,
>> # then we're done.
>> PRESENT_DIR=`pwd`
>> cd `dirname "$1"`
>> FROM_DIR=`pwd`
>>
Angus Leeming <[EMAIL PROTECTED]> writes:
> > what about [ `dirname "$1"` -ef `dirname "$2"` ] ?
>
> "test -e FOO" is a bash extension.
> Also, "dirname" does nothing more than strip everything after the final '/'
> character. "/foo/bar/../baz.cpp" and "/foo/baz.cpp" will appear to be in
>
Andreas Vox wrote:
Angus Leeming <[EMAIL PROTECTED]> writes:
what about [ `dirname "$1"` -ef `dirname "$2"` ] ?
"test -e FOO" is a bash extension.
Also, "dirname" does nothing more than strip everything after the final '/'
character. "/foo/bar/../baz.cpp" and "/foo/baz.cpp" will appear to be in
Stephan Witt wrote:
> Andreas Vox wrote:
>> Angus Leeming <[EMAIL PROTECTED]> writes:
>>
>>
what about [ `dirname "$1"` -ef `dirname "$2"` ] ?
>>>
>>>"test -e FOO" is a bash extension.
>>>Also, "dirname" does nothing more than strip everything after the final
>>>'/' character.
Angus Leeming <[EMAIL PROTECTED]> writes:
< I think we're getting a little too involved with generics here, given that
< this script is to be used to move .fig files into the temp directory only.
< I think that the test below should do the job and should be portable.
<
< PRESENT_DIR=$PWD
<
< cd
Andreas Vox wrote:
> < I think we're getting a little too involved with generics here, given
> that < this script is to be used to move .fig files into the temp
> directory only. < I think that the test below should do the job and
> should be portable. <
> < PRESENT_DIR=$PWD
> <
> < cd `dirname
Angus Leeming <[EMAIL PROTECTED]> writes:
< Andreas Vox wrote:
< > Doesn't resolve symlinks on Mac
<
< and I repeat: this script is to be used to move .fig files into the temp
< directory only. The worst case is that the directories are flagged as
< different and so 'sed' is used rather than
Andreas Vox wrote:
> < > Doesn't resolve symlinks on Mac
> <
> < and I repeat: this script is to be used to move .fig files into the
> temp directory only. The worst case is that the directories are flagged
> as different and so 'sed' is used rather than 'cp'. Explain to me why
> that is a problem
Angus Leeming wrote:
>> < > Doesn't resolve symlinks on Mac
>> <
>> < and I repeat: this script is to be used to move .fig files into the
>> temp directory only. The worst case is that the directories are flagged
>> as different and so 'sed' is used rather than 'cp'. Explain to me why
>> that is a
Angus Leeming <[EMAIL PROTECTED]> writes:
> >> ... I thought it was
> >> about not accidently overwriting some files.
> >
> > Ach! Should I test for that? Hmmm. As it stands the script will overwrite
> > an existing "$2" if 'sed' is used and will not if 'cp' is used. I guess
> > I'll change that
Am Freitag, 22. Oktober 2004 22:59 schrieb Angus Leeming:
I won't apply this until I've finished the stuff above, but it now works
as-is. Perhaps someone else would like to test it out?
I did, and I could not break it, but I found another reason to use this
mover stuff: Bug 605 is still not
Am Freitag, 22. Oktober 2004 22:59 schrieb Angus Leeming:
> I won't apply this until I've finished the stuff above, but it now works
> as-is. Perhaps someone else would like to test it out?
I did, and I could not break it, but I found another reason to use this
mover stuff: Bug 605 is still not
Andreas Vox wrote:
Alfredo Braunstein [EMAIL PROTECTED] writes:
what about [ `dirname $1` -ef `dirname $2` ] ?
No idea about portability and such.
Works on MacOSX (bash).
forgot to mention, bash too ;-)
Apparently the default on MacOSX is pwd -L rather than pwd -P as
stated in the
Andreas Vox wrote:
> Alfredo Braunstein <[EMAIL PROTECTED]> writes:
>
>> what about [ `dirname "$1"` -ef `dirname "$2"` ] ?
>>
>> No idea about portability and such.
>
> Works on MacOSX (bash).
forgot to mention, bash too ;-)
> Apparently the default on MacOSX is "pwd -L" rather than "pwd
The attached patch enables us to move XFig files to the temp directory and
continue to generate DVI files, etc that show any included picture files.
The next step is to add an ability to iterate over the specialized copier
functions and ascertain which ones have been added and which ones have
Angus Leeming wrote:
The attached patch enables us to move XFig files to the temp directory and
continue to generate DVI files, etc that show any included picture files.
The next step is to add an ability to iterate over the specialized copier
functions and ascertain which ones have been
Alfredo Braunstein [EMAIL PROTECTED] writes:
what about [ `dirname $1` -ef `dirname $2` ] ?
No idea about portability and such.
Works on MacOSX (bash).
Apparently the default on MacOSX is pwd -L rather than pwd -P as
stated in the manpage, so the original script would not work on Mac.
The attached patch enables us to move XFig files to the temp directory and
continue to generate DVI files, etc that show any included picture files.
The next step is to add an ability to iterate over the specialized copier
functions and ascertain which ones have been added and which ones have
Angus Leeming wrote:
> The attached patch enables us to move XFig files to the temp directory and
> continue to generate DVI files, etc that show any included picture files.
>
> The next step is to add an ability to iterate over the specialized copier
> functions and ascertain which ones have
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
> what about [ `dirname "$1"` -ef `dirname "$2"` ] ?
>
> No idea about portability and such.
Works on MacOSX (bash).
Apparently the default on MacOSX is "pwd -L" rather than "pwd -P" as
stated in the manpage, so the original script would not
64 matches
Mail list logo
