Re: Updating NEWS for 1.2.0
On Mon, Jul 23, 2001 at 12:10:40PM +0200, Jean-Marc Lasgouttes wrote: I have begun to update NEWS for version 1.2.0. Appended is my first attempt. I do know that things are missing, but I am sure you will be able to point them out. Corrections to my faulty english and complete rewrites are welcome too. Few minor new features: - Search in the citation dialog. - Bookmarks - Cycle between a label and its references. - Preliminary support for multiple citations. - Option to disable babel when using the default language. - floats, footnotes and margin notes are now real insets Maybe mention that it is now possible to put footnotes inside tables (we still have the problem of what to do in that case).
Re: Updating NEWS for 1.2.0
On Mon, Jul 23, 2001 at 02:00:43PM +0200, Jean-Marc Lasgouttes wrote: The math editor has been mostly rewritten (and thus may have many new bugs :). Most of the changes should not be visible for the user, except: - enable switching between equation/eqnarray and align environment Replace the above by - Support for the amsmath align environment. Also, add the following - Changing math font of a selection.
Re: Updating NEWS for 1.2.0
Am Mittwoch, 25. Juli 2001 18:08 schrieb Herbert Voss: Dekel Maybe mention that it is now possible to put footnotes inside Dekel tables (we still have the problem of what to do in that case). We should probably think more about this feature before announcing it. yes, because footnotes in table-floats make no sense! and where shall they appear? under the table, inside a float? on the bottom of the page, like others? ... I think Dekel is talking about footnotes in tables _outside_ floats here. We have discussed this some days ago. LaTeX inserts a footnote number but no footnote in this case, but with two lines in the preamble, the footnote text appears at the bottom of the page. You're right: Floats and Footnotes together make no sense, but why not having a footnote in a fixed table? Jürgen Herbert
Re: Updating NEWS for 1.2.0
Jürgen Spitzmüller wrote: yes, because footnotes in table-floats make no sense! and where shall they appear? under the table, inside a float? on the bottom of the page, like others? ... I think Dekel is talking about footnotes in tables _outside_ floats here. We have discussed this some days ago. LaTeX inserts a footnote number but no footnote in this case, but with two lines in the preamble, the footnote text appears at the bottom of the page. You're right: Floats and Footnotes together make no sense, but why not having a footnote in a fixed table? ok! Herbert -- http://www.educat.hu-berlin.de/~voss/lyx/
Re: Updating NEWS for 1.2.0
On Wed, 25 Jul 2001, Herbert Voss wrote: yes, because footnotes in table-floats make no sense! and where shall they appear? under the table, inside a float? on the bottom of the page, like others? ... I disagree somewhat strongly - footnotes to table-floats (or endnotes as they are more properly called) are used all the time (in astronomical journals, at least), and they appear under the table, inside the float :-) The AASTeX package (for which I created a LyX layout) actually defines \tablenotemark and \tablenotetext commands to deal with this in a sane fashion. I expect LyX could create a similar functionality. Mike -- Mike Ressler [EMAIL PROTECTED] OK, I'm lame: I don't have my own website ...
Re: Updating NEWS for 1.2.0
Am Mittwoch, 25. Juli 2001 18:44 schrieb Mike Ressler: I disagree somewhat strongly - footnotes to table-floats (or endnotes as they are more properly called) are used all the time (in astronomical journals, at least), and they appear under the table, inside the float :-) The AASTeX package (for which I created a LyX layout) actually defines \tablenotemark and \tablenotetext commands to deal with this in a sane fashion. I expect LyX could create a similar functionality. Isn't the best way to get this behaviour inserting the table inside a minipage, now that there is this new minipage support? I think that's the way it is done in the LaTeX world. But I think LyX should only allow footnotes in table- (and graphic-)*floats* when a minipage is used and this is surely something which has to be documented (so I guess I'm speaking to the right person ;-) Greets, Jürgen Mike
Re: Updating NEWS for 1.2.0
On Wed, 25 Jul 2001, [iso-8859-1] Jürgen Spitzmüller wrote: Am Mittwoch, 25. Juli 2001 18:44 schrieb Mike Ressler: I disagree somewhat strongly - footnotes to table-floats (or endnotes as they are more properly called) are used all the time (in ... Isn't the best way to get this behaviour inserting the table inside a minipage, now that there is this new minipage support? I think that's the way it is done in the LaTeX world. But I think LyX should only allow footnotes in table- (and graphic-)*floats* when a minipage is used and this is surely something which has to be documented (so I guess I'm speaking to the right person ;-) Ouch! Beautiful touché! :-) Your minipage suggestion is indeed correct (though AASTeX uses some funky \parbox magic). I can live with minipages, though it would be cool if LyX would do this automatically with a table endnote layout or something. Mike -- Mike Ressler [EMAIL PROTECTED] OK, I'm lame: I don't have my own website ...
Re: Updating NEWS for 1.2.0
On Wed, Jul 25, 2001 at 06:11:05PM +0200, Jean-Marc Lasgouttes wrote: Dekel == Dekel Tsur [EMAIL PROTECTED] writes: You mean multiple bibliographies? Dekel Yes. Perhaps it should be noted that when using bibtopic, the Dekel 'dot' option should be used. This belongs to the docs. Would it be possible for the parsing mechanism to work with and without the 'dot' option? This way people could do just as they want. We already discussed this: LyX doesn't support the default naming scheme of bibtopic since it might lead to confusion when the user has filename.lyx and filename2.lyx, and he doesn't use tempdir. If you think that the above situation is rare enough, it is easy to support the default naming scheme (with or without the dot naming scheme). But is it that hard to use the dot option ?
Re: Updating NEWS for 1.2.0
On Mon, Jul 23, 2001 at 12:10:40PM +0200, Jean-Marc Lasgouttes wrote: > > I have begun to update NEWS for version 1.2.0. Appended is my first > attempt. I do know that things are missing, but I am sure you will be > able to point them out. Corrections to my faulty english and complete > rewrites are welcome too. Few minor new features: - Search in the citation dialog. - Bookmarks - Cycle between a label and its references. - Preliminary support for multiple citations. - Option to disable babel when using the default language. > - floats, footnotes and margin notes are now real insets Maybe mention that it is now possible to put footnotes inside tables (we still have the problem of what to do in that case).
Re: Updating NEWS for 1.2.0
On Mon, Jul 23, 2001 at 02:00:43PM +0200, Jean-Marc Lasgouttes wrote: > The math editor has been mostly rewritten (and thus may have many new > bugs :). Most of the changes should not be visible for the user, > except: > - enable switching between equation/eqnarray and align environment Replace the above by - Support for the amsmath align environment. Also, add the following - Changing math font of a selection.
Re: Updating NEWS for 1.2.0
Am Mittwoch, 25. Juli 2001 18:08 schrieb Herbert Voss: > > Dekel> Maybe mention that it is now possible to put footnotes > > inside Dekel> tables (we still have the problem of what to do in > > that case). > > > > We should probably think more about this feature before announcing > > it. > > yes, because footnotes in table-floats make no sense! > and where shall they appear? under the table, inside a float? > on the bottom of the page, like others? ... I think Dekel is talking about footnotes in tables _outside_ floats here. We have discussed this some days ago. LaTeX inserts a footnote number but no footnote in this case, but with two lines in the preamble, the footnote text appears at the bottom of the page. You're right: Floats and Footnotes together make no sense, but why not having a footnote in a fixed table? Jürgen > Herbert
Re: Updating NEWS for 1.2.0
Jürgen Spitzmüller wrote: > > > yes, because footnotes in table-floats make no sense! > > and where shall they appear? under the table, inside a float? > > on the bottom of the page, like others? ... > > I think Dekel is talking about footnotes in tables _outside_ floats > here. We have discussed this some days ago. LaTeX inserts a footnote > number but no footnote in this case, but with two lines in the > preamble, the footnote text appears at the bottom of the page. > You're right: Floats and Footnotes together make no sense, but why not > having a footnote in a fixed table? ok! Herbert -- http://www.educat.hu-berlin.de/~voss/lyx/
Re: Updating NEWS for 1.2.0
On Wed, 25 Jul 2001, Herbert Voss wrote: > yes, because footnotes in table-floats make no sense! > and where shall they appear? under the table, inside a float? > on the bottom of the page, like others? ... I disagree somewhat strongly - footnotes to table-floats (or endnotes as they are more properly called) are used all the time (in astronomical journals, at least), and they appear under the table, inside the float :-) The AASTeX package (for which I created a LyX layout) actually defines \tablenotemark and \tablenotetext commands to deal with this in a sane fashion. I expect LyX could create a similar functionality. Mike -- Mike Ressler [EMAIL PROTECTED] OK, I'm lame: I don't have my own website ...
Re: Updating NEWS for 1.2.0
Am Mittwoch, 25. Juli 2001 18:44 schrieb Mike Ressler: > I disagree somewhat strongly - footnotes to table-floats (or endnotes > as they are more properly called) are used all the time (in > astronomical journals, at least), and they appear under the table, > inside the float :-) The AASTeX package (for which I created a LyX > layout) actually defines \tablenotemark and \tablenotetext commands > to deal with this in a sane fashion. I expect LyX could create a > similar functionality. Isn't the best way to get this behaviour inserting the table inside a minipage, now that there is this new minipage support? I think that's the way it is done in the LaTeX world. But I think LyX should only allow footnotes in table- (and graphic-)*floats* when a minipage is used and this is surely something which has to be documented (so I guess I'm speaking to the right person ;-) Greets, Jürgen > Mike
Re: Updating NEWS for 1.2.0
On Wed, 25 Jul 2001, [iso-8859-1] Jürgen Spitzmüller wrote: > Am Mittwoch, 25. Juli 2001 18:44 schrieb Mike Ressler: > > I disagree somewhat strongly - footnotes to table-floats (or endnotes > > as they are more properly called) are used all the time (in > ... > > Isn't the best way to get this behaviour inserting the table inside a > minipage, now that there is this new minipage support? > I think that's the way it is done in the LaTeX world. > But I think LyX should only allow footnotes in table- (and > graphic-)*floats* when a minipage is used and this is surely something > which has to be documented (so I guess I'm speaking to the right person > ;-) Ouch! Beautiful touché! :-) Your minipage suggestion is indeed correct (though AASTeX uses some funky \parbox magic). I can live with minipages, though it would be cool if LyX would do this automatically with a "table endnote" layout or something. Mike -- Mike Ressler [EMAIL PROTECTED] OK, I'm lame: I don't have my own website ...
Re: Updating NEWS for 1.2.0
On Wed, Jul 25, 2001 at 06:11:05PM +0200, Jean-Marc Lasgouttes wrote: > > "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes: > > >> You mean multiple bibliographies? > > Dekel> Yes. Perhaps it should be noted that when using bibtopic, the > Dekel> 'dot' option should be used. > > This belongs to the docs. Would it be possible for the parsing > mechanism to work with and without the 'dot' option? This way people > could do just as they want. We already discussed this: LyX doesn't support the default naming scheme of bibtopic since it might lead to confusion when the user has filename.lyx and filename2.lyx, and he doesn't use tempdir. If you think that the above situation is rare enough, it is easy to support the default naming scheme (with or without the dot naming scheme). But is it that hard to use the dot option ?
Re: Updating NEWS for 1.2.0
On Mon, Jul 23, 2001 at 12:10:40PM +0200, Jean-Marc Lasgouttes wrote: - TeX mode has been superseded by the 666 (aka ERT) inset, which is foldable or is it collapsable ? I would prefer foldable as the user term for this indeed, I just want to mamake sure we're consistent in the docs etc. john -- Voodoo Programming: Things programmers do that they know shouldn't work but they try anyway, and which sometimes actually work, such as recompiling everything. - Karl Lehenbauer
Re: Updating NEWS for 1.2.0
On Mon, Jul 23, 2001 at 08:20:45AM -0400, Baruch Even wrote: Question is actually, do we mind not being able to resize/dither for 1.2.0 For me it doesn't matter, but this isn't WYSIWYM and is a step backwards from the current inset. think screen shots. I don't want them taking up more than a Lyx WorkArea ! the figure float doesn't resize *itself* anyway now, so it's basically unusable (try it on platypus.eps)
Re: Updating NEWS for 1.2.0
On 23-Jul-2001 John Levon wrote: the figure float doesn't resize *itself* anyway now, so it's basically unusable (try it on platypus.eps) Should it? I made this types of insets only be wider than the WorkArea if the include inset is wider otherwise they are always the width of the workarea. That now the inset is not redrawn and that the dimension are not correct this is due to the problem I descirbed on friday! Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Never test for an error condition you don't know how to handle. -- Steinbach
Re: Updating NEWS for 1.2.0
On Mon, 23 Jul 2001, John Levon wrote: On Mon, Jul 23, 2001 at 08:20:45AM -0400, Baruch Even wrote: Question is actually, do we mind not being able to resize/dither for 1.2.0 For me it doesn't matter, but this isn't WYSIWYM and is a step backwards from the current inset. think screen shots. I don't want them taking up more than a Lyx WorkArea ! In figinset if you specify the image to be 5cm x 5cm it will be resized so it will be that size on screen (or at least it attempts to do it thusly). What you want is similar to dither, to keep it on the screen small enough but to print it regularly on paper. That's a feature request :-) I need to deal with the basic resizing first and then it can be added easily. Baruch
Re: Updating NEWS for 1.2.0
On Mon, Jul 23, 2001 at 08:47:07AM -0400, Baruch Even wrote: Could you write a few lines on the advantages of insetgraphics wrt figinset? Basically, cleaner code. It has no reall addition in it compared to figinset, but it stops using ghostscript for preview which was a problem when you did some menu action, you lost the preview images generated at the time. so your code is the biggest workaround for an xforms bug ever ? /me runs john -- Voodoo Programming: Things programmers do that they know shouldn't work but they try anyway, and which sometimes actually work, such as recompiling everything. - Karl Lehenbauer
Re: Updating NEWS for 1.2.0
On Mon, 23 Jul 2001, John Levon wrote: On Mon, Jul 23, 2001 at 08:47:07AM -0400, Baruch Even wrote: Could you write a few lines on the advantages of insetgraphics wrt figinset? Basically, cleaner code. It has no reall addition in it compared to figinset, but it stops using ghostscript for preview which was a problem when you did some menu action, you lost the preview images generated at the time. so your code is the biggest workaround for an xforms bug ever ? Yup :-) And a cleanup of a convoluted code that had everything in it, the latex handling, dialog and image manipulation. /me runs It won't matter, I can't get to you anyhow... Baruch
Re: Updating NEWS for 1.2.0
On Mon, Jul 23, 2001 at 08:47:07AM -0400, Baruch Even wrote: On 23 Jul 2001, Jean-Marc Lasgouttes wrote: Baruch == Baruch Even [EMAIL PROTECTED] writes: Baruch On 23 Jul 2001, Jean-Marc Lasgouttes wrote: - new graphics inset superseding the older figure inset [will that be OK in 1.2.0?] Baruch The graphics inset as it is now is a bit backwards from the Baruch old figinset, specifically it will not resize or dither the Baruch image, but load it as it is. It will load the image in the Baruch inline preview though. Could you write a few lines on the advantages of insetgraphics wrt figinset? Basically, cleaner code. It has no reall addition in it compared to figinset, but it stops using ghostscript for preview which was a problem when you did some menu action, you lost the preview images generated at the time. There are several problem with the preview code in graphics inset: 1) It doesn't work. I get Need converter from eps to xpm message. Even if I define such a converter, it doesn't work. 2) I really don't like the idea to use convert to create an xpm file. Why not use pipes ? (namely run 'convert graphics-file xpm:-' ) 3) The image conversions should be done in thread, so it won't affect the time for opening a document.
Re: Updating NEWS for 1.2.0
On Mon, 23 Jul 2001, Dekel Tsur wrote: There are several problem with the preview code in graphics inset: 1) It doesn't work. I get Need converter from eps to xpm message. Even if I define such a converter, it doesn't work. I think there should be such converters defined automatically, I belive I commited my code to update the libs/configure, will recheck when I get back home. I'm using ImageMagick and it worked, will test it. 2) I really don't like the idea to use convert to create an xpm file. Why not use pipes ? (namely run 'convert graphics-file xpm:-' ) Basically because I use XpmReadFileToPixmap to get the XPixmap, I don't know how to make it load the data from the pipe. I can probably create a pipe file and use that but I've never done such things, a guiding hand or a reference example would help. We had the discussion a long time ago, there is no real reason to avoid it when you use a dumb image loader like XForms have, too much trouble. I intend to add additional loaders that will use better graphical libraries (like gdk-pixbuf or imlib2) and these will do most of this on their own. The reason for not doing it right now is to support those users who cannot install a good supporting library. The simplest route could be to require everyone to install gdk-pixbuf (and thus gdk and glib) and have the image library do it all for us, resizing, rotationg, dithering and all in the background. 3) The image conversions should be done in thread, so it won't affect the time for opening a document. I want to do it this way, but it is not so trivial, the execution code in support doesnt work asynchronously, and I'm not sure if Converter can be used in a thread. We have no protection on the data structures from several changes. Can I be sure that the Converter data structures are read-only when I load the document? I believe I asked Lars about this at the time, can we add dependency on libpthread? This will solve my problem by adding mutexes and using threads. Otherwise I'll need to get back to my asynchronous process running code that I started work on and abandoned when the complexity soared. A partial solution could be to have two code paths for when there is libpthread and for thwne there isn't but this is a maintenance nightmare. Baruch
Re: Updating NEWS for 1.2.0
On Mon, Jul 23, 2001 at 09:55:23AM -0400, Baruch Even wrote: 2) I really don't like the idea to use convert to create an xpm file. Why not use pipes ? (namely run 'convert graphics-file xpm:-' ) Basically because I use XpmReadFileToPixmap to get the XPixmap, I don't know how to make it load the data from the pipe. I can probably create a pipe file and use that but I've never done such things, a guiding hand or a reference example would help. So read from the pipe to a memory buffer, and then use XpmCreatePixmapFromBuffer. The reason for not doing it right now is to support those users who cannot install a good supporting library. The simplest route could be to require everyone to install gdk-pixbuf (and thus gdk and glib) and have the image library do it all for us, resizing, rotationg, dithering and all in the background. What about using libmagick ? 3) The image conversions should be done in thread, so it won't affect the time for opening a document. I want to do it this way, but it is not so trivial, the execution code in support doesnt work asynchronously, and I'm not sure if Converter can be used in a thread. The converter data structure can change by the preferences dialog. However, you don't really need to use the converter code for image conversion. Most image conversions are just one call to convert...
Re: Updating NEWS for 1.2.0
* Dekel Tsur [EMAIL PROTECTED] [010723 17:28]: There are several problem with the preview code in graphics inset: 1) It doesn't work. I get Need converter from eps to xpm message. Even if I define such a converter, it doesn't work. Fixed. I'll commit this soon. It was a mistake of mine when I reordered the code to be easier to change to synchronous mode. -- Baruch Even http://baruch.ev-en.org/
Re: Updating NEWS for 1.2.0
* Dekel Tsur [EMAIL PROTECTED] [010723 19:06]: On Mon, Jul 23, 2001 at 09:55:23AM -0400, Baruch Even wrote: The reason for not doing it right now is to support those users who cannot install a good supporting library. The simplest route could be to require everyone to install gdk-pixbuf (and thus gdk and glib) and have the image library do it all for us, resizing, rotationg, dithering and all in the background. What about using libmagick ? That too, but I remember an e-mail from someone who doesn't have ImageMagick installed and so libmagick is not a standard lib. I would be very happy if it's possible to add another dependency to LyX and solve this mess by having a good standard requirement, but the general tendency is against this. 3) The image conversions should be done in thread, so it won't affect the time for opening a document. I want to do it this way, but it is not so trivial, the execution code in support doesnt work asynchronously, and I'm not sure if Converter can be used in a thread. The converter data structure can change by the preferences dialog. However, you don't really need to use the converter code for image conversion. Most image conversions are just one call to convert... I cannot depend on ImageMagick, I need the configurability of Converter. I can however create a limited version of that that can do a single conversion only. That will pretty much go into ImageTransformer but then the user will need to configure that too, but I guess usually users dont need image formats in their Converter configs it will be just another keyword. -- Baruch Even http://baruch.ev-en.org/
Re: Updating NEWS for 1.2.0
On Mon, Jul 23, 2001 at 07:19:05PM +0300, Baruch Even wrote: * Dekel Tsur [EMAIL PROTECTED] [010723 19:06]: On Mon, Jul 23, 2001 at 09:55:23AM -0400, Baruch Even wrote: The reason for not doing it right now is to support those users who cannot install a good supporting library. The simplest route could be to require everyone to install gdk-pixbuf (and thus gdk and glib) and have the image library do it all for us, resizing, rotationg, dithering and all in the background. What about using libmagick ? That too, but I remember an e-mail from someone who doesn't have ImageMagick installed and so libmagick is not a standard lib. But the current code does require to have imagemagick (or something equivalent) to be installed in order to have image previewing. You can always use an image library (libmagick,imlib, etc.) if it is present, and otherwise use an external program.
Re: Updating NEWS for 1.2.0
Jean-Marc Lasgouttes wrote: Baruch == Baruch Even [EMAIL PROTECTED] writes: Baruch I cannot depend on ImageMagick, I need the configurability of Baruch Converter. netpbm comes to mind, but I do not know whether it is still maintained. JMarc This just in, so I suppose so. NETPBM 9.16 [ NOT RATED ] Description: A whole bunch of utilities for converting from one graphics format to another. For example, from g3 fax format to gif. Also, some rudimentary graphics editing tools such as magnifying and cropping. This is a successor to Jef Poskanzer's PBMPlus package, and gathers converters by many people from many places. See: http://www.icewalk.com/softlib/app/app_00039.html Garst
Re: Updating NEWS for 1.2.0
* Dekel Tsur [EMAIL PROTECTED] [010723 20:43]: But the current code does require to have imagemagick (or something equivalent) to be installed in order to have image previewing. You can always use an image library (libmagick,imlib, etc.) if it is present, and otherwise use an external program. I do require some image transformation program, and ghsotscript by itself will not do anymore, so it is an added dependency, but I still need to support the case when there is no library installed only some program to do the work. The libraries are a compile time dependency, the programs are a run time dependency. Netpbm doesn't have a corresponding library so I'll still need to provide some interface to that, and there might be other programs. As I said, I currently try to create the lowest common support and then to build up from there for those who do have the libraries. -- Baruch Even http://baruch.ev-en.org/
Re: Updating NEWS for 1.2.0
On Mon, Jul 23, 2001 at 12:10:40PM +0200, Jean-Marc Lasgouttes wrote: > - TeX mode has been superseded by the 666 (aka ERT) inset, which is > foldable or is it collapsable ? I would prefer "foldable" as the user term for this indeed, I just want to mamake sure we're consistent in the docs etc. john -- "Voodoo Programming: Things programmers do that they know shouldn't work but they try anyway, and which sometimes actually work, such as recompiling everything." - Karl Lehenbauer
Re: Updating NEWS for 1.2.0
On Mon, Jul 23, 2001 at 08:20:45AM -0400, Baruch Even wrote: > Question is actually, do we mind not being able to resize/dither for 1.2.0 > For me it doesn't matter, but this isn't WYSIWYM and is a step backwards > from the current inset. think screen shots. I don't want them taking up more than a Lyx WorkArea ! the figure float doesn't resize *itself* anyway now, so it's basically unusable (try it on platypus.eps)
Re: Updating NEWS for 1.2.0
On 23-Jul-2001 John Levon wrote: > the figure float doesn't resize *itself* anyway now, so it's basically unusable > (try it on platypus.eps) Should it? I made this types of insets only be wider than the WorkArea if the include inset is wider otherwise they are always the width of the workarea. That now the inset is not redrawn and that the dimension are not correct this is due to the problem I descirbed on friday! Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Never test for an error condition you don't know how to handle. -- Steinbach
Re: Updating NEWS for 1.2.0
On Mon, 23 Jul 2001, John Levon wrote: > On Mon, Jul 23, 2001 at 08:20:45AM -0400, Baruch Even wrote: > > > Question is actually, do we mind not being able to resize/dither for 1.2.0 > > For me it doesn't matter, but this isn't WYSIWYM and is a step backwards > > from the current inset. > > think screen shots. I don't want them taking up more than a Lyx WorkArea ! In figinset if you specify the image to be 5cm x 5cm it will be resized so it will be that size on screen (or at least it attempts to do it thusly). What you want is similar to dither, to keep it on the screen small enough but to print it regularly on paper. That's a feature request :-) I need to deal with the basic resizing first and then it can be added easily. Baruch
Re: Updating NEWS for 1.2.0
On Mon, Jul 23, 2001 at 08:47:07AM -0400, Baruch Even wrote: > > Could you write a few lines on the advantages of insetgraphics wrt > > figinset? > > Basically, cleaner code. It has no reall addition in it compared to > figinset, but it stops using ghostscript for preview which was a problem > when you did some menu action, you lost the preview images generated at > the time. so your code is the biggest workaround for an xforms bug ever ? /me runs john -- "Voodoo Programming: Things programmers do that they know shouldn't work but they try anyway, and which sometimes actually work, such as recompiling everything." - Karl Lehenbauer
Re: Updating NEWS for 1.2.0
On Mon, 23 Jul 2001, John Levon wrote: > On Mon, Jul 23, 2001 at 08:47:07AM -0400, Baruch Even wrote: > > > > Could you write a few lines on the advantages of insetgraphics wrt > > > figinset? > > > > Basically, cleaner code. It has no reall addition in it compared to > > figinset, but it stops using ghostscript for preview which was a problem > > when you did some menu action, you lost the preview images generated at > > the time. > > so your code is the biggest workaround for an xforms bug ever ? Yup :-) And a cleanup of a convoluted code that had everything in it, the latex handling, dialog and image manipulation. > /me runs It won't matter, I can't get to you anyhow... Baruch
Re: Updating NEWS for 1.2.0
On Mon, Jul 23, 2001 at 08:47:07AM -0400, Baruch Even wrote: > On 23 Jul 2001, Jean-Marc Lasgouttes wrote: > > > > "Baruch" == Baruch Even <[EMAIL PROTECTED]> writes: > > > > Baruch> On 23 Jul 2001, Jean-Marc Lasgouttes wrote: > > >> - new graphics inset superseding the older figure inset [will that > > >> be OK in 1.2.0?] > > > > Baruch> The graphics inset as it is now is a bit backwards from the > > Baruch> old figinset, specifically it will not resize or dither the > > Baruch> image, but load it as it is. It will load the image in the > > Baruch> inline preview though. > > > > Could you write a few lines on the advantages of insetgraphics wrt > > figinset? > > Basically, cleaner code. It has no reall addition in it compared to > figinset, but it stops using ghostscript for preview which was a problem > when you did some menu action, you lost the preview images generated at > the time. There are several problem with the preview code in graphics inset: 1) It doesn't work. I get "Need converter from eps to xpm" message. Even if I define such a converter, it doesn't work. 2) I really don't like the idea to use convert to create an xpm file. Why not use pipes ? (namely run 'convert xpm:-' ) 3) The image conversions should be done in thread, so it won't affect the time for opening a document.
Re: Updating NEWS for 1.2.0
On Mon, 23 Jul 2001, Dekel Tsur wrote: > There are several problem with the preview code in graphics inset: > > 1) It doesn't work. I get "Need converter from eps to xpm" message. > Even if I define such a converter, it doesn't work. I think there should be such converters defined automatically, I belive I commited my code to update the libs/configure, will recheck when I get back home. I'm using ImageMagick and it worked, will test it. > 2) I really don't like the idea to use convert to create an xpm file. > Why not use pipes ? (namely run 'convert xpm:-' ) Basically because I use XpmReadFileToPixmap to get the XPixmap, I don't know how to make it load the data from the pipe. I can probably create a pipe "file" and use that but I've never done such things, a guiding hand or a reference example would help. We had the discussion a long time ago, there is no real reason to avoid it when you use a dumb image loader like XForms have, too much trouble. I intend to add additional loaders that will use better graphical libraries (like gdk-pixbuf or imlib2) and these will do most of this on their own. The reason for not doing it right now is to support those users who cannot install a good supporting library. The simplest route could be to require everyone to install gdk-pixbuf (and thus gdk and glib) and have the image library do it all for us, resizing, rotationg, dithering and all in the background. > 3) The image conversions should be done in thread, so it won't affect the > time for opening a document. I want to do it this way, but it is not so trivial, the execution code in support doesnt work asynchronously, and I'm not sure if Converter can be used in a thread. We have no protection on the data structures from several changes. Can I be sure that the Converter data structures are read-only when I load the document? I believe I asked Lars about this at the time, can we add dependency on libpthread? This will solve my problem by adding mutexes and using threads. Otherwise I'll need to get back to my asynchronous process running code that I started work on and abandoned when the complexity soared. A partial solution could be to have two code paths for when there is libpthread and for thwne there isn't but this is a maintenance nightmare. Baruch
Re: Updating NEWS for 1.2.0
On Mon, Jul 23, 2001 at 09:55:23AM -0400, Baruch Even wrote: > > 2) I really don't like the idea to use convert to create an xpm file. > > Why not use pipes ? (namely run 'convert xpm:-' ) > > Basically because I use XpmReadFileToPixmap to get the XPixmap, I don't > know how to make it load the data from the pipe. I can probably create a > pipe "file" and use that but I've never done such things, a guiding hand > or a reference example would help. So read from the pipe to a memory buffer, and then use XpmCreatePixmapFromBuffer. > The reason for not doing it right now is to support those users who cannot > install a good supporting library. The simplest route could be to require > everyone to install gdk-pixbuf (and thus gdk and glib) and have the image > library do it all for us, resizing, rotationg, dithering and all in the > background. What about using libmagick ? > > 3) The image conversions should be done in thread, so it won't affect the > > time for opening a document. > > I want to do it this way, but it is not so trivial, the execution code in > support doesnt work asynchronously, and I'm not sure if Converter can be > used in a thread. The converter data structure can change by the preferences dialog. However, you don't really need to use the converter code for image conversion. Most image conversions are just one call to convert...
Re: Updating NEWS for 1.2.0
* Dekel Tsur <[EMAIL PROTECTED]> [010723 17:28]: > There are several problem with the preview code in graphics inset: > > 1) It doesn't work. I get "Need converter from eps to xpm" message. > Even if I define such a converter, it doesn't work. Fixed. I'll commit this soon. It was a mistake of mine when I reordered the code to be easier to change to synchronous mode. -- Baruch Even http://baruch.ev-en.org/
Re: Updating NEWS for 1.2.0
* Dekel Tsur <[EMAIL PROTECTED]> [010723 19:06]: > On Mon, Jul 23, 2001 at 09:55:23AM -0400, Baruch Even wrote: > > The reason for not doing it right now is to support those users who cannot > > install a good supporting library. The simplest route could be to require > > everyone to install gdk-pixbuf (and thus gdk and glib) and have the image > > library do it all for us, resizing, rotationg, dithering and all in the > > background. > > What about using libmagick ? That too, but I remember an e-mail from someone who doesn't have ImageMagick installed and so libmagick is not a standard lib. I would be very happy if it's possible to add another dependency to LyX and solve this mess by having a good standard requirement, but the general tendency is against this. > > > 3) The image conversions should be done in thread, so it won't affect the > > > time for opening a document. > > > > I want to do it this way, but it is not so trivial, the execution code in > > support doesnt work asynchronously, and I'm not sure if Converter can be > > used in a thread. > > The converter data structure can change by the preferences dialog. > However, you don't really need to use the converter code for image conversion. > Most image conversions are just one call to convert... I cannot depend on ImageMagick, I need the configurability of Converter. I can however create a limited version of that that can do a single conversion only. That will pretty much go into ImageTransformer but then the user will need to configure that too, but I guess usually users dont need image formats in their Converter configs it will be just another keyword. -- Baruch Even http://baruch.ev-en.org/
Re: Updating NEWS for 1.2.0
On Mon, Jul 23, 2001 at 07:19:05PM +0300, Baruch Even wrote: > * Dekel Tsur <[EMAIL PROTECTED]> [010723 19:06]: > > On Mon, Jul 23, 2001 at 09:55:23AM -0400, Baruch Even wrote: > > > The reason for not doing it right now is to support those users who cannot > > > install a good supporting library. The simplest route could be to require > > > everyone to install gdk-pixbuf (and thus gdk and glib) and have the image > > > library do it all for us, resizing, rotationg, dithering and all in the > > > background. > > > > What about using libmagick ? > > That too, but I remember an e-mail from someone who doesn't have > ImageMagick installed and so libmagick is not a standard lib. But the current code does require to have imagemagick (or something equivalent) to be installed in order to have image previewing. You can always use an image library (libmagick,imlib, etc.) if it is present, and otherwise use an external program.
Re: Updating NEWS for 1.2.0
Jean-Marc Lasgouttes wrote: > > > "Baruch" == Baruch Even <[EMAIL PROTECTED]> writes: > > Baruch> I cannot depend on ImageMagick, I need the configurability of > Baruch> Converter. > > netpbm comes to mind, but I do not know whether it is still > maintained. > > JMarc This just in, so I suppose so. NETPBM 9.16 [ NOT RATED ] Description: A whole bunch of utilities for converting from one graphics format to another. For example, from g3 fax format to gif. Also, some rudimentary graphics editing tools such as magnifying and cropping. This is a successor to Jef Poskanzer's PBMPlus package, and gathers converters by many people from many places. See: http://www.icewalk.com/softlib/app/app_00039.html Garst
Re: Updating NEWS for 1.2.0
* Dekel Tsur <[EMAIL PROTECTED]> [010723 20:43]: > But the current code does require to have imagemagick (or something > equivalent) to be installed in order to have image previewing. > > You can always use an image library (libmagick,imlib, etc.) if it is > present, and otherwise use an external program. I do require some image transformation program, and ghsotscript by itself will not do anymore, so it is an added dependency, but I still need to support the case when there is no library installed only some program to do the work. The libraries are a compile time dependency, the programs are a run time dependency. Netpbm doesn't have a corresponding library so I'll still need to provide some interface to that, and there might be other programs. As I said, I currently try to create the lowest common support and then to build up from there for those who do have the libraries. -- Baruch Even http://baruch.ev-en.org/
