Also the most salient point of those previews (at least that has
turned out to be for preview-latex) is to integrate the look of the
final output into the source, so as to render things more readable.
Since the elements themselves are lacking fine structure, for editing
you need the
On Thu, Jun 27, 2002 at 12:26:17PM +0300, Dekel Tsur wrote:
The math editor already gives a good approximation on hour your formulae
will look, so the need for a preview is much less needed than in emacs.
In fact, in my opinion, the change in display that is performed when
opening a formula
Andre Poenitz [EMAIL PROTECTED] writes:
On Thu, Jun 27, 2002 at 12:26:17PM +0300, Dekel Tsur wrote:
The math editor already gives a good approximation on hour your
formulae will look, so the need for a preview is much less needed
than in emacs. In fact, in my opinion, the change in
On Thu, Jun 27, 2002 at 12:26:17PM +0300, Dekel Tsur wrote:
The math editor already gives a good approximation on hour your formulae
will look, so the need for a preview is much less needed than in emacs.
In fact, in my opinion, the change in display that is performed when
opening a formula
On Thu, Jun 27, 2002 at 10:57:18AM +0100, Jules Bean wrote:
On Thu, Jun 27, 2002 at 12:26:17PM +0300, Dekel Tsur wrote:
The math editor already gives a good approximation on hour your formulae
will look, so the need for a preview is much less needed than in emacs.
In fact, in my
On Thu, Jun 27, 2002 at 01:36:50PM +0300, Dekel Tsur wrote:
I hope we will support 99% of math constructs some day.
But then there is always stuff defined in local .sty files...
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve,
?
At the moment, primarily prooftrees and 'mathlig' (a package which I
wrote to allow me to use shorthands like |- for the \vdash symbol).
In the past it was commutative diagrams (which I typset in xypic).
Almost every single chunk of math in my work uses features LyX doesn't
suport ;) Preview Lyx
On Thu, Jun 27, 2002 at 12:40:36PM +0200, Andre Poenitz wrote:
On Thu, Jun 27, 2002 at 01:36:50PM +0300, Dekel Tsur wrote:
I hope we will support 99% of math constructs some day.
But then there is always stuff defined in local .sty files...
LyX should support defining macros in a different
On Thu, Jun 27, 2002 at 01:54:59PM +0300, Dekel Tsur wrote:
But then there is always stuff defined in local .sty files...
LyX should support defining macros in a different .lyx files.
I know.
But even that's not the solution. Either lyx understands all TeX primitives
or we would need the
On Thu, Jun 27, 2002 at 12:59:27PM +0200, Andre Poenitz wrote:
On Thu, Jun 27, 2002 at 01:54:59PM +0300, Dekel Tsur wrote:
But then there is always stuff defined in local .sty files...
LyX should support defining macros in a different .lyx files.
I know.
But even that's not the
>
> Also the most salient point of those previews (at least that has
> turned out to be for preview-latex) is to integrate the look of the
> final output into the source, so as to render things more readable.
> Since the elements themselves are lacking fine structure, for editing
> you need the
On Thu, Jun 27, 2002 at 12:26:17PM +0300, Dekel Tsur wrote:
> The math editor already gives a good approximation on hour your formulae
> will look, so the need for a preview is much less needed than in emacs.
> In fact, in my opinion, the change in display that is performed when
> opening a
Andre Poenitz <[EMAIL PROTECTED]> writes:
> On Thu, Jun 27, 2002 at 12:26:17PM +0300, Dekel Tsur wrote:
> > The math editor already gives a good approximation on hour your
> > formulae will look, so the need for a preview is much less needed
> > than in emacs. In fact, in my opinion, the change
On Thu, Jun 27, 2002 at 12:26:17PM +0300, Dekel Tsur wrote:
>
> The math editor already gives a good approximation on hour your formulae
> will look, so the need for a preview is much less needed than in emacs.
> In fact, in my opinion, the change in display that is performed when
> opening a
On Thu, Jun 27, 2002 at 10:57:18AM +0100, Jules Bean wrote:
> On Thu, Jun 27, 2002 at 12:26:17PM +0300, Dekel Tsur wrote:
> >
> > The math editor already gives a good approximation on hour your formulae
> > will look, so the need for a preview is much less needed than in emacs.
> > In fact, in
On Thu, Jun 27, 2002 at 01:36:50PM +0300, Dekel Tsur wrote:
> I hope we will support 99% of math constructs some day.
But then there is always stuff defined in local .sty files...
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve,
ike |- for the \vdash symbol).
In the past it was commutative diagrams (which I typset in xypic).
Almost every single chunk of math in my work uses features LyX doesn't
suport ;) Preview Lyx would allow me to at least see pretty renderings
of the ERT LyX doesn't like.
Jules
On Thu, Jun 27, 2002 at 12:40:36PM +0200, Andre Poenitz wrote:
> On Thu, Jun 27, 2002 at 01:36:50PM +0300, Dekel Tsur wrote:
> > I hope we will support 99% of math constructs some day.
>
> But then there is always stuff defined in local .sty files...
LyX should support defining macros in a
On Thu, Jun 27, 2002 at 01:54:59PM +0300, Dekel Tsur wrote:
> > But then there is always stuff defined in local .sty files...
>
> LyX should support defining macros in a different .lyx files.
I know.
But even that's not the solution. Either lyx understands all TeX primitives
or we would need
On Thu, Jun 27, 2002 at 12:59:27PM +0200, Andre Poenitz wrote:
> On Thu, Jun 27, 2002 at 01:54:59PM +0300, Dekel Tsur wrote:
> > > But then there is always stuff defined in local .sty files...
> >
> > LyX should support defining macros in a different .lyx files.
>
> I know.
>
> But even
André, how does it work for you???
I get stacks of these messages because /tmp/lyx does not exist.
Angus
aleem@pneumon:src- writing '$D'$' to '/tmp/lyx/EcEeHcEc.eps'
/tmp/lyx/: No such file or directory
file '/tmp/lyx/EcEeHcEc.eps' registered
writing '$D'$' to '/tmp/lyx/EcEeHcEc.eps'
file
On Wednesday 26 June 2002 3:18 pm, David Kastrup wrote:
Angus Leeming [EMAIL PROTECTED] writes:
André, how does it work for you???
I get stacks of these messages because /tmp/lyx does not exist.
aleem@pneumon:src- writing '$D'$' to '/tmp/lyx/EcEeHcEc.eps'
/tmp/lyx/: No such file or
Angus Leeming [EMAIL PROTECTED] writes:
On Wednesday 26 June 2002 3:18 pm, David Kastrup wrote:
Angus Leeming [EMAIL PROTECTED] writes:
André, how does it work for you???
I get stacks of these messages because /tmp/lyx does not exist.
aleem@pneumon:src- writing '$D'$' to
André, how does it work for you???
I get stacks of these messages because /tmp/lyx does not exist.
Angus
aleem@pneumon:src-> writing '$D'$' to '/tmp/lyx/EcEeHcEc.eps'
/tmp/lyx/: No such file or directory
file '/tmp/lyx/EcEeHcEc.eps' registered
writing '$D'$' to '/tmp/lyx/EcEeHcEc.eps'
file
On Wednesday 26 June 2002 3:18 pm, David Kastrup wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> > André, how does it work for you???
> >
> > I get stacks of these messages because /tmp/lyx does not exist.
> >
> > aleem@pneumon:src-> writing '$D'$' to '/tmp/lyx/EcEeHcEc.eps'
> > /tmp/lyx/:
Angus Leeming <[EMAIL PROTECTED]> writes:
> On Wednesday 26 June 2002 3:18 pm, David Kastrup wrote:
> > Angus Leeming <[EMAIL PROTECTED]> writes:
> > > André, how does it work for you???
> > >
> > > I get stacks of these messages because /tmp/lyx does not exist.
> > >
> > > aleem@pneumon:src->
Proof of concept see attached gif.
It is actually not as slow as I expected. In its current (really stupid)
implementation its less than a second for the preview to come up (on my
admittedly fairly recent machine_.
But it eats quite a bit of memory currently and does not clean up properly.
A
On Tue, Jun 25, 2002 at 09:05:29PM +0200, Andre Poenitz wrote:
Proof of concept see attached gif.
It is actually not as slow as I expected. In its current (really stupid)
implementation its less than a second for the preview to come up (on my
admittedly fairly recent machine_.
I'm sure a
On Tue, Jun 25, 2002 at 09:05:29PM +0200, Andre Poenitz wrote:
Proof of concept see attached gif.
It is actually not as slow as I expected. In its current (really stupid)
implementation its less than a second for the preview to come up (on my
admittedly fairly recent machine_.
But it
Proof of concept see attached gif.
It is actually not as slow as I expected. In its current (really stupid)
implementation its less than a second for the preview to come up (on my
admittedly fairly recent machine_.
But it eats quite a bit of memory currently and does not clean up properly.
A
On Tue, Jun 25, 2002 at 09:05:29PM +0200, Andre Poenitz wrote:
>
> Proof of concept see attached gif.
>
> It is actually not as slow as I expected. In its current (really stupid)
> implementation its less than a second for the preview to come up (on my
> admittedly fairly recent machine_.
I'm
On Tue, Jun 25, 2002 at 09:05:29PM +0200, Andre Poenitz wrote:
>
> Proof of concept see attached gif.
>
> It is actually not as slow as I expected. In its current (really stupid)
> implementation its less than a second for the preview to come up (on my
> admittedly fairly recent machine_.
>
>
will be a big starting
help for some users. What other features would you find worth having
pointed out (apart from preview-LyX, in case it gets into a
demonstratable state by conference time, or at least into a stage
where one can be reasonably sure that its implementation will get
followed
(key bindings, mouseclicks, drawing).
> I am digressing. Obviously, the math editor will be a big starting
> help for some users. What other features would you find worth having
> pointed out (apart from preview-LyX, in case it gets into a
> demonstratable state by conference time, o
. Obviously, the math editor will be a big starting
help for some users. What other features would you find worth having
pointed out (apart from preview-LyX, in case it gets into a
demonstratable state by conference time, or at least into a stage
where one can be reasonably sure that its implementation
Herbert Voss [EMAIL PROTECTED] writes:
David Kastrup wrote:
I am digressing. Obviously, the math editor will be a big starting
help for some users. What other features would you find worth having
pointed out (apart from preview-LyX, in case it gets into a
demonstratable state
David Kastrup wrote:
I am digressing. Obviously, the math editor will be a big starting
help for some users. What other features would you find worth having
pointed out (apart from preview-LyX, in case it gets into a
demonstratable state by conference time, or at least into a stage
where
. Obviously, the math editor will be a big starting
help for some users. What other features would you find worth having
pointed out (apart from preview-LyX, in case it gets into a
demonstratable state by conference time, or at least into a stage
where one can be reasonably sure that its implementation
Herbert Voss <[EMAIL PROTECTED]> writes:
> David Kastrup wrote:
>
> > I am digressing. Obviously, the math editor will be a big starting
> > help for some users. What other features would you find worth having
> > pointed out (apart from preview-LyX, in case it
David Kastrup wrote:
> I am digressing. Obviously, the math editor will be a big starting
> help for some users. What other features would you find worth having
> pointed out (apart from preview-LyX, in case it gets into a
> demonstratable state by conference time, or at least
On Tue, May 14, 2002 at 03:12:27PM +0100, Angus Leeming wrote:
Well LyX is getting better at graphics. It can display almost any graphics
file you throw at it, either by loading the file direct or by converting it
to a loadable format and loading that temp file. All graphics loading and
On Wednesday 15 May 2002 8:01 am, Andre Poenitz wrote:
What would be the format that (a) can be produced by gs, (b) displayed
natively by LyX and (c) is the fastest?
Comparing the available gs devices to this list of formats that can be loaded
natively by LyX, these formats could be used:
Angus Leeming [EMAIL PROTECTED] writes:
On Wednesday 15 May 2002 8:01 am, Andre Poenitz wrote:
What would be the format that (a) can be produced by gs, (b) displayed
natively by LyX and (c) is the fastest?
Comparing the available gs devices to this list of formats that can be loaded
Angus Leeming [EMAIL PROTECTED] writes:
On Wednesday 15 May 2002 8:01 am, Andre Poenitz wrote:
What would be the format that (a) can be produced by gs, (b) displayed
natively by LyX and (c) is the fastest?
Comparing the available gs devices to this list of formats that can be loaded
On Wednesday 15 May 2002 11:05 am, David Kastrup wrote:
Angus Leeming [EMAIL PROTECTED] writes:
But if you ask me: better to support PNG natively soon. After all, it
is _the_ standard free format for lossless compression of graphical
images.
Keep bugging us once 1.2 is out the door. I'll
Garst R. Reese [EMAIL PROTECTED] writes:
Well, jpeg lets you choose how lossy it is, tif files tend to get huge,
pnm I have not used that much. The following are all the same figure.
-rw-r--r--1 garstusers2043 May 10 2000 pei.gif
-rw-r--r--1 garstusers2640
On Wed, May 15, 2002 at 09:01:38AM +0200, Andre Poenitz wrote:
What would be the format that (a) can be produced by gs, (b) displayed
natively by LyX and (c) is the fastest?
Undoubtedly the fastest method is to use the X rendering we used to for
figinset, since there is no intermediate file,
On Wed, May 15, 2002 at 12:05:00PM +0200, David Kastrup wrote:
least pnm will encode monochromatic images with 8 bits per pixel
instead of 24 (and if you don't use antialiasing, pure BW text will
render with 1 bit per pixel, while looking ugly).
Actually David I have a question about how
What would be the format that (a) can be produced by gs, (b) displayed
natively by LyX and (c) is the fastest?
JL Undoubtedly the fastest method is to use the X rendering we used to for
JL figinset, since there is no intermediate file, and probably no need to
JL spawn another gs process.
On Wed, May 15, 2002 at 04:04:53PM +0200, Philipp Reichmuth wrote:
JL Undoubtedly the fastest method is to use the X rendering we used to for
JL figinset, since there is no intermediate file, and probably no need to
JL spawn another gs process.
Wouldn't that break GUI independence with
On Wednesday 15 May 2002 2:44 pm, John Levon wrote:
On Wed, May 15, 2002 at 09:01:38AM +0200, Andre Poenitz wrote:
What would be the format that (a) can be produced by gs, (b) displayed
natively by LyX and (c) is the fastest?
Undoubtedly the fastest method is to use the X rendering we used
On Wed, May 15, 2002 at 03:16:07PM +0100, Angus Leeming wrote:
John, I don't think that David is subscribed to the list yet, so he won't be
getting these insights.
Yeah I forgot, but bounced them after posting
john
--
So what you're saying is screw the disabled and you want us to do the
John Levon [EMAIL PROTECTED] writes:
On Wed, May 15, 2002 at 12:05:00PM +0200, David Kastrup wrote:
least pnm will encode monochromatic images with 8 bits per pixel
instead of 24 (and if you don't use antialiasing, pure BW text will
render with 1 bit per pixel, while looking ugly).
On Wed, May 15, 2002 at 02:47:40PM +0100, John Levon wrote:
Is it simple to detect cases like and automatically just show the TeX
code, or would it be up to the user to turn off preview for these insets
?
I'd guess we (i.e. LyX) have to specify which things can be rendered and
which not. Sort
On Wed, May 15, 2002 at 04:04:53PM +0200, Philipp Reichmuth wrote:
Wouldn't that break GUI independence with non-X platforms? If I
remember correctly, there has been a substantial number of users
expressing interest in Qt-Win32, native Windows or BeOS GUIs which
would be quite incompatible
John Levon [EMAIL PROTECTED] writes:
On Wed, May 15, 2002 at 09:01:38AM +0200, Andre Poenitz wrote:
What would be the format that (a) can be produced by gs, (b)
displayed natively by LyX and (c) is the fastest?
Undoubtedly the fastest method is to use the X rendering we used to
for
On Tue, May 14, 2002 at 03:12:27PM +0100, Angus Leeming wrote:
> Well LyX is getting better at graphics. It can display almost any graphics
> file you throw at it, either by loading the file direct or by converting it
> to a loadable format and loading that temp file. All graphics loading and
On Wednesday 15 May 2002 8:01 am, Andre Poenitz wrote:
> What would be the format that (a) can be produced by gs, (b) displayed
> "natively" by LyX and (c) is the "fastest"?
Comparing the available gs devices to this list of formats that can be loaded
natively by LyX, these formats could be
Angus Leeming <[EMAIL PROTECTED]> writes:
> On Wednesday 15 May 2002 8:01 am, Andre Poenitz wrote:
> > What would be the format that (a) can be produced by gs, (b) displayed
> > "natively" by LyX and (c) is the "fastest"?
>
> Comparing the available gs devices to this list of formats that can
Angus Leeming <[EMAIL PROTECTED]> writes:
> On Wednesday 15 May 2002 8:01 am, Andre Poenitz wrote:
> > What would be the format that (a) can be produced by gs, (b) displayed
> > "natively" by LyX and (c) is the "fastest"?
>
> Comparing the available gs devices to this list of formats that can
On Wednesday 15 May 2002 11:05 am, David Kastrup wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> But if you ask me: better to support PNG natively soon. After all, it
> is _the_ standard free format for lossless compression of graphical
> images.
Keep bugging us once 1.2 is out the door.
"Garst R. Reese" <[EMAIL PROTECTED]> writes:
> Well, jpeg lets you choose how lossy it is, tif files tend to get huge,
> pnm I have not used that much. The following are all the same figure.
> -rw-r--r--1 garstusers2043 May 10 2000 pei.gif
> -rw-r--r--1 garstusers
On Wed, May 15, 2002 at 09:01:38AM +0200, Andre Poenitz wrote:
> What would be the format that (a) can be produced by gs, (b) displayed
> "natively" by LyX and (c) is the "fastest"?
Undoubtedly the fastest method is to use the X rendering we used to for
figinset, since there is no intermediate
On Wed, May 15, 2002 at 12:05:00PM +0200, David Kastrup wrote:
> least pnm will encode monochromatic images with 8 bits per pixel
> instead of 24 (and if you don't use antialiasing, pure B text will
> render with 1 bit per pixel, while looking ugly).
Actually David I have a question about how
>> What would be the format that (a) can be produced by gs, (b) displayed
>> "natively" by LyX and (c) is the "fastest"?
JL> Undoubtedly the fastest method is to use the X rendering we used to for
JL> figinset, since there is no intermediate file, and probably no need to
JL> spawn another gs
On Wed, May 15, 2002 at 04:04:53PM +0200, Philipp Reichmuth wrote:
> JL> Undoubtedly the fastest method is to use the X rendering we used to for
> JL> figinset, since there is no intermediate file, and probably no need to
> JL> spawn another gs process.
>
> Wouldn't that break GUI independence
On Wednesday 15 May 2002 2:44 pm, John Levon wrote:
> On Wed, May 15, 2002 at 09:01:38AM +0200, Andre Poenitz wrote:
> > What would be the format that (a) can be produced by gs, (b) displayed
> > "natively" by LyX and (c) is the "fastest"?
>
> Undoubtedly the fastest method is to use the X
On Wed, May 15, 2002 at 03:16:07PM +0100, Angus Leeming wrote:
> John, I don't think that David is subscribed to the list yet, so he won't be
> getting these insights.
Yeah I forgot, but bounced them after posting
john
--
"So what you're saying is "screw the disabled" and you want us to do
John Levon <[EMAIL PROTECTED]> writes:
> On Wed, May 15, 2002 at 12:05:00PM +0200, David Kastrup wrote:
>
> > least pnm will encode monochromatic images with 8 bits per pixel
> > instead of 24 (and if you don't use antialiasing, pure B text will
> > render with 1 bit per pixel, while looking
On Wed, May 15, 2002 at 02:47:40PM +0100, John Levon wrote:
> Is it simple to detect cases like and automatically just show the TeX
> code, or would it be up to the user to turn off preview for these insets
> ?
I'd guess we (i.e. LyX) have to specify which "things" can be rendered and
which not.
On Wed, May 15, 2002 at 04:04:53PM +0200, Philipp Reichmuth wrote:
> Wouldn't that break GUI independence with non-X platforms? If I
> remember correctly, there has been a substantial number of users
> expressing interest in Qt-Win32, native Windows or BeOS GUIs which
> would be quite
John Levon <[EMAIL PROTECTED]> writes:
> On Wed, May 15, 2002 at 09:01:38AM +0200, Andre Poenitz wrote:
>
> > What would be the format that (a) can be produced by gs, (b)
> > displayed "natively" by LyX and (c) is the "fastest"?
>
> Undoubtedly the fastest method is to use the X rendering we
On 12 May 2002, David Kastrup wrote:
Several of you probably are already aware of the preview-latex project
where I am head developer. I delivered a talk about it at the recent
I propose that you stay around a bit, and when 1.3.0 opens, we
can look into this. Right now, LyX is in feature
On Tuesday 14 May 2002 9:47 am, Asger K. Alstrup Nielsen wrote:
On 12 May 2002, David Kastrup wrote:
Several of you probably are already aware of the preview-latex project
where I am head developer. I delivered a talk about it at the recent
I propose that you stay around a bit, and when
be
done in C++ for preview-LyX. Since Emacs provides a usable (though
idiosyncratic) rapid prototyping extension language and a powerful
display engine, and I am used to it, I will certainly try to keep the
Emacs connection up to par with developments in that area. But the
ultimate goal will probably
On Sun, May 12, 2002 at 04:59:09PM +0200, David Kastrup wrote:
[...] In contrast, I believe LyX to have the necessary infrastructure for
that kind of functionality.
At least partially... I believe so, too.
[...] Even in those areas where LyX _does_ know its things
(like in math formulas),
that
is reasonable to ensure this will be as painless as it gets for me and
prospective customers.
And don't you believe I am not perfectly capable of stealing any good
code that you may develop in the course of implementing some
preview-LyX functionality. Just tying together the work of others is
one
believe I am not perfectly capable of stealing any good
code that you may develop in the course of implementing some preview-LyX
functionality.
Good code?
From us?
;^)
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T
On Tuesday 14 May 2002 12:47 pm, Andre Poenitz wrote:
We don't have proper multithreading, but some of the graphics stuff is
(was?) rendered asynchronously already.
We have a forkedcalls class that executes a fork-ed process and emits a
signal when that process finishes. I think that it'd be
Angus Leeming [EMAIL PROTECTED] writes:
On Tuesday 14 May 2002 12:47 pm, Andre Poenitz wrote:
We don't have proper multithreading, but some of the graphics stuff is
(was?) rendered asynchronously already.
We have a forkedcalls class that executes a fork-ed process and emits a
signal
Andre Poenitz [EMAIL PROTECTED] writes:
At the current point of time, preview-latex is defensive in
resource usage; you need an explicit request to let it start the
background machinations. Part of the reason is that there are
associated fixed costs with starting up LaTeX, DviPS and
On Tuesday 14 May 2002 1:47 pm, David Kastrup wrote:
Angus Leeming [EMAIL PROTECTED] writes:
On Tuesday 14 May 2002 12:47 pm, Andre Poenitz wrote:
We don't have proper multithreading, but some of the graphics stuff is
(was?) rendered asynchronously already.
We have a forkedcalls
Angus Leeming [EMAIL PROTECTED] writes:
On Tuesday 14 May 2002 1:47 pm, David Kastrup wrote:
Angus Leeming [EMAIL PROTECTED] writes:
On Tuesday 14 May 2002 12:47 pm, Andre Poenitz wrote:
We don't have proper multithreading, but some of the graphics stuff is
(was?) rendered
On Tuesday 14 May 2002 2:20 pm, David Kastrup wrote:
Angus Leeming [EMAIL PROTECTED] writes:
On Tuesday 14 May 2002 1:47 pm, David Kastrup wrote:
Angus Leeming [EMAIL PROTECTED] writes:
On Tuesday 14 May 2002 12:47 pm, Andre Poenitz wrote:
We don't have proper multithreading, but
They waited 18 months for 1.2. They're going to like what they see which
should give us some time before thay start screaming for more ;-)
Angus
As a token userMORE!
Thought I'd try to be the first...
Regards (and many thanks)
Rod
Angus Leeming [EMAIL PROTECTED] writes:
Well LyX is getting better at graphics. It can display almost any
graphics file you throw at it, either by loading the file direct or
by converting it to a loadable format and loading that temp
file. All graphics loading and rendering is asynchronous,
On 12 May 2002, David Kastrup wrote:
> Several of you probably are already aware of the preview-latex project
> where I am head developer. I delivered a talk about it at the recent
I propose that you stay around a bit, and when 1.3.0 opens, we
can look into this. Right now, LyX is in feature
On Tuesday 14 May 2002 9:47 am, Asger K. Alstrup Nielsen wrote:
> On 12 May 2002, David Kastrup wrote:
> > Several of you probably are already aware of the preview-latex project
> > where I am head developer. I delivered a talk about it at the recent
>
> I propose that you stay around a bit, and
review-latex, and it could obliterate quite a bit of
the glue code done in Emacs Lisp there, and which would presumably be
done in C++ for preview-LyX. Since Emacs provides a usable (though
idiosyncratic) rapid prototyping extension language and a powerful
display engine, and I am used to it, I wil
On Sun, May 12, 2002 at 04:59:09PM +0200, David Kastrup wrote:
> [...] In contrast, I believe LyX to have the necessary infrastructure for
> that kind of functionality.
At least partially... I believe so, too.
> [...] Even in those areas where LyX _does_ know its things
> (like in math
ems and environments I would not prefer for personal work. When I
am forced to use and offer them, I better make sure that I do all that
is reasonable to ensure this will be as painless as it gets for me and
prospective customers.
And don't you believe I am not perfectly capable of stealing any
important for its acceptance: does
> LyX offer some sort of multithreading or asynchronicity or the like?
We don't have proper multithreading, but some of the graphics stuff is
(was?) rendered asynchronously already.
> And don't you believe I am not perfectly capable of stealing any good
> code tha
On Tuesday 14 May 2002 12:47 pm, Andre Poenitz wrote:
> We don't have proper multithreading, but some of the graphics stuff is
> (was?) rendered asynchronously already.
We have a forkedcalls class that executes a fork-ed process and emits a
signal when that process finishes. I think that it'd
Angus Leeming <[EMAIL PROTECTED]> writes:
> On Tuesday 14 May 2002 12:47 pm, Andre Poenitz wrote:
> > We don't have proper multithreading, but some of the graphics stuff is
> > (was?) rendered asynchronously already.
>
> We have a forkedcalls class that executes a fork-ed process and emits a
>
Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> > At the current point of time, preview-latex is defensive in
> > resource usage; you need an explicit request to let it start the
> > background machinations. Part of the reason is that there are
> > associated fixed costs with starting up LaTeX,
On Tuesday 14 May 2002 1:47 pm, David Kastrup wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> > On Tuesday 14 May 2002 12:47 pm, Andre Poenitz wrote:
> > > We don't have proper multithreading, but some of the graphics stuff is
> > > (was?) rendered asynchronously already.
> >
> > We have a
Angus Leeming <[EMAIL PROTECTED]> writes:
> On Tuesday 14 May 2002 1:47 pm, David Kastrup wrote:
> > Angus Leeming <[EMAIL PROTECTED]> writes:
> > > On Tuesday 14 May 2002 12:47 pm, Andre Poenitz wrote:
> > > > We don't have proper multithreading, but some of the graphics stuff is
> > > > (was?)
On Tuesday 14 May 2002 2:20 pm, David Kastrup wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> > On Tuesday 14 May 2002 1:47 pm, David Kastrup wrote:
> > > Angus Leeming <[EMAIL PROTECTED]> writes:
> > > > On Tuesday 14 May 2002 12:47 pm, Andre Poenitz wrote:
> > > > > We don't have proper
>
> They waited 18 months for 1.2. They're going to like what they see which
> should give us some time before thay start screaming for more ;-)
>
> Angus
As a token user"MORE!"
Thought I'd try to be the first...
Regards (and many thanks)
Rod
Angus Leeming <[EMAIL PROTECTED]> writes:
> Well LyX is getting better at graphics. It can display almost any
> graphics file you throw at it, either by loading the file direct or
> by converting it to a loadable format and loading that temp
> file. All graphics loading and rendering is
1 - 100 of 102 matches
Mail list logo
