Re: preview lyx
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 original output. That would mean that the current paragraph being edited would not be subject to previews, but those around the current one would: certainly an interesting experiment, but I am not sure that it would warrant implementing at first, at least, if what I understood from Andre is more or less correct, the display code outside of the math editor is quite likely to change quite a bit in the near future. 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 (switching from the preview display to the mathed display) is a little distracting. But this is only my opinion.
Re: preview lyx
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 (switching from the preview display to the mathed display) is a little distracting. But this is only my opinion. And that's why \preview defaults to false (and that will stay that way) Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: preview lyx
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 display that is performed when opening a formula (switching from the preview display to the mathed display) is a little distracting. But this is only my opinion. And that's why \preview defaults to false (and that will stay that way) The main application is when you are fiddling with things like spacing, or when you are using user-defined macros or other constructs that LyX does not understand by itself. It will be a nice addition for dealing with ERT, once the text inset stuff has stabilized properly. But the math editor is certainly a nice testbed. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: preview lyx
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 (switching from the preview display to the mathed display) is a little distracting. But this is only my opinion. You obviously don't use as much maths as me ;) This feature looks like it could be the feature which causes me to switch back from emacs to LyX again, which ought to be some kind of recommendation :) I frequently use constructs which LyX's mathed doesn't understand, and I'd love to see them rendered... Clearly maths is something of a minority interest (my impression from the bug reports I get on Debian is that most Debian LyX users don't make extensive use of it, for example), but for those of us that do use it, this is a 'killer-app' quality feature. Jules
Re: preview lyx
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 opinion, the change in display that is performed when opening a formula (switching from the preview display to the mathed display) is a little distracting. But this is only my opinion. You obviously don't use as much maths as me ;) Really? On my thesis files (which BTW, I finished writing today) grep begin_inset Formula */*lyx | wc -l 7422 This feature looks like it could be the feature which causes me to switch back from emacs to LyX again, which ought to be some kind of recommendation :) I frequently use constructs which LyX's mathed doesn't understand, and I'd love to see them rendered... I hope we will support 99% of math constructs some day. What constructs that you use are not supported currently ?
Re: preview lyx
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, either one. (T. Jefferson)
Re: preview lyx
On Thu, Jun 27, 2002 at 01:36:50PM +0300, Dekel Tsur wrote: 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 opinion, the change in display that is performed when opening a formula (switching from the preview display to the mathed display) is a little distracting. But this is only my opinion. You obviously don't use as much maths as me ;) Really? On my thesis files (which BTW, I finished writing today) grep begin_inset Formula */*lyx | wc -l 7422 :-) OK, you've obviously been happy with LyX's subset of maths features, then. This feature looks like it could be the feature which causes me to switch back from emacs to LyX again, which ought to be some kind of recommendation :) I frequently use constructs which LyX's mathed doesn't understand, and I'd love to see them rendered... I hope we will support 99% of math constructs some day. What constructs that you use are not supported currently ? 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 would allow me to at least see pretty renderings of the ERT LyX doesn't like. Jules
Re: 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 .lyx files.
Re: preview lyx
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 preview stuff. The latter is definitely less work... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: preview lyx
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 solution. Either lyx understands all TeX primitives or we would need the preview stuff. The latter is definitely less work... Bearing in mind that 'understand all TeX primitives' roughly boils down to 'being able to calculate the total state of the TeX machine at every point' which is no mean feat... In some sense it would be a step backwards, since the LyX document representation is more structured than the underlying TeX one. Jules
Re: preview lyx
> > 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 original output. That would mean that the current > paragraph being edited would not be subject to previews, but those > around the current one would: certainly an interesting experiment, but > I am not sure that it would warrant implementing at first, at least, > if what I understood from Andre is more or less correct, the display > code outside of the math editor is quite likely to change quite a bit > in the near future. 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 (switching from the preview display to the mathed display) is a little distracting. But this is only my opinion.
Re: preview lyx
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 (switching from the preview display to the mathed display) > is a little distracting. > But this is only my opinion. And that's why \preview defaults to false (and that will stay that way) Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: preview lyx
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 display that > > is performed when opening a formula (switching from the preview > > display to the mathed display) is a little distracting. But this > > is only my opinion. > > And that's why \preview defaults to false (and that will stay that way) The main application is when you are fiddling with things like spacing, or when you are using user-defined macros or other constructs that LyX does not understand by itself. It will be a nice addition for dealing with ERT, once the text inset stuff has stabilized properly. But the math editor is certainly a nice testbed. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: preview lyx
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 (switching from the preview display to the mathed display) > is a little distracting. > But this is only my opinion. You obviously don't use as much maths as me ;) This feature looks like it could be the feature which causes me to switch back from emacs to LyX again, which ought to be some kind of recommendation :) I frequently use constructs which LyX's mathed doesn't understand, and I'd love to see them rendered... Clearly maths is something of a minority interest (my impression from the bug reports I get on Debian is that most Debian LyX users don't make extensive use of it, for example), but for those of us that do use it, this is a 'killer-app' quality feature. Jules
Re: preview lyx
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 opinion, the change in display that is performed when > > opening a formula (switching from the preview display to the mathed display) > > is a little distracting. > > But this is only my opinion. > > You obviously don't use as much maths as me ;) Really? On my thesis files (which BTW, I finished writing today) grep "begin_inset Formula" */*lyx | wc -l 7422 > This feature looks like it could be the feature which causes me to > switch back from emacs to LyX again, which ought to be some kind of > recommendation :) I frequently use constructs which LyX's mathed > doesn't understand, and I'd love to see them rendered... I hope we will support 99% of math constructs some day. What constructs that you use are not supported currently ?
Re: preview lyx
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, either one. (T. Jefferson)
Re: preview lyx
On Thu, Jun 27, 2002 at 01:36:50PM +0300, Dekel Tsur wrote: > 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 opinion, the change in display that is performed when > > > opening a formula (switching from the preview display to the mathed display) > > > is a little distracting. > > > But this is only my opinion. > > > > You obviously don't use as much maths as me ;) > > Really? > On my thesis files (which BTW, I finished writing today) > grep "begin_inset Formula" */*lyx | wc -l > >7422 :-) OK, you've obviously been happy with LyX's subset of maths features, then. > > > This feature looks like it could be the feature which causes me to > > switch back from emacs to LyX again, which ought to be some kind of > > recommendation :) I frequently use constructs which LyX's mathed > > doesn't understand, and I'd love to see them rendered... > > I hope we will support 99% of math constructs some day. > What constructs that you use are not supported currently ? 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 would allow me to at least see pretty renderings of the ERT LyX doesn't like. Jules
Re: 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 .lyx files.
Re: preview lyx
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 preview stuff. The latter is definitely less work... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: preview lyx
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 solution. Either lyx understands all TeX primitives > or we would need the preview stuff. The latter is definitely less work... Bearing in mind that 'understand all TeX primitives' roughly boils down to 'being able to calculate the total state of the TeX machine at every point' which is no mean feat... In some sense it would be a step backwards, since the LyX document representation is more structured than the underlying TeX one. Jules
Re: preview lyx
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 '/tmp/lyx/EcEeHcEc.eps' not finished loading
writing '$D'$' to '/tmp/lyx/EcEeHcEc.eps'
file '/tmp/lyx/EcEeHcEc.eps' not finished loading
writing '$D'$' to '/tmp/lyx/EcEeHcEc.eps'
file '/tmp/lyx/EcEeHcEc.eps' not finished loading
writing '\[
E\left(0\right)-E\left(\kappa \right)\propto \sqrt{\kappa }^{1-D'}\]
' to
'/tmp/lyx/MfLfKaFeMfMgFgGgEhIcAdMfChJgHgIgEhJcNcFeMfMgFgGgEhIcMfLgBgAhAhBgAcMfChJgHgIgEhJcMfAhChPgAhEhPgAcMfDhBhChEhLhMfLgBgAhAhBgAcNhOfLhBdNcEeHcNhMfNfKa.eps'
/tmp/lyx/: No such file or directory
Re: preview lyx
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 directory Proof-of-concept-mode. Does it help to do mkdir /tmp/lyx ? It does. The result isn't quite there yet (see attached) but it's looking very encouraging. Congratulations both. Angus preview.png Description: PNG image
Re: preview 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- writing '$D'$' to '/tmp/lyx/EcEeHcEc.eps'
/tmp/lyx/: No such file or directory
Proof-of-concept-mode. Does it help to do
mkdir /tmp/lyx
?
It does. The result isn't quite there yet (see attached) but it's
looking very encouraging. Congratulations both.
Both? The credit I could claim for this work is just being a
general pest. This is entirely André's work.
For maximal usefulness, when you are not editing the formula, I would
think it best if the LyX version was _completely_ replaced by the
preview.
One thing I have noticed from your screenshot is that the colors are
off.
If you are just working via command line, try
-c 0.5 0.3 0.7 setrgbcolor clippath fill 0.2 0.8 0.9 setrgbcolor -f
on the GhostScript command line after the device has been set, of
course using the RGB values of the current background and foreground
colors of the LyX window. If you have those as integer numbers, you
can write
-c '[' 45 54 54 234 234 234 ']' '{' 255 div '}' forall setrgbcolor
clippath fill setrgbcolor -f
(here background color triple comes first).
Or if you have them in hex, just write
-c '45afcf003b3c' '{' 255 div '}' forall setrgbcolor clippath fill
setrgbcolor -f
Here the first 6 hexadecimal digits are foreground RGB.
Hope this helps.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: preview lyx
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 '/tmp/lyx/EcEeHcEc.eps' not finished loading
writing '$D'$' to '/tmp/lyx/EcEeHcEc.eps'
file '/tmp/lyx/EcEeHcEc.eps' not finished loading
writing '$D'$' to '/tmp/lyx/EcEeHcEc.eps'
file '/tmp/lyx/EcEeHcEc.eps' not finished loading
writing '\[
E\left(0\right)-E\left(\kappa \right)\propto \sqrt{\kappa }^{1-D'}\]
' to
'/tmp/lyx/MfLfKaFeMfMgFgGgEhIcAdMfChJgHgIgEhJcNcFeMfMgFgGgEhIcMfLgBgAhAhBgAcMfChJgHgIgEhJcMfAhChPgAhEhPgAcMfDhBhChEhLhMfLgBgAhAhBgAcNhOfLhBdNcEeHcNhMfNfKa.eps'
/tmp/lyx/: No such file or directory
Re: preview lyx
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 directory > > Proof-of-concept-mode. Does it help to do > mkdir /tmp/lyx > ? It does. The result isn't quite there yet (see attached) but it's looking very encouraging. Congratulations both. Angus preview.png Description: PNG image
Re: preview 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-> writing '$D'$' to '/tmp/lyx/EcEeHcEc.eps'
> > > /tmp/lyx/: No such file or directory
> >
> > Proof-of-concept-mode. Does it help to do
> > mkdir /tmp/lyx
> > ?
>
> It does. The result isn't quite there yet (see attached) but it's
> looking very encouraging. Congratulations both.
"Both"? The credit I could claim for this work is just being a
general pest. This is entirely André's work.
For maximal usefulness, when you are not editing the formula, I would
think it best if the LyX version was _completely_ replaced by the
preview.
One thing I have noticed from your screenshot is that the colors are
off.
If you are just working via command line, try
-c 0.5 0.3 0.7 setrgbcolor clippath fill 0.2 0.8 0.9 setrgbcolor -f
on the GhostScript command line after the device has been set, of
course using the RGB values of the current background and foreground
colors of the LyX window. If you have those as integer numbers, you
can write
-c '[' 45 54 54 234 234 234 ']' '{' 255 div '}' forall setrgbcolor
clippath fill setrgbcolor -f
(here background color triple comes first).
Or if you have them in hex, just write
-c '<45afcf003b3c>' '{' 255 div '}' forall setrgbcolor clippath fill
setrgbcolor -f
Here the first 6 hexadecimal digits are foreground RGB.
Hope this helps.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: preview lyx
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 lot of time is wasted by calling dvips and then using gs to convert the eps into a bitmap. I'm sure that there is a dvi-bitmap program somewhere.
Re: preview lyx
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 eats quite a bit of memory currently and does not clean up properly. A bit of scaling would not hurt either, so a bit of work still needs to be done. Do try it out, change the #if 0 into #if 1 in mathed/formula.C. There are two #if 0 in that file, but I was intelligent enough to select the correct one. Anyway, why limit the preview only to mathed ? Wouldn't it be nicer to have a preview of the entire current paragraph (i.e., something similar to whizzytex) ?
Re: preview lyx
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 lot of time is wasted by calling dvips and then using gs to convert the eps into a bitmap. I'm sure that there is a dvi->bitmap program somewhere.
Re: preview lyx
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 eats quite a bit of memory currently and does not clean up properly. > A bit of scaling would not hurt either, so a bit of work still needs to > be done. > > Do try it out, change the #if 0 into #if 1 in mathed/formula.C. There are two #if 0 in that file, but I was intelligent enough to select the correct one. Anyway, why limit the preview only to mathed ? Wouldn't it be nicer to have a preview of the entire current paragraph (i.e., something similar to whizzytex) ?
Re: preview-LyX ?
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 rendering is asynchronous, so slowness doesn't block the user. [...] (Xforms can load, directly and quickly, BMP, GIF, JPEG, PNM, TIF, XBM, XPM bitmap formats). What would be the format that (a) can be produced by gs, (b) displayed natively by LyX and (c) is the fastest? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: preview-LyX ?
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: jpeg, pnm, tif I guess that fastest is a trial and error discovery. A
Re: preview-LyX ?
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 natively by LyX, these formats could be used: jpeg, pnm, tif I guess that fastest is a trial and error discovery. JPEG is unsuitable for typeset material. PNM leads to large file sizes. I would think that GhostScript's tiffpack device would probably be the thing to use. Except that for some reason or other, my Ghostscript generates just junk when I use it. At least the usual programs using libtiff do not seem comfortable with it. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: preview-LyX ?
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 natively by LyX, these formats could be used: jpeg, pnm, tif I guess that fastest is a trial and error discovery. Forget my last comment: just found out that with the exception of the noncompressed TIF devices, all of the TIF in GhostScript are just BlackWhite (1 bit per pixel). The noncompressed ones offer no size advantage over the simpler pnm. That leaves pnm as the only feasible candidate out of the box. At 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). 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. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: preview-LyX ?
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 start bugging the xforms mailing list once xforms 1.0 is released. Angus
Re: preview-LyX ?
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 May 9 2000 pei.png -rw-r--r--1 garstusers 279804 May 10 2000 pei.pnm I would expect that while the GIF file is smaller, this is because it first reduced the figure to a 256-color palette. PNG can be truecolor, in contrast. My GhostScript does not support GIF anyway, probably because of the patent issues. This leaves PNM, and the above underlines that native PNG support would not be the worst idea. A typical computer will be quite faster reading 2640 byte from disk and uncompressing to 280kB than it could be just reading in 280kB of uncompressed data. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: preview-LyX ?
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, and probably no need to spawn another gs process. By the time that we implement a cool feature like we are discussing, the remaining xforms bugs with using gs like this will be long gone I would imagine (in fact hopefully my last patch for xforms got rid of the last case). regards john -- So what you're saying is screw the disabled and you want us to do the same ? No thanks... - Ian Hixie, bug 25537
Re: preview-LyX ?
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 this can work when we are
mixing ERT with normal LyX objects. For example, the current CVs doesn't
support floatingfigure (though there is a patch for this available), so
users have to do :
ERT : [ \floatingfigure[l]{ ]
LyX figure inset
ERT : [ } ]
or similar. So each inset in cases like this cannot be rendered in
isolation. A similar problem occurs with ERT that just contains macro
definitions or the like, there is no actual output generated.
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
?
regards
john
--
So what you're saying is screw the disabled and you want us to do the
same ? No thanks...
- Ian Hixie, bug 25537
Re: preview-LyX ?
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. 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 with that approach. Philippmailto:[EMAIL PROTECTED] ___ There is a chasm / of carbon and silicon / the software can't bridge
Re: preview-LyX ?
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 non-X platforms? If I Yes, it would. It doesn't mean, however, we can't support both this and a file-based approach. regards john -- So what you're saying is screw the disabled and you want us to do the same ? No thanks... - Ian Hixie, bug 25537
Re: preview-LyX ?
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 to for figinset, since there is no intermediate file, and probably no need to spawn another gs process. By the time that we implement a cool feature like we are discussing, the remaining xforms bugs with using gs like this will be long gone I would imagine (in fact hopefully my last patch for xforms got rid of the last case). regards john John, I don't think that David is subscribed to the list yet, so he won't be getting these insights. Angus
Re: preview-LyX ?
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 same ? No thanks... - Ian Hixie, bug 25537
Re: preview-LyX ?
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).
Actually David I have a question about how this can work when we are
mixing ERT with normal LyX objects. For example, the current CVs doesn't
support floatingfigure (though there is a patch for this available), so
users have to do :
ERT : [ \floatingfigure[l]{ ]
LyX figure inset
ERT : [ } ]
or similar. So each inset in cases like this cannot be rendered in
isolation. A similar problem occurs with ERT that just contains macro
definitions or the like, there is no actual output generated.
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 ?
Good point. In order to treat stuff like the above properly, LyX
would need the concept of regular stuff nested inside of ERT that
is supposed to be previewed. Perhaps something like opening ERT
and closing ERT ? I believe that once an actual implementation is
available, a few iterations will be required until coming up with
reasonable schemes to accommodate common requirements. A reasonable
first approach would be to do turn previews off where LaTeX produces
errors.
preview-latex has fewer problems in that area since it basically has
only a document consisting just in ERT to deal with (it does not
understand anything). The actual filtering and location of the
previewed chunks is left to LaTeX itself, via the preview style. You
would have to specify something like
\PreviewMacro\floatingfigure[{[]{}}]
in your preamble, and then the style would know that it was supposed
to extract and preview those elements as one figure, or
\PreviewMacro*\floatingfigure[{[]}]
in order to tell the preview style that it should ignore the macro
and its optional argument for previewing purposes. That way, any
previewable stuff inside would be treated properly.
As to the problem of macro definitions in ERT: incremental updates of
display in preview-latex require that you place required definitions
in the document preamble (which is part of every compilation), or
inside of the previewed environment itself. I would think a similar
requirement for the LyX implementation reasonable.
Somewhat related: LaTeX's counters are not checkpointed currently.
This means that equation and section numbers in incremental updates
will come out wrong.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: preview-LyX ?
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 of an inset property... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: preview-LyX ?
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 with that approach. The rendering of course is optional as in use LaTeX fonts if available. We can't force it on users of slower or otherwise handicapped machines anyway... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: preview-LyX ?
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 figinset, since there is no intermediate file, and probably no need to spawn another gs process. I don't concur here. The usual GHOSTVIEW API of GhostScript is rather broken: it will only render into a single window, and it makes it impossible to have more than a single GhostScript process active. The main problem is of course that there is no reasonable way of rendering images off-screen in advance. With preview-latex, all images from a document are getting rendered in background after the ones on the screen have been dealt with. That means that they will be immediately available when paging around the source later. This can be offered by PNG images, but not by images kept in PostScript format. Also, incremental changes in a buffer imply that the images present in a buffer typically come from different LaTeX runs, consequently from different Dvips runs, and the only way to treat them the same way by a single GhostScript process is to make them self-contained EPS files. But this makes the rendering process much slower than when you are able to load the common PostScript preamble just once for those images that can be generated in a single LaTeX/DviPS run. preview-latex started out with just the approach you describe. But for the given reasons, reverting back to it will not be desirable even in case the utterly broken EPS image implementation of Emacs gets fixed one day. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: preview-LyX ?
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 > rendering is asynchronous, so slowness doesn't block the user. > [...] > (Xforms can load, directly and quickly, BMP, GIF, JPEG, PNM, TIF, XBM, XPM > bitmap formats). What would be the format that (a) can be produced by gs, (b) displayed "natively" by LyX and (c) is the "fastest"? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: preview-LyX ?
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: jpeg, pnm, tif I guess that "fastest" is a trial and error discovery. A
Re: preview-LyX ?
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 > natively by LyX, these formats could be used: > jpeg, pnm, tif > I guess that "fastest" is a trial and error discovery. JPEG is unsuitable for typeset material. PNM leads to large file sizes. I would think that GhostScript's tiffpack device would probably be the thing to use. Except that for some reason or other, my Ghostscript generates just junk when I use it. At least the usual programs using libtiff do not seem comfortable with it. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: preview-LyX ?
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 > natively by LyX, these formats could be used: > jpeg, pnm, tif > I guess that "fastest" is a trial and error discovery. Forget my last comment: just found out that with the exception of the noncompressed TIF devices, all of the TIF in GhostScript are just Black (1 bit per pixel). The noncompressed ones offer no size advantage over the simpler pnm. That leaves pnm as the only feasible candidate out of the box. At 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). 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. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: preview-LyX ?
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 start bugging the xforms mailing list once xforms 1.0 is released. Angus
Re: preview-LyX ?
"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 May 9 2000 pei.png > -rw-r--r--1 garstusers 279804 May 10 2000 pei.pnm I would expect that while the GIF file is smaller, this is because it first reduced the figure to a 256-color palette. PNG can be truecolor, in contrast. My GhostScript does not support GIF anyway, probably because of the patent issues. This leaves PNM, and the above underlines that native PNG support would not be the worst idea. A typical computer will be quite faster reading 2640 byte from disk and uncompressing to 280kB than it could be just reading in 280kB of uncompressed data. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: preview-LyX ?
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, and probably no need to spawn another gs process. By the time that we implement a cool feature like we are discussing, the remaining xforms bugs with using gs like this will be long gone I would imagine (in fact hopefully my last patch for xforms got rid of the last case). regards john -- "So what you're saying is "screw the disabled" and you want us to do the same ? No thanks..." - Ian Hixie, bug 25537
Re: preview-LyX ?
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 this can work when we are
mixing ERT with normal LyX objects. For example, the current CVs doesn't
support floatingfigure (though there is a patch for this available), so
users have to do :
ERT : [ \floatingfigure[l]{ ]
LyX figure inset
ERT : [ } ]
or similar. So each inset in cases like this cannot be rendered in
isolation. A similar problem occurs with ERT that just contains macro
definitions or the like, there is no actual output generated.
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
?
regards
john
--
"So what you're saying is "screw the disabled" and you want us to do the
same ? No thanks..."
- Ian Hixie, bug 25537
Re: preview-LyX ?
>> 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. 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 with that approach. Philippmailto:[EMAIL PROTECTED] ___ There is a chasm / of carbon and silicon / the software can't bridge
Re: preview-LyX ?
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 non-X platforms? If I Yes, it would. It doesn't mean, however, we can't support both this and a file-based approach. regards john -- "So what you're saying is "screw the disabled" and you want us to do the same ? No thanks..." - Ian Hixie, bug 25537
Re: preview-LyX ?
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 to for > figinset, since there is no intermediate file, and probably no need to > spawn another gs process. > > By the time that we implement a cool feature like we are discussing, the > remaining xforms bugs with using gs like this will be long gone I would > imagine (in fact hopefully my last patch for xforms got rid of the last > case). > > regards > john John, I don't think that David is subscribed to the list yet, so he won't be getting these insights. Angus
Re: preview-LyX ?
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 same ? No thanks..." - Ian Hixie, bug 25537
Re: preview-LyX ?
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 ugly).
>
> Actually David I have a question about how this can work when we are
> mixing ERT with normal LyX objects. For example, the current CVs doesn't
> support floatingfigure (though there is a patch for this available), so
> users have to do :
>
> ERT : [ \floatingfigure[l]{ ]
> LyX figure inset
> ERT : [ } ]
>
> or similar. So each inset in cases like this cannot be rendered in
> isolation. A similar problem occurs with ERT that just contains macro
> definitions or the like, there is no actual output generated.
>
> 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 ?
Good point. In order to treat stuff like the above properly, LyX
would need the concept of "regular" stuff nested inside of ERT that
is supposed to be previewed. Perhaps something like "opening ERT"
and "closing ERT" ? I believe that once an actual implementation is
available, a few iterations will be required until coming up with
reasonable schemes to accommodate common requirements. A reasonable
first approach would be to do turn previews off where LaTeX produces
errors.
preview-latex has fewer problems in that area since it basically has
only a document consisting just in ERT to deal with (it does not
understand anything). The actual filtering and location of the
previewed chunks is left to LaTeX itself, via the preview style. You
would have to specify something like
\PreviewMacro\floatingfigure[{[]{}}]
in your preamble, and then the style would know that it was supposed
to extract and preview those elements as one figure, or
\PreviewMacro*\floatingfigure[{[]}]
in order to tell the preview style that it should ignore the macro
and its optional argument for previewing purposes. That way, any
previewable stuff inside would be treated properly.
As to the problem of macro definitions in ERT: incremental updates of
display in preview-latex require that you place required definitions
in the document preamble (which is part of every compilation), or
inside of the previewed environment itself. I would think a similar
requirement for the LyX implementation reasonable.
Somewhat related: LaTeX's counters are not checkpointed currently.
This means that equation and section numbers in incremental updates
will come out wrong.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: preview-LyX ?
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 of an inset property... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: preview-LyX ?
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 with that approach. The rendering of course is optional as in "use LaTeX fonts if available". We can't force it on users of slower or otherwise handicapped machines anyway... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: preview-LyX ?
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 figinset, since there is no intermediate file, and probably no > need to spawn another gs process. I don't concur here. The usual GHOSTVIEW API of GhostScript is rather broken: it will only render into a single window, and it makes it impossible to have more than a single GhostScript process active. The main problem is of course that there is no reasonable way of rendering images off-screen in advance. With preview-latex, all images from a document are getting rendered in background after the ones on the screen have been dealt with. That means that they will be immediately available when paging around the source later. This can be offered by PNG images, but not by images kept in PostScript format. Also, incremental changes in a buffer imply that the images present in a buffer typically come from different LaTeX runs, consequently from different Dvips runs, and the only way to treat them the same way by a single GhostScript process is to make them self-contained EPS files. But this makes the rendering process much slower than when you are able to load the common PostScript preamble just once for those images that can be generated in a single LaTeX/DviPS run. preview-latex started out with just the approach you describe. But for the given reasons, reverting back to it will not be desirable even in case the utterly broken EPS image implementation of Emacs gets fixed one day. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: preview-LyX ?
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 freeze until 1.2.0 is out. Greets, Asger
Re: preview-LyX ?
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 1.3.0 opens, we can look into this. Right now, LyX is in feature freeze until 1.2.0 is out. Greets, Asger But that (release of 1.2.0) might happen next week and this looks very interesting. Angus
Re: preview-LyX ?
Angus Leeming [EMAIL PROTECTED] writes: 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, Oh, it is not that I am planning to pass away soon. and when 1.3.0 opens, we can look into this. Right now, LyX is in feature freeze until 1.2.0 is out. But that (release of 1.2.0) might happen next week and this looks very interesting. Agreed, this is nothing to start working on just before a release. But after that has consolidated... the approach could deal with a lot of Evil Red Text and would in its first iterations mostly be based on existing programs. It could also form a base for future work: One of the Omega project's goals is to turn TeX into something callable as a C++ library for typesetting purposes. This could greatly improve the manner and efficiency compared to the current mode of operation of preview-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 will certainly try to keep the Emacs connection up to par with developments in that area. But the ultimate goal will probably be to arrive at a state where tying Omega into the display machinery for arbitrary editors (like Abiword, Openoffice and similar) or browsers will become feasible for foreign language typesetting demands. And I suppose that LyX would be an obvious candidate for pioneering work in that area. While my time frame and personal projects do not allow me to offer substantial amounts of time and work to invest into LyX proper, I am certainly more than willing to provide any assistance my TeX programming expertise and the ongoing experiences with my own project in that area might procur. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: preview-LyX ?
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), some people might not be adverse to having an option to let LyX replace its own rendition of them by a true LaTeX one as long as one is not actively editing the formula. Actually I have been playing with this idea after I've seen your preview-LaTeX package in action. I am fairly sure that can be done at least for mathed by using a mechanism similar to what we already do there for macro editing [Macro with arguments change their appearance to allow editing parameters when the cursor is in the macro. Probably not the best piece of user-interaction, but it works]. Additionally I'd probably allow plain LaTeX editing, too, to accomodate people who'd like to use the hard way (or want to use unusual stuff). So in the end we'd have four cases: (a) cursor outside an inset, inset rendered by LyX (as we do now) (b) cursor outside an inset, inset rendered by LaTeX (your proposal) (c) cursor inside an inset, inset rendered by LyX (as we do now) (d) cursor inside an inset, inset rendered as plain LaTeX source. (a) and (c) is what we have right now, (b) and (d) is what preview-LaTeX does right now. Toggling between ( (a) and (b) ) and ( (c) and (d) ) could be done by some hotkey, so the whole is more than sum of the parts... While most of the _determination_ of the previewable parts would probably already be done by LyX itself, the actual extraction (with the help of the preview environment provided by the style) could still be accomplished using that package. I would be glad to be of assistance if particular options or general advice would be necessary in order to generate a version suitable for working with LyX. I'd basically need a _fast_ way to get some rendered bitmap out of a string like $a^2+b^2$. That's it. The obvious solution would be to create some temp.tex, run LaTeX on it, convert the dvi. I don't know how 'fast' this is, though. I suppose preview-latex can help here already, but I am not sure how far it helps... Of course, since preview-latex is GPLed software, you would be free to incorporate and read all of it that you want into LyX, anyhow. You know, there is always some difference between incorporatin GPLed software and incorporating GPLed software with active help of its author... Andre' PS: Again, I apologize for the intrusion on this list, but hope that it might incite a few of you to look into a particular way of improving LyX in an area I personally would estimate to be well worth the work to be invested. Actually I did not expect /you/ to show up on this list with such an offer of assistance. You are certainly welcome here ;-) -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: preview-LyX ?
Andre Poenitz [EMAIL PROTECTED] writes: 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), some people might not be adverse to having an option to let LyX replace its own rendition of them by a true LaTeX one as long as one is not actively editing the formula. Actually I have been playing with this idea after I've seen your preview-LaTeX package in action. I am fairly sure that can be done at least for mathed by using a mechanism similar to what we already do there for macro editing [Macro with arguments change their appearance to allow editing parameters when the cursor is in the macro. Probably not the best piece of user-interaction, but it works]. That's the point. preview-latex has an auto-reveal-mode where it automatically opens stuff you enter (the default is to cater previews just as one single big character). This can be turned on and off and made dependent on some condition. The setting I use personally is to auto-open stuff if you are moving into it with cursor-left-right, but to keep it as a single character-like entity for other movements. This is wildly inconsistent (word-left-right will not trigger it). It also makes the display jump spontaneously when you are moving into and out of those areas. But it works, as in becomes convenient. Your macro editing sounds just like that. Additionally I'd probably allow plain LaTeX editing, too, to accomodate people who'd like to use the hard way (or want to use unusual stuff). So in the end we'd have four cases: (a) cursor outside an inset, inset rendered by LyX (as we do now) (b) cursor outside an inset, inset rendered by LaTeX (your proposal) (c) cursor inside an inset, inset rendered by LyX (as we do now) (d) cursor inside an inset, inset rendered as plain LaTeX source. (a) and (c) is what we have right now, Actually, (d) is Evil Red Text IIRC, and so the code for it should mostly exist already. (b) and (d) is what preview-LaTeX does right now. It is not automatic. You can toggle between (b) and (d) regardless of the cursor position (although auto-reveal automates that). Editing changes permanently to state (d), you have to manually request regeneration (easy) for this to generate a new (b) (adjacent changed areas are merged into a single LaTeX/DviPS/GhostScript run). 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 GhostScript, and one would want to group requests as much as possible. LaTeX startup time can be considerably reduced by dumping formats (the CVS version of preview-latex uses Carlisle's mylatex.ltx for that purpose). The ultimate goal would be to keep one pipe running. DviPS cannot really be made to fit into that scheme, one would probably want to ultimately replace it with a DVI to bitmap rendering daemon. GhostScript could probably be kept running efficiently across multiple DviPS runs if you did clever resource management (do not download already present fonts and other stuff etc). But that's all future stuff to think about. Toggling between ( (a) and (b) ) and ( (c) and (d) ) could be done by some hotkey, so the whole is more than sum of the parts... Yes. That's exactly the work principle behind this: preview-latex itself does appallingly little except delegating work. While most of the _determination_ of the previewable parts would probably already be done by LyX itself, the actual extraction (with the help of the preview environment provided by the style) could still be accomplished using that package. I would be glad to be of assistance if particular options or general advice would be necessary in order to generate a version suitable for working with LyX. I'd basically need a _fast_ way to get some rendered bitmap out of a string like $a^2+b^2$. That's it. The obvious solution would be to create some temp.tex, run LaTeX on it, convert the dvi. I don't know how 'fast' this is, though. If you start with a pregenerated format, surprisingly so. But you want to have this work asynchronously: editing should not block actively while the rendered bitmaps trundle in. What made me start this project at all was Emacs-21' ability to directly place EPS files into its buffer. Within one week, I had code ready that would place display formulas in the buffer. Even before the first regular release, this approach had to be scrapped, and still is (the historic code is still in and you can enable it, but it probably has suffered bit rot by now). The problem was that Emacs rendered on-demand. Scroll to a page with 20
Re: preview-LyX ?
On Tue, May 14, 2002 at 01:25:09PM +0200, David Kastrup wrote: (d) cursor inside an inset, inset rendered as plain LaTeX source. Actually, (d) is Evil Red Text IIRC, and so the code for it should mostly exist already. Not exactly. ERT within math is converted to proper math if recoqnized as something known. There is normally no way to keep \int as a sequence of four characters. (d) would allow us to do that. 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 GhostScript, and one would want to group requests as much as possible. I see. So there _is_ a performance problem. LaTeX startup time can be considerably reduced by dumping formats (the CVS version of preview-latex uses Carlisle's mylatex.ltx for that purpose). The ultimate goal would be to keep one pipe running. DviPS cannot really be made to fit into that scheme, one would probably want to ultimately replace it with a DVI to bitmap rendering daemon. GhostScript could probably be kept running efficiently across multiple DviPS runs if you did clever resource management (do not download already present fonts and other stuff etc). But that's all future stuff to think about. Do you think you (or somebody else for that matter) will do that kind of work? Soonish? I'd basically need a _fast_ way to get some rendered bitmap out of a string like $a^2+b^2$. That's it. The obvious solution would be to create some temp.tex, run LaTeX on it, convert the dvi. I don't know how 'fast' this is, though. If you start with a pregenerated format, surprisingly so. But you want to have this work asynchronously: editing should not block actively while the rendered bitmaps trundle in. Sure we could just keep a list of insets to be rendered in a background process and as soon as one is finished, we cache this in the LyX inset and display it when needed (i.e. when the next redraw request comes) instead of doing our homegrown rendering. [...] The problem was that Emacs rendered on-demand. Scroll to a page with 20 previews on them, and Emacs started 20 GhostScript processes and would block until most of them were finished placing their bitmaps right into the window. Doing that without blocking should be possible in LyX... This is quite 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 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. Jefferson)
Re: preview-LyX ?
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 perfect for the requirements you describe. And yes, it is used by the graphics code. Angus
Re: preview-LyX ?
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 when that process finishes. I think that it'd be perfect for the
requirements you describe. And yes, it is used by the graphics code.
Somewhat more would be required for feeding the GhostScript process.
Here is an pseudoextract from a fake session:
gs -q -dSAFER -dDELAYSAFER -dNOPAUSE -DNOPLATFONTS -dTextAlphaBits\=4
-dGraphicsAlphaBits\=4 -sDEVICE\=png16m -r135.992x144.924
GS/preview-latex-do{setpagedevice save gsave 0.705882 0.93 0.705882 setrgbcolor
false setstrokeadjust 3.0 setlinewidth clippath strokepath matrix setmatrix true { 2
index { newpath } if round exch round exch moveto pop false } { round exch round exch
lineto } { curveto } { closepath } pathforall pop fill grestore exch[count 2 roll]exch
cvx systemdict/.runandhide known revision 700 ge and{.setsafe{.runandhide}}if
stopped{handleerror quit}if count 1 ne{quit}if aload pop restore}bind def
(/home/dak/src/preview/_region_.prv/tmp1327ZQd/preview.ps)(r)file dup dup 0
setfileposition 17994()/SubFileDecode filter cvx exec dup dup 17994 setfileposition
85()/SubFileDecode filter cvx /PageSize[40.7122 9.85568]/PageOffset[-71.5
717.563]/OutputFile(/home/dak/src/preview/_region_.prv/tmp1327ZQd/prev001.png)preview-latex-do
(in case it does not survive in the mail, all of the above behind the
prompt is a single command). That's the initial command fed to
GhostScript (contains a lot of complications for the sake of adding a
coloured border with non-antialiased edges around the image in order
to make a nice cursor display) for the first image. More images of
the same run would then look just like the last part:
GS1dup dup 17994 setfileposition 85()/SubFileDecode filter cvx /PageSize[40.7122
9.85568]/PageOffset[-71.5
717.563]/OutputFile(/home/dak/src/preview/_region_.prv/tmp1327ZQd/prev001.png)preview-latex-do
This selects the source portion in the (already open) PostScript file
for the next scrap to be rendered, sets up the dimensions of the
graphics and the file name to produce, and does the next graphic.
So one has to react to GhostScript producing a prompt, then feed it
the next item (actually, the next few: we allow for a few outstanding
requests in order not to let GhostScript idle unnecessarily). It's
not just termination that is interesting, but there is an ongoing
communication.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: preview-LyX ?
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 GhostScript, and one would want to group requests as much as possible. I see. So there _is_ a performance problem. It is called Jan-Åke. He has a 150Mhz computer or so. At the current point of time, preview-latex is working convincingly for him, but this has not always been that way. Historically, DviPS was called with options -i -E in order to generate one EPS file per image. Generating the stuff separately took time, passing it through GhostScript (which reloaded fonts and reinitialized sections all the time) took time. EPS was necessary because of bounding boxes. We now get the bounding box info from directly from TeX. This necessitated quite a few changes in preview.sty: previously it was fine with outputting horizontal material in a \vbox as a full line: DviPS determined the bounding box just by looking at actually typeset material. Cropping the boxes to sensible dimensions from TeX requires quite a bit of wizardry with \lastbox, \vsplit and the like. Since we now have the bounding box info available separately, we don't need no stinking EPS, but just a single fat PS file. Its preamble is just passed once through GhostScript, then the separate pages are passed in display optimized order through. This necessitates some basic parsing of the DSC comments, like PostScript previewers do. By now one could probably make some of the reprocessing automatic. LaTeX startup time can be considerably reduced by dumping formats (the CVS version of preview-latex uses Carlisle's mylatex.ltx for that purpose). The ultimate goal would be to keep one pipe running. DviPS cannot really be made to fit into that scheme, one would probably want to ultimately replace it with a DVI to bitmap rendering daemon. GhostScript could probably be kept running efficiently across multiple DviPS runs if you did clever resource management (do not download already present fonts and other stuff etc). But that's all future stuff to think about. Do you think you (or somebody else for that matter) will do that kind of work? Soonish? There is the GPLed DVIlib2 library rendering DVI directly to bitmaps. That would be just the thing to use. Unfortunately, in some experiments I did it appeared to be slower than the DviPS/GhostScript combo. It also had some other problems (like not wanting to render above the 0in coordinate even if I told it the paper was supposed to start above there). I have not received replies to some requests to the author, and have not pursued this matter further. If people were willing to invest serious work into it, this would probably be the technically soundest implementation path in the long term. There is a dvi2bitmap program under a noncommercial license (which is not really good enough for me to want to make my GPLed code rely on it), and there is presumably some free dvi2gif that could be slaughtered for its innards (the latter info I just recently got from Yannis Haralambous). It might also be an idea to take a look at a few DVI previewers (traditionally fast renderers of bitmaps) and see whether one could rip code from them. But the DviPS/GhostScript path is a good start and should probably be retained at least as an option for things like PStricks graphics. I'd basically need a _fast_ way to get some rendered bitmap out of a string like $a^2+b^2$. That's it. The obvious solution would be to create some temp.tex, run LaTeX on it, convert the dvi. I don't know how 'fast' this is, though. If you start with a pregenerated format, surprisingly so. But you want to have this work asynchronously: editing should not block actively while the rendered bitmaps trundle in. Sure we could just keep a list of insets to be rendered in a background process and as soon as one is finished, we cache this in the LyX inset and display it when needed (i.e. when the next redraw request comes) instead of doing our homegrown rendering. Good. [...] The problem was that Emacs rendered on-demand. Scroll to a page with 20 previews on them, and Emacs started 20 GhostScript processes and would block until most of them were finished placing their bitmaps right into the window. Doing that without blocking should be possible in LyX... Don't ever think of starting 20 GhostScript processes simultaneously for 20 previews. It's sinful. This is quite 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. That sounds like the basic framework should be there. Emacs does not have proper
Re: preview-LyX ?
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 class that executes a fork-ed process and emits a signal when that process finishes. I think that it'd be perfect for the requirements you describe. And yes, it is used by the graphics code. Somewhat more would be required for feeding the GhostScript process. Here is an pseudoextract from a fake session: What you describe is conceptually similar to spellchecking and we can spellcheck in LyX ;-) (I mean that we're communicating interactively with an external program, ispell or gs.) LyX's spellchecker code communicates with ispell via pipes. How do you communicate with gs? Angus
Re: preview-LyX ?
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 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 perfect for the requirements you describe. And yes, it is used by the graphics code. Somewhat more would be required for feeding the GhostScript process. Here is an pseudoextract from a fake session: What you describe is conceptually similar to spellchecking and we can spellcheck in LyX ;-) (I mean that we're communicating interactively with an external program, ispell or gs.) LyX's spellchecker code communicates with ispell via pipes. How do you communicate with gs? Pipes. So it seems like all of the technical infrastructure necessary to let LyX manage the data flow for generating inline previews as well as preview-latex does would already be present. Uh, wait: it should support fast display of bitmap files in a format that GhostScript can produce. But I would guess this would not prove really much of an issue? Just hope that not too many _users_ are reading the developer lists, or they may come banging at your doors asking you to do what appears doable after all... -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: preview-LyX ?
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 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 perfect for the requirements you describe. And yes, it is used by the graphics code. Somewhat more would be required for feeding the GhostScript process. Here is an pseudoextract from a fake session: What you describe is conceptually similar to spellchecking and we can spellcheck in LyX ;-) (I mean that we're communicating interactively with an external program, ispell or gs.) LyX's spellchecker code communicates with ispell via pipes. How do you communicate with gs? Pipes. So it seems like all of the technical infrastructure necessary to let LyX manage the data flow for generating inline previews as well as preview-latex does would already be present. Uh, wait: it should support fast display of bitmap files in a format that GhostScript can produce. But I would guess this would not prove really much of an issue? 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, so slowness doesn't block the user. You may have heard that one of the immediate goals that we have set ourselves is to support multiple GUI toolkits cleanly. We currently use the xforms library to load graphics files. Its image loading routines do not (currently) load PNG files, so we'd have to follow the (slow) conversion route. (Xforms can load, directly and quickly, BMP, GIF, JPEG, PNM, TIF, XBM, XPM bitmap formats). Fortunately xforms is now LGPL-ed and modifiable, so native loading of PNG is an achievable target. Moreover, one of the main goals of 1.3 is to finish the Qt port; that would use Qt's image loading routines which I understand are pretty good. So yes, it looks like progress is possible. Just hope that not too many _users_ are reading the developer lists, or they may come banging at your doors asking you to do what appears doable after all... 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
Re: preview-LyX ?
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
Re: preview-LyX ?
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, so slowness doesn't block the user. You may have heard that one of the immediate goals that we have set ourselves is to support multiple GUI toolkits cleanly. We currently use the xforms library to load graphics files. Its image loading routines do not (currently) load PNG files, so we'd have to follow the (slow) conversion route. (Xforms can load, directly and quickly, BMP, GIF, JPEG, PNM, TIF, XBM, XPM bitmap formats). PNG is simply chosen because it is a fast truecolor format turning out very compact for typical typeset stuff. It is a nobrainer to let GhostScript produce other image formats. Probably some TIF format would fit the bill. Fortunately xforms is now LGPL-ed and modifiable, so native loading of PNG is an achievable target. Would be a good idea, anyhow. libpng should make this reasonably easy. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: preview-LyX ?
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 freeze until 1.2.0 is out. Greets, Asger
Re: preview-LyX ?
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 1.3.0 opens, we > can look into this. Right now, LyX is in feature freeze until > 1.2.0 is out. > > Greets, > > Asger But that (release of 1.2.0) might happen next week and this looks very interesting. Angus
Re: preview-LyX ?
Angus Leeming <[EMAIL PROTECTED]> writes: > 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, Oh, it is not that I am planning to pass away soon. > > and when 1.3.0 opens, we can look into this. Right now, LyX is in > > feature freeze until 1.2.0 is out. > > But that (release of 1.2.0) might happen next week and this looks > very interesting. Agreed, this is nothing to start working on just before a release. But after that has consolidated... the approach could deal with a lot of "Evil Red Text" and would in its first iterations mostly be based on existing programs. It could also form a base for future work: One of the Omega project's goals is to turn TeX into something callable as a C++ library for typesetting purposes. This could greatly improve the manner and efficiency compared to the current mode of operation of preview-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 will certainly try to keep the Emacs connection up to par with developments in that area. But the ultimate goal will probably be to arrive at a state where tying Omega into the display machinery for arbitrary editors (like Abiword, Openoffice and similar) or browsers will become feasible for foreign language typesetting demands. And I suppose that LyX would be an obvious candidate for pioneering work in that area. While my time frame and personal projects do not allow me to offer substantial amounts of time and work to invest into LyX proper, I am certainly more than willing to provide any assistance my TeX programming expertise and the ongoing experiences with my own project in that area might procur. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: preview-LyX ?
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), some people might not be adverse to having > an option to let LyX replace its own rendition of them by a true > LaTeX one as long as one is not actively editing the formula. Actually I have been playing with this idea after I've seen your preview-LaTeX package in action. I am fairly sure that can be done at least for mathed by using a mechanism similar to what we already do there for macro editing [Macro with arguments change their appearance to allow editing parameters when the cursor is "in" the macro. Probably not the best piece of user-interaction, but it "works"]. Additionally I'd probably allow "plain LaTeX" editing, too, to accomodate people who'd like to use the "hard way" (or want to use "unusual" stuff). So in the end we'd have four cases: (a) cursor outside an inset, inset rendered by LyX (as we do now) (b) cursor outside an inset, inset rendered by LaTeX (your proposal) (c) cursor inside an inset, inset rendered by LyX (as we do now) (d) cursor inside an inset, inset rendered as plain LaTeX source. (a) and (c) is what we have right now, (b) and (d) is what preview-LaTeX does right now. Toggling between ( (a) and (b) ) and ( (c) and (d) ) could be done by some hotkey, so "the whole is more than sum of the parts"... > While most of the _determination_ of the previewable parts would probably > already be done by LyX itself, the actual extraction (with the help of > the preview environment provided by the style) could still be > accomplished using that package. I would be glad to be of assistance > if particular options or general advice would be necessary in order to > generate a version suitable for working with LyX. I'd basically need a _fast_ way to get some rendered bitmap out of a string like $a^2+b^2$. That's it. The "obvious" solution would be to create some temp.tex, run LaTeX on it, convert the dvi. I don't know how 'fast' this is, though. I suppose preview-latex can help here already, but I am not sure how far it helps... > Of course, since preview-latex is GPLed software, you would be free to > incorporate and read all of it that you want into LyX, anyhow. You know, there is always some difference between "incorporatin GPLed software" and "incorporating GPLed software with active help of its author"... Andre' PS: > Again, I apologize for the intrusion on this list, but hope that it might > incite a few of you to look into a particular way of improving LyX in an > area I personally would estimate to be well worth the work to be > invested. Actually I did not expect /you/ to show up on this list with such an offer of assistance. You are certainly welcome here ;-) -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: preview-LyX ?
Andre Poenitz <[EMAIL PROTECTED]> writes: > 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), some people might not be adverse to having > > an option to let LyX replace its own rendition of them by a true > > LaTeX one as long as one is not actively editing the formula. > > Actually I have been playing with this idea after I've seen your > preview-LaTeX package in action. I am fairly sure that can be done > at least for mathed by using a mechanism similar to what we already > do there for macro editing [Macro with arguments change their > appearance to allow editing parameters when the cursor is "in" the > macro. Probably not the best piece of user-interaction, but it > "works"]. That's the point. preview-latex has an auto-reveal-mode where it automatically opens stuff you enter (the default is to cater previews just as one single big character). This can be turned on and off and made dependent on some condition. The setting I use personally is to auto-open stuff if you are moving into it with cursor-left-right, but to keep it as a single character-like entity for other movements. This is wildly inconsistent (word-left-right will not trigger it). It also makes the display jump spontaneously when you are moving into and out of those areas. But it "works", as in "becomes convenient". Your macro editing sounds just like that. > Additionally I'd probably allow "plain LaTeX" editing, too, to > accomodate people who'd like to use the "hard way" (or want to use > "unusual" stuff). > > So in the end we'd have four cases: > > (a) cursor outside an inset, inset rendered by LyX (as we do now) > (b) cursor outside an inset, inset rendered by LaTeX (your proposal) > (c) cursor inside an inset, inset rendered by LyX (as we do now) > (d) cursor inside an inset, inset rendered as plain LaTeX source. > > (a) and (c) is what we have right now, Actually, (d) is "Evil Red Text" IIRC, and so the code for it should mostly exist already. > (b) and (d) is what preview-LaTeX does right now. It is not automatic. You can toggle between (b) and (d) regardless of the cursor position (although auto-reveal automates that). Editing changes permanently to state (d), you have to manually request regeneration (easy) for this to generate a new (b) (adjacent changed areas are merged into a single LaTeX/DviPS/GhostScript run). 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 GhostScript, and one would want to group requests as much as possible. LaTeX startup time can be considerably reduced by dumping formats (the CVS version of preview-latex uses Carlisle's mylatex.ltx for that purpose). The ultimate goal would be to keep one pipe running. DviPS cannot really be made to fit into that scheme, one would probably want to ultimately replace it with a DVI to bitmap rendering daemon. GhostScript could probably be kept running efficiently across multiple DviPS runs if you did clever resource management (do not download already present fonts and other stuff etc). But that's all future stuff to think about. > Toggling between ( (a) and (b) ) and ( (c) and (d) ) could be done > by some hotkey, so "the whole is more than sum of the parts"... Yes. That's exactly the work principle behind this: preview-latex itself does appallingly little except delegating work. > > While most of the _determination_ of the previewable parts would > > probably already be done by LyX itself, the actual extraction > > (with the help of the preview environment provided by the style) > > could still be accomplished using that package. I would be glad > > to be of assistance if particular options or general advice would > > be necessary in order to generate a version suitable for working > > with LyX. > > I'd basically need a _fast_ way to get some rendered bitmap out of a > string like $a^2+b^2$. That's it. The "obvious" solution would be to > create some temp.tex, run LaTeX on it, convert the dvi. I don't know > how 'fast' this is, though. If you start with a pregenerated format, surprisingly so. But you want to have this work asynchronously: editing should not block actively while the rendered bitmaps trundle in. What made me start this project at all was Emacs-21' ability to directly place EPS files into its buffer. Within one week, I had code ready that would place display formulas in the buffer. Even before the first regular release, this approach had to be scrapped, and still is (the historic code is still in and you can enable it, but it probably has suffered bit rot by
Re: preview-LyX ?
On Tue, May 14, 2002 at 01:25:09PM +0200, David Kastrup wrote: > > (d) cursor inside an inset, inset rendered as plain LaTeX source. > > Actually, (d) is "Evil Red Text" IIRC, and so the code for it should > mostly exist already. Not exactly. ERT within math is converted to "proper math" if recoqnized as something known. There is normally no way to keep "\int" as a sequence of four characters. (d) would allow us to do that. > 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 GhostScript, and one would want > to group requests as much as possible. I see. So there _is_ a performance problem. > LaTeX startup time can be considerably reduced by dumping formats (the > CVS version of preview-latex uses Carlisle's mylatex.ltx for that > purpose). The ultimate goal would be to keep one pipe running. DviPS > cannot really be made to fit into that scheme, one would probably want to > ultimately replace it with a DVI to bitmap rendering daemon. GhostScript > could probably be kept running efficiently across multiple DviPS runs > if you did clever resource management (do not download already present > fonts and other stuff etc). But that's all future stuff to think about. Do you think you (or somebody else for that matter) will do that kind of work? "Soonish"? > > I'd basically need a _fast_ way to get some rendered bitmap out of a > > string like $a^2+b^2$. That's it. The "obvious" solution would be to > > create some temp.tex, run LaTeX on it, convert the dvi. I don't know > > how 'fast' this is, though. > > If you start with a pregenerated format, surprisingly so. But you want > to have this work asynchronously: editing should not block actively while > the rendered bitmaps trundle in. Sure we could just keep a list of "insets to be rendered" in a background process and as soon as one is finished, we cache this in the LyX inset and display it when needed (i.e. when the next redraw request comes) instead of doing our "homegrown rendering". > [...] The problem was that Emacs rendered on-demand. Scroll to a page > with 20 previews on them, and Emacs started 20 GhostScript processes and > would block until most of them were finished placing their bitmaps right > into the window. Doing that without blocking should be possible in LyX... > This is quite 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 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. Jefferson)
Re: preview-LyX ?
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 perfect for the requirements you describe. And yes, it is used by the graphics code. Angus
Re: preview-LyX ?
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 when that process finishes. I think that it'd be perfect for the
> requirements you describe. And yes, it is used by the graphics code.
Somewhat more would be required for feeding the GhostScript process.
Here is an pseudoextract from a fake session:
gs -q -dSAFER -dDELAYSAFER -dNOPAUSE -DNOPLATFONTS -dTextAlphaBits\=4
-dGraphicsAlphaBits\=4 -sDEVICE\=png16m -r135.992x144.924
GS>/preview-latex-do{setpagedevice save gsave 0.705882 0.93 0.705882 setrgbcolor
false setstrokeadjust 3.0 setlinewidth clippath strokepath matrix setmatrix true { 2
index { newpath } if round exch round exch moveto pop false } { round exch round exch
lineto } { curveto } { closepath } pathforall pop fill grestore exch[count 2 roll]exch
cvx systemdict/.runandhide known revision 700 ge and{.setsafe{.runandhide}}if
stopped{handleerror quit}if count 1 ne{quit}if aload pop restore}bind def
(/home/dak/src/preview/_region_.prv/tmp1327ZQd/preview.ps)(r)file dup dup 0
setfileposition 17994()/SubFileDecode filter cvx exec dup dup 17994 setfileposition
85()/SubFileDecode filter cvx <>preview-latex-do
(in case it does not survive in the mail, all of the above behind the
prompt is a single command). That's the initial command fed to
GhostScript (contains a lot of complications for the sake of adding a
coloured border with non-antialiased edges around the image in order
to make a nice cursor display) for the first image. More images of
the same run would then look just like the last part:
GS<1>dup dup 17994 setfileposition 85()/SubFileDecode filter cvx <>preview-latex-do
This selects the source portion in the (already open) PostScript file
for the next scrap to be rendered, sets up the dimensions of the
graphics and the file name to produce, and does the next graphic.
So one has to react to GhostScript producing a prompt, then feed it
the next item (actually, the next few: we allow for a few outstanding
requests in order not to let GhostScript idle unnecessarily). It's
not just termination that is interesting, but there is an ongoing
communication.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: preview-LyX ?
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 > > GhostScript, and one would want to group requests as much as > > possible. > > I see. So there _is_ a performance problem. It is called Jan-Åke. He has a 150Mhz computer or so. At the current point of time, preview-latex is working convincingly for him, but this has not always been that way. Historically, DviPS was called with options -i -E in order to generate one EPS file per image. Generating the stuff separately took time, passing it through GhostScript (which reloaded fonts and reinitialized sections all the time) took time. EPS was necessary because of bounding boxes. We now get the bounding box info from directly from TeX. This necessitated quite a few changes in preview.sty: previously it was fine with outputting horizontal material in a \vbox as a full line: DviPS determined the bounding box just by looking at actually typeset material. Cropping the boxes to sensible dimensions from TeX requires quite a bit of wizardry with \lastbox, \vsplit and the like. Since we now have the bounding box info available separately, we don't need no stinking EPS, but just a single fat PS file. Its preamble is just passed once through GhostScript, then the separate pages are passed in display optimized order through. This necessitates some basic parsing of the DSC comments, like PostScript previewers do. By now one could probably make some of the reprocessing automatic. > > LaTeX startup time can be considerably reduced by dumping formats > > (the CVS version of preview-latex uses Carlisle's mylatex.ltx for > > that purpose). The ultimate goal would be to keep one pipe > > running. DviPS cannot really be made to fit into that scheme, one > > would probably want to ultimately replace it with a DVI to bitmap > > rendering daemon. GhostScript could probably be kept running > > efficiently across multiple DviPS runs if you did clever resource > > management (do not download already present fonts and other stuff > > etc). But that's all future stuff to think about. > > Do you think you (or somebody else for that matter) will do that > kind of work? "Soonish"? There is the GPLed DVIlib2 library rendering DVI directly to bitmaps. That would be just the thing to use. Unfortunately, in some experiments I did it appeared to be slower than the DviPS/GhostScript combo. It also had some other problems (like not wanting to render above the 0in coordinate even if I told it the paper was supposed to start above there). I have not received replies to some requests to the author, and have not pursued this matter further. If people were willing to invest serious work into it, this would probably be the technically soundest implementation path in the long term. There is a dvi2bitmap program under a noncommercial license (which is not really good enough for me to want to make my GPLed code rely on it), and there is presumably some free dvi2gif that could be slaughtered for its innards (the latter info I just recently got from Yannis Haralambous). It might also be an idea to take a look at a few DVI previewers (traditionally fast renderers of bitmaps) and see whether one could rip code from them. But the DviPS/GhostScript path is a good start and should probably be retained at least as an option for things like PStricks graphics. > > > I'd basically need a _fast_ way to get some rendered bitmap out of a > > > string like $a^2+b^2$. That's it. The "obvious" solution would be to > > > create some temp.tex, run LaTeX on it, convert the dvi. I don't know > > > how 'fast' this is, though. > > > > If you start with a pregenerated format, surprisingly so. But you want > > to have this work asynchronously: editing should not block actively while > > the rendered bitmaps trundle in. > > Sure we could just keep a list of "insets to be rendered" in a > background process and as soon as one is finished, we cache this in the LyX > inset and display it when needed (i.e. when the next redraw request comes) > instead of doing our "homegrown rendering". Good. > > [...] The problem was that Emacs rendered on-demand. Scroll to a page > > with 20 previews on them, and Emacs started 20 GhostScript processes and > > would block until most of them were finished placing their bitmaps right > > into the window. > > Doing that without blocking should be possible in LyX... Don't ever think of starting 20 GhostScript processes simultaneously for 20 previews. It's sinful. > > This is quite 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.
Re: preview-LyX ?
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 class that executes a fork-ed process and emits a > > signal when that process finishes. I think that it'd be perfect for the > > requirements you describe. And yes, it is used by the graphics code. > > Somewhat more would be required for feeding the GhostScript process. > Here is an pseudoextract from a fake session: What you describe is conceptually similar to spellchecking and we can spellcheck in LyX ;-) (I mean that we're communicating interactively with an external program, ispell or gs.) LyX's spellchecker code communicates with ispell via pipes. How do you communicate with gs? Angus
Re: preview-LyX ?
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 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 perfect for the > > > requirements you describe. And yes, it is used by the graphics code. > > > > Somewhat more would be required for feeding the GhostScript process. > > Here is an pseudoextract from a fake session: > > What you describe is conceptually similar to spellchecking and we > can spellcheck in LyX ;-) (I mean that we're communicating > interactively with an external program, ispell or gs.) > > LyX's spellchecker code communicates with ispell via pipes. How do you > communicate with gs? Pipes. So it seems like all of the technical infrastructure necessary to let LyX manage the data flow for generating inline previews as well as preview-latex does would already be present. Uh, wait: it should support fast display of bitmap files in a format that GhostScript can produce. But I would guess this would not prove really much of an issue? Just hope that not too many _users_ are reading the developer lists, or they may come banging at your doors asking you to do what appears doable after all... -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: preview-LyX ?
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 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 perfect for > > > > the requirements you describe. And yes, it is used by the graphics > > > > code. > > > > > > Somewhat more would be required for feeding the GhostScript process. > > > Here is an pseudoextract from a fake session: > > > > What you describe is conceptually similar to spellchecking and we > > can spellcheck in LyX ;-) (I mean that we're communicating > > interactively with an external program, ispell or gs.) > > > > LyX's spellchecker code communicates with ispell via pipes. How do you > > communicate with gs? > > Pipes. So it seems like all of the technical infrastructure necessary > to let LyX manage the data flow for generating inline previews as well > as preview-latex does would already be present. Uh, wait: it should > support fast display of bitmap files in a format that GhostScript can > produce. But I would guess this would not prove really much of an > issue? 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, so slowness doesn't block the user. You may have heard that one of the immediate goals that we have set ourselves is to support multiple GUI toolkits cleanly. We currently use the xforms library to load graphics files. Its image loading routines do not (currently) load PNG files, so we'd have to follow the (slow) conversion route. (Xforms can load, directly and quickly, BMP, GIF, JPEG, PNM, TIF, XBM, XPM bitmap formats). Fortunately xforms is now LGPL-ed and modifiable, so native loading of PNG is an achievable target. Moreover, one of the main goals of 1.3 is to finish the Qt port; that would use Qt's image loading routines which I understand are pretty good. So yes, it looks like progress is possible. > Just hope that not too many _users_ are reading the developer lists, > or they may come banging at your doors asking you to do what appears > doable after all... 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
Re: preview-LyX ?
> > 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
Re: preview-LyX ?
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, so > slowness doesn't block the user. > > You may have heard that one of the immediate goals that we have set > ourselves is to support multiple GUI toolkits cleanly. We currently > use the xforms library to load graphics files. Its image loading > routines do not (currently) load PNG files, so we'd have to follow > the (slow) conversion route. (Xforms can load, directly and > quickly, BMP, GIF, JPEG, PNM, TIF, XBM, XPM bitmap formats). PNG is simply chosen because it is a fast truecolor format turning out very compact for typical typeset stuff. It is a nobrainer to let GhostScript produce other image formats. Probably some TIF format would fit the bill. > Fortunately xforms is now LGPL-ed and modifiable, so native loading > of PNG is an achievable target. Would be a good idea, anyhow. libpng should make this reasonably easy. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
