Angus Leeming [EMAIL PROTECTED] writes:
Luis Rivera wrote:
Got it. However, I can't find which converters need to be tuned up
to fix LyX's misbehavior.
There's a page on the wiki that explains enough to get you started:
Thanks a lot!!!
Now I think we can close this thread...
Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Luis Rivera wrote:
> > Got it. However, I can't find which converters need to be tuned up
> > to fix LyX's misbehavior.
>
> There's a page on the wiki that explains enough to get you started:
>
Thanks a lot!!!
Now I think we can close this
Luis Rivera wrote:
The real solution would be to tell LyX about different path
styles in the converters:
native, Cygwin paths: convert $$i $$o
Win32 paths: convert $$win32i $$win32o
All I meant was, rather than have a single global value (to
win32path or to not win32path),
Luis Rivera wrote:
>> >> The "real" solution would be to tell LyX about different path
>> >> styles in the converters:
>> >> native, Cygwin paths: convert $$i $$o
>> >> Win32 paths: convert $$win32i $$win32o
>> All I meant was, rather than have a single global value (to
>> win32path or to
Angus Leeming [EMAIL PROTECTED] writes:
Luis Rivera wrote:
I wonder whether this code only handles (and thus, fixes) the paths for
the applications, not the target input/output files.
All file names should be transformed using external_path.
OK.
No need to quote them?
Cheers,
Angus Leeming [EMAIL PROTECTED] writes:
The real solution would be to tell LyX about different path styles in
the converters:
native, Cygwin paths: convert $$i $$o
Win32 paths: convert $$win32i $$win32o
All I meant was, rather than have a single global value (to win32path or
Luis Rivera wrote:
All file names should be transformed using external_path.
OK.
No need to quote them?
At the moment, yes. (Hence our problems with files with spaces.)
Eventually, I'd hope we wouldn't have to quote them because we'd store
the arguments in an array and pass this array to the
Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Luis Rivera wrote:
> > I wonder whether this code only handles (and thus, fixes) the paths for
> > the applications, not the target input/output files.
>
> All file names should be transformed using "external_path".
>
OK.
No need to quote them?
Angus Leeming <[EMAIL PROTECTED]> writes:
>
> >> The "real" solution would be to tell LyX about different path styles in
> >> the converters:
> >> native, Cygwin paths: convert $$i $$o
> >> Win32 paths: convert $$win32i $$win32o
>
> All I meant was, rather than have a single global value
Luis Rivera wrote:
>> All file names should be transformed using "external_path".
> OK.
> No need to quote them?
At the moment, yes. (Hence our problems with "files with spaces".)
Eventually, I'd hope we wouldn't have to quote them because we'd store
the arguments in an array and pass this array
Luis Rivera [EMAIL PROTECTED] writes:
Hello,
I compiled and use LyX --with-frontend=xforms succesfully on cygwin
(version 1.5.18-1, with gcc 3.4.4-1).
However, --with-frontend=qt, I can can compile LyX succesfully, but it
doesn't display any characters: just plain white squares.
COOL
So you are saying that I can just go to gcc-3.4.4 and the Cygwin supplied QT
and it will just work??!!
Great!!
---Kayvan
On Wed, Oct 19, 2005 at 04:14:24PM +, Luis Rivera wrote:
Luis Rivera [EMAIL PROTECTED] writes:
Hello,
I compiled and use
In [EMAIL PROTECTED], Luis Rivera [EMAIL PROTECTED] typed:
In short, this port of LyX-Qt on Cygwin-X requires the Cygwin native python
interpreter, ImageMagick, ghostscript, and the jpeg and qt3 packages, plus the
Xserver scalable fonts. Apparently, LyX-Qt on Cygwin-X does posix style
Mike Meyer wrote:
In [EMAIL PROTECTED],
Luis Rivera [EMAIL PROTECTED] typed:
In short, this port of LyX-Qt on Cygwin-X requires the Cygwin native
python interpreter, ImageMagick, ghostscript, and the jpeg and qt3
packages, plus the
Xserver scalable fonts. Apparently, LyX-Qt on Cygwin-X
Angus Leeming [EMAIL PROTECTED] writes:
Mike Meyer wrote:
In [EMAIL PROTECTED],
Luis Rivera [EMAIL PROTECTED] typed:
In short, this port of LyX-Qt on Cygwin-X requires the Cygwin native
python interpreter, ImageMagick, ghostscript, and the jpeg and qt3
packages, plus the
Xserver
Luis Rivera wrote:
Angus Leeming [EMAIL PROTECTED] writes:
Mike Meyer wrote:
In [EMAIL PROTECTED],
Luis Rivera [EMAIL PROTECTED] typed:
In short, this port of LyX-Qt on Cygwin-X requires the Cygwin native
python interpreter, ImageMagick, ghostscript, and the jpeg and qt3
Angus Leeming [EMAIL PROTECTED] writes:
Basically, the current code is a bit of a kludge.
The kludge is the cygwin_path_fix_ which is settable from the
Edit-Preferences dialog IIRC and can certainly be set manually in your
preferences file as:
\cygwin_path_fix_needed true
Tried it,
Angus Leeming [EMAIL PROTECTED] writes:
Luis Rivera wrote:
Indeed, I tried both (in reverse order, btw, since I thought instructions
for lusers should go from inside out the application), and as I said, it
seems that LyX sticks to posix-style path searches, not for the
applications
Luis Rivera wrote:
\cygwin_path_fix_needed true
Tried it, and now the error message is
22 [main] lyx 440 fork_parent: child 1276 died waiting for longjmp before
initialization.
Could not fork: No such file or directory
Presumably because some unix shell script (convertDefault.sh ?) is
Luis Rivera wrote:
Basically, the current code is a bit of a kludge. Here it is (from
src/support/os_cygwin.C):
I wonder whether this code only handles (and thus, fixes) the paths for
the applications, not the target input/output files.
Just shooting from the hip...
All file names should
Luis Rivera <[EMAIL PROTECTED]> writes:
>
> Hello,
>
> I compiled and use LyX --with-frontend=xforms succesfully on cygwin
> (version 1.5.18-1, with gcc 3.4.4-1).
>
> However, --with-frontend=qt, I can can compile LyX succesfully, but it
> doesn't display any characters: just plain white
COOL
So you are saying that I can just go to gcc-3.4.4 and the Cygwin supplied QT
and it will just work??!!
Great!!
---Kayvan
On Wed, Oct 19, 2005 at 04:14:24PM +, Luis Rivera wrote:
> Luis Rivera <[EMAIL PROTECTED]> writes:
>
> >
> > Hello,
> >
> > I
In <[EMAIL PROTECTED]>, Luis Rivera <[EMAIL PROTECTED]> typed:
> In short, this port of LyX-Qt on Cygwin-X requires the Cygwin native python
> interpreter, ImageMagick, ghostscript, and the jpeg and qt3 packages, plus the
> Xserver scalable fonts. Apparently, LyX-Qt on Cygwin-X does posix style
>
Mike Meyer wrote:
> In <[EMAIL PROTECTED]>,
> Luis Rivera <[EMAIL PROTECTED]> typed:
>> In short, this port of LyX-Qt on Cygwin-X requires the Cygwin native
>> python interpreter, ImageMagick, ghostscript, and the jpeg and qt3
>> packages, plus the
>> Xserver scalable fonts. Apparently, LyX-Qt
Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Mike Meyer wrote:
>
> > In <[EMAIL PROTECTED]>,
> > Luis Rivera <[EMAIL PROTECTED]> typed:
> >> In short, this port of LyX-Qt on Cygwin-X requires the Cygwin native
> >> python interpreter, ImageMagick, ghostscript, and the jpeg and qt3
> >>
Luis Rivera wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
>>
>> Mike Meyer wrote:
>>
>> > In <[EMAIL PROTECTED]>,
>> > Luis Rivera <[EMAIL PROTECTED]> typed:
>> >> In short, this port of LyX-Qt on Cygwin-X requires the Cygwin native
>> >> python interpreter, ImageMagick, ghostscript,
Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Basically, the current code is a bit of a kludge.
> The kludge is the "cygwin_path_fix_" which is settable from the
> Edit->Preferences dialog IIRC and can certainly be set manually in your
> preferences file as:
>
> \cygwin_path_fix_needed true
>
Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Luis Rivera wrote:
>
> > Indeed, I tried both (in reverse order, btw, since I thought instructions
> > for lusers should go from inside out the application), and as I said, it
> > seems that LyX sticks to posix-style path searches, not for the
> >
Luis Rivera wrote:
>> \cygwin_path_fix_needed true
> Tried it, and now the error message is
> 22 [main] lyx 440 fork_parent: child 1276 died waiting for longjmp before
> initialization.
> Could not fork: No such file or directory
Presumably because some unix shell script (convertDefault.sh ?) is
Luis Rivera wrote:
>> Basically, the current code is a bit of a kludge. Here it is (from
>> src/support/os_cygwin.C):
> I wonder whether this code only handles (and thus, fixes) the paths for
> the applications, not the target input/output files.
> Just shooting from the hip...
All file names
Hello,
I compiled and use LyX --with-frontend=xforms succesfully on cygwin
(version 1.5.18-1, with gcc 3.4.4-1).
However, --with-frontend=qt, I can can compile LyX succesfully, but it
doesn't display any characters: just plain white squares.
Perhaps there is nothing wrong with LyX, and the
Hello,
I compiled and use LyX --with-frontend=xforms succesfully on cygwin
(version 1.5.18-1, with gcc 3.4.4-1).
However, --with-frontend=qt, I can can compile LyX succesfully, but it
doesn't display any characters: just plain white squares.
Perhaps there is nothing wrong with LyX, and the
32 matches
Mail list logo
