RE: Give insets a full Row
On 11-Apr-2002 Juergen Vigna wrote: The attached small patch changes LyX's behaviour for NeedFullRow insets in that it does give them ALWAYS the full row for drawing and does not care if there is some indent or depth. IMO this is correct and should be done, also this fixes a few problems we have and makes things easier to handle. Comments!? Hmm, I did not get any complaints so I will commit this patch later this morning. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Machines take me by surprise with great frequency. - Alan Turing
Re: Give insets a full Row
Juergen Vigna [EMAIL PROTECTED] writes: | The attached small patch changes LyX's behaviour for NeedFullRow insets in | that it does give them ALWAYS the full row for drawing and does not care if | there is some indent or depth. IMO this is correct and should be done, also | this fixes a few problems we have and makes things easier to handle. What problems? What things? | + Inset * ins; | + if ((row-par()-getChar(row-pos()) == Paragraph::META_INSET) | + (ins=row-par()-getInset(row-pos())) | + (ins-needFullRow() || ins-display())) | + return LYX_PAPER_MARGIN; | + Should probably be in a function of its own. -- Lgb
Re: Give insets a full Row
Juergen Vigna [EMAIL PROTECTED] writes: | On 11-Apr-2002 Juergen Vigna wrote: The attached small patch changes LyX's behaviour for NeedFullRow insets in that it does give them ALWAYS the full row for drawing and does not care if there is some indent or depth. IMO this is correct and should be done, also this fixes a few problems we have and makes things easier to handle. Comments!? | Hmm, I did not get any complaints so I will commit this patch later this | morning. What bugnumber does this fix? -- Lgb
Re: Give insets a full Row
On Fri, Apr 12, 2002 at 10:31:15AM +0200, Lars Gullik Bjønnes wrote: | + Inset * ins; | + if ((row-par()-getChar(row-pos()) == Paragraph::META_INSET) | + (ins=row-par()-getInset(row-pos())) | + (ins-needFullRow() || ins-display())) | + return LYX_PAPER_MARGIN; | + Should probably be in a function of its own. And since every term uses row-(...) it probably should be a function of the row... 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: Give insets a full Row
Juergen == Juergen Vigna [EMAIL PROTECTED] writes: Juergen The attached small patch changes LyX's behaviour for Juergen NeedFullRow insets in that it does give them ALWAYS the full Juergen row for drawing and does not care if there is some indent or Juergen depth. IMO this is correct and should be done, also this Juergen fixes a few problems we have and makes things easier to Juergen handle. If you are giving the whole window width, it means that the depth markers in left margin will be overwritten. This is not nice. JMarc
Re: Give insets a full Row
Juergen == Juergen Vigna [EMAIL PROTECTED] writes: Juergen On 11-Apr-2002 Juergen Vigna wrote: The attached small patch changes LyX's behaviour for NeedFullRow insets in that it does give them ALWAYS the full row for drawing and does not care if there is some indent or depth. IMO this is correct and should be done, also this fixes a few problems we have and makes things easier to handle. Comments!? Juergen Hmm, I did not get any complaints so I will commit this patch Juergen later this morning. Huh? I just posted my own complaint one minute ago... JMarc
Re: Give insets a full Row
On 12-Apr-2002 Lars Gullik Bjønnes wrote: | + Inset * ins; | + if ((row-par()-getChar(row-pos()) == Paragraph::META_INSET) | + (ins=row-par()-getInset(row-pos())) | + (ins-needFullRow() || ins-display())) | + return LYX_PAPER_MARGIN; | + Should probably be in a function of its own. Yes I already thought about that. Should it be an inlined function? | Hmm, I did not get any complaints so I will commit this patch later this | morning. What bugnumber does this fix? Well in general we have problems with getting the right width of an inset when we have indent as paragraph spacing and also when we have paragraph which are in a deeper depth. Also this are insets which use more space as they also contain more paragraphs and so IMO when editing them we should give them more space. You surely saw in the commitlog official bug this fixes but IMO this fixes also bugs which are not on the list, but which bugged me since quite a time. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ QOTD: I haven't come far enough, and don't call me baby.
Re: Graphics: file loading problems
On Friday 12 April 2002 5:23 am, R. Lahaye wrote:
Hi,
I have attached a tar file that contains an example lyx-file
and a graphics file, that hopefully demonstrate the problem.
Please start LyX-CVS from beginning (don't use an already
running LyX) and open the attached GraphicsTest.lyx, which
has figures/MyGraph.jpg as a graphics-float inset.
All you need to do is: View-DVI, which will generate an error.
See the attached png files for my LyX-canvas and the LaTeX-Error
window.
(sorry for all attachments, don't know howelse to show this).
Can you reproduce this error?
If so, please notice that in the process LyX generates a file
figures/MyGraph.eps. This shouldn't happen, should it?
But since we now have that eps file there, please open next
the graphics dialog and change the filename to the eps file.
All of a sudden View-DVI works fine!
There is something wrong here with non-(e)ps files.
Am I the only one experiencing this?
Regards,
Rob.
No, Rob, you aren't the only one experiencing this. It will be fixed before
1.2 comes out. we're currently trying to do it right as opposed to hack a
solution.
The hack is to modify insetgraphics.C, so:
string const InsetGraphics::prepareFile(Buffer const *buf) const
{
...
//
// if it's a zipped one, than let LaTeX do the rest!!!
- string filename_ = params().filename;
+ string filename_ = MakeAbsPath(params().filename, buf-filePath());
bool const zipped = zippedFile(filename_);
That should at least enable you to do some work.
Regards,
Angus
Re: Give insets a full Row
On 12-Apr-2002 Jean-Marc Lasgouttes wrote: Juergen == Juergen Vigna [EMAIL PROTECTED] writes: Juergen The attached small patch changes LyX's behaviour for Juergen NeedFullRow insets in that it does give them ALWAYS the full Juergen row for drawing and does not care if there is some indent or Juergen depth. IMO this is correct and should be done, also this Juergen fixes a few problems we have and makes things easier to Juergen handle. If you are giving the whole window width, it means that the depth markers in left margin will be overwritten. This is not nice. You may be right but we overwirte it only if the depth 5, should I add code anyway to put it more to the right? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ The man who sees, on New Year's day, Mount Fuji, a hawk, and an eggplant is forever blessed. -- Old Japanese proverb
Re: Give insets a full Row
On 12-Apr-2002 Jean-Marc Lasgouttes wrote: Juergen Hmm, I did not get any complaints so I will commit this patch Juergen later this morning. Huh? I just posted my own complaint one minute ago... Well I did not get it until now so! Anyway if you think this is wrong we can always revert it it's really small (just a few lines in the start of LeftMargin and RightMargin!). Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 go to a doctor whose office plants have died. -- Erma Bombeck
Re: Graphics: file loading problems
Angus Leeming wrote: No, Rob, you aren't the only one experiencing this. It will be fixed before 1.2 comes out. we're currently trying to do it right as opposed to hack a solution. One point of serious concern is that LyX apparently is dumping and removing(!!) the corresponding eps files in/from the user's working directory, instead of doing these things in the LyX's-tmp directory. I have been already a few times confused, when corresponding eps-files, generated by me manually, all of a sudden were gone when I was using their GRACE counterparts in LyX; until I realized that LyX was actually deleting them on the fly. Dangerous! Well, that's the risk of using CVS :). Cheers, Rob.
Re: Graphics: file loading problems
On Friday 12 April 2002 9:55 am, R. Lahaye wrote: Angus Leeming wrote: No, Rob, you aren't the only one experiencing this. It will be fixed before 1.2 comes out. we're currently trying to do it right as opposed to hack a solution. One point of serious concern is that LyX apparently is dumping and removing(!!) the corresponding eps files in/from the user's working directory, instead of doing these things in the LyX's-tmp directory. I have been already a few times confused, when corresponding eps-files, generated by me manually, all of a sudden were gone when I was using their GRACE counterparts in LyX; until I realized that LyX was actually deleting them on the fly. Dangerous! Well, that's the risk of using CVS :). Cheers, Rob. Just for my information, what are the current bugs associated with the graphics inset. I know about: * LaTeX is unable to find the generated eps file if the original non-eps file lies in a directory deeper than the document. * If LyX loads a graphics some_path/graphics.ext, it will place the generated eps file at some_path/graphics.eps. This will overwrite any eps file of the same name. I think Herbert has cured all the other bugs ;-) Feel free to add to this list. Angus
Re: Graphics: file loading problems
R == R Lahaye [EMAIL PROTECTED] writes: R Hi, R I have attached a tar file that contains an example lyx-file and a R graphics file, that hopefully demonstrate the problem. I think the following patch addresses the issue. Rob, Herbert, could you please test it and tell me whether it works? JMarc Index: src/insets/ChangeLog === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/ChangeLog,v retrieving revision 1.386 diff -u -p -r1.386 ChangeLog --- src/insets/ChangeLog 11 Apr 2002 18:40:59 - 1.386 +++ src/insets/ChangeLog 12 Apr 2002 09:04:03 - @@ -1,7 +1,12 @@ +2002-04-12 Jean-Marc Lasgouttes [EMAIL PROTECTED] + + * insetgraphics.C (prepareFile): fix bug when graphics is a + relative path + 2002-04-08 Herbert Voss [EMAIL PROTECTED] - * insetgraphic.C (write): write the rotating angle as - a float as is. test only for != 0.0 + * insetgraphic.C (write): write the rotating angle as + a float as is. test only for != 0.0 2002-04-11 Juergen Vigna [EMAIL PROTECTED] Index: src/insets/insetgraphics.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetgraphics.C,v retrieving revision 1.103 diff -u -p -r1.103 insetgraphics.C --- src/insets/insetgraphics.C 8 Apr 2002 17:26:33 - 1.103 +++ src/insets/insetgraphics.C 12 Apr 2002 09:04:04 - @@ -635,7 +635,7 @@ string const InsetGraphics::prepareFile( return filename_; } - string const temp = AddName(buf-tmppath, filename_); + string const temp = MakeAbsPath(filename_, buf-tmppath); string const outfile_base = RemoveExtension(temp); lyxerr[Debug::GRAPHICS] tempname = temp \n; @@ -644,7 +644,7 @@ string const InsetGraphics::prepareFile( lyxerr[Debug::GRAPHICS] outfile_base = outfile_base endl; converters.convert(buf, filename_, outfile_base, from, to); - return outfile_base; + return RemoveExtension(filename_); }
Re: Bug in graphics rotation (Was: Cant rotate by 270 degrees)
Angus wrote. In other words I can not get a 270 degree rotation no matter how the figure was recently rotated. Claus Why the hell are the output images affected? I _really_ don't believe you there. Well it _really_ happens :-). I just noticed that I got this error message on the terminal when failing to rotate by 270 (or -90) degrees: In RotateMatrix [image_rotate.c 239] InternalError: bad special angle Claus
Re: Bug in graphics rotation (Was: Cant rotate by 270 degrees)
On Friday 12 April 2002 10:46 am, Claus Hindsgaul wrote: Angus wrote. In other words I can not get a 270 degree rotation no matter how the figure was recently rotated. Claus Why the hell are the output images affected? I _really_ don't believe you there. Well it _really_ happens :-). I just noticed that I got this error message on the terminal when failing to rotate by 270 (or -90) degrees: In RotateMatrix [image_rotate.c 239] InternalError: bad special angle Claus Sure, you can't rotate the image on the LyX screen by 270 degs, but the latex output is correct. At least, it is here. Please tell me if you can't rotate the LaTeX output image by 270 degs. == As for the image on the LyX screen, well you have two options: 1. rotate by 270.1 degs ;-) 2. patch the open source version of the xforms library with the patch I posted a day or so ago. See: http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg36385.html Apparently it works fine. Angus
Re: Give insets a full Row
Juergen == Juergen Vigna [EMAIL PROTECTED] writes: Juergen On 12-Apr-2002 Jean-Marc Lasgouttes wrote: Juergen Hmm, I did not get any complaints so I will commit this patch Juergen later this morning. Huh? I just posted my own complaint one minute ago... Juergen Well I did not get it until now so! Anyway if you think this Juergen is wrong we can always revert it it's really small (just a Juergen few lines in the start of LeftMargin and RightMargin!). It seems my mail is very slow today... JMarc
Re: Bug in graphics rotation (Was: Cant rotate by 270 degrees)
fre, 2002-04-12 kl. 12:01 skrev Angus Leeming: Please tell me if you can't rotate the LaTeX output image by 270 degs. == The LaTeX-output is fine, so this is only a display problem after all - and obviously known and being fixed. Thanks. Claus
FW: Graphics: file loading problems
Since my e-mail seems to arrive very slowly, let's try to post this one in a different way. People, please try this patch. -Original Message- From: Jean-Marc Lasgouttes [mailto:[EMAIL PROTECTED]] Sent: vendredi 12 avril 2002 12:05 To: [EMAIL PROTECTED] Subject: Re: Graphics: file loading problems R == R Lahaye [EMAIL PROTECTED] writes: R Hi, R I have attached a tar file that contains an example lyx-file and a R graphics file, that hopefully demonstrate the problem. I think the following patch addresses the issue. Rob, Herbert, could you please test it and tell me whether it works? JMarc Index: src/insets/ChangeLog === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/ChangeLog,v retrieving revision 1.386 diff -u -p -r1.386 ChangeLog --- src/insets/ChangeLog 11 Apr 2002 18:40:59 - 1.386 +++ src/insets/ChangeLog 12 Apr 2002 09:04:03 - @@ -1,7 +1,12 @@ +2002-04-12 Jean-Marc Lasgouttes [EMAIL PROTECTED] + + * insetgraphics.C (prepareFile): fix bug when graphics is a + relative path + 2002-04-08 Herbert Voss [EMAIL PROTECTED] - * insetgraphic.C (write): write the rotating angle as - a float as is. test only for != 0.0 + * insetgraphic.C (write): write the rotating angle as + a float as is. test only for != 0.0 2002-04-11 Juergen Vigna [EMAIL PROTECTED] Index: src/insets/insetgraphics.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetgraphics.C,v retrieving revision 1.103 diff -u -p -r1.103 insetgraphics.C --- src/insets/insetgraphics.C 8 Apr 2002 17:26:33 - 1.103 +++ src/insets/insetgraphics.C 12 Apr 2002 09:04:04 - @@ -635,7 +635,7 @@ string const InsetGraphics::prepareFile( return filename_; } - string const temp = AddName(buf-tmppath, filename_); + string const temp = MakeAbsPath(filename_, buf-tmppath); string const outfile_base = RemoveExtension(temp); lyxerr[Debug::GRAPHICS] tempname = temp \n; @@ -644,7 +644,7 @@ string const InsetGraphics::prepareFile( lyxerr[Debug::GRAPHICS] outfile_base = outfile_base endl; converters.convert(buf, filename_, outfile_base, from, to); - return outfile_base; + return RemoveExtension(filename_); }
Re: Graphics: file loading problems
Jean-Marc Lasgouttes wrote: R == R Lahaye [EMAIL PROTECTED] writes: R Hi, R I have attached a tar file that contains an example lyx-file and a R graphics file, that hopefully demonstrate the problem. I think the following patch addresses the issue. Rob, Herbert, could you please test it and tell me whether it works? Works for me here! At least the problem is solved. Will see whether undesired side-effects pop up while continue working on my paperbut for me this can go into CVS. Thanks! Rob.
Re: Graphics: file loading problems
Angus Leeming wrote: Just for my information, what are the current bugs associated with the graphics inset. I know about: * LaTeX is unable to find the generated eps file if the original non-eps file lies in a directory deeper than the document. * If LyX loads a graphics some_path/graphics.ext, it will place the generated eps file at some_path/graphics.eps. This will overwrite any eps file of the same name. I think Herbert has cured all the other bugs ;-) Feel free to add to this list. 1) BUG: Bounding-box implementation on the LyX view is not consistent with the final DVI/Postscript output. Also, the use of the Top-right y-coordinate in the LyX View is bogus! Use 'clip to boundingbox' to check this. 2) WISH: Is it possible to make the file Pattern in the graphics file browser dynamical, so that it finds the file extensions of all convertable graphics format-extensions itself? Everytime I have to add agr to that list. Would be nice if the graphics-file-browser can find out itself about that, by using the Format/Conversion information from Preferences. 3) DIALOG-POLICY: When I do Insert-Graphics... and then immediatly click on the [Close] button, I'm left with a No image-square on my canvas. However, it would be better if such a nill-action would not affect the canvas at all. NB: Change [Close] into [Cancel] when implementing this behaviour. Actually this dialog-policy-violation also applies to BibTeX-database dialog Include-file dialog Edit-external-file dialog Regards, Rob.
Re: Graphics: file loading problems
On Friday 12 April 2002 11:30 am, R. Lahaye wrote: Angus Leeming wrote: Just for my information, what are the current bugs associated with the graphics inset. I know about: * LaTeX is unable to find the generated eps file if the original non-eps file lies in a directory deeper than the document. * If LyX loads a graphics some_path/graphics.ext, it will place the generated eps file at some_path/graphics.eps. This will overwrite any eps file of the same name. I think Herbert has cured all the other bugs ;-) Feel free to add to this list. 1) BUG: Bounding-box implementation on the LyX view is not consistent with the final DVI/Postscript output. Is this still the case? Is your Bounding Box consistent with the eps data, or have you modified it? eg, if the postscript points lie in the range -100 x 100 and you have modified the Bounding Box to 0 y1 100 y2, then the two are inconsistent. There's little we can do about this. Can you send me the offending image. Also, the use of the Top-right y-coordinate in the LyX View is bogus! Use 'clip to boundingbox' to check this. I suspect that this is the same as the above. With reasonable ps files all is fine. 2) WISH: Is it possible to make the file Pattern in the graphics file browser dynamical, so that it finds the file extensions of all convertable graphics format-extensions itself? Everytime I have to add agr to that list. Would be nice if the graphics-file-browser can find out itself about that, by using the Format/Conversion information from Preferences. 3) DIALOG-POLICY: When I do Insert-Graphics... and then immediatly click on the [Close] button, I'm left with a No image-square on my canvas. However, it would be better if such a nill-action would not affect the canvas at all. NB: Change [Close] into [Cancel] when implementing this behaviour. Actually this dialog-policy-violation also applies to BibTeX-database dialog Include-file dialog Edit-external-file dialog Regards, Rob. -- Dr Angus Leeming Dept. of Bioengineering Imperial College London SW7 2BX Tel +44 (0) 20 7594 5186 Fax +44 (0) 20 7584 6897
Web page tweaks
Hello, I did some work to separate the contrib stuff from the rest on the users site. The result can be seen here http://www.devel.lyx.org/~lasgouttes/www-user If it looks good to everyone, I'll commit it. ChangeLog entry is 2002-04-12[EMAIL PROTECTED] * navbar.inc: rename 'How to get it' to 'Download Links' * download/index.php3: remove contrib stuff comment out two invalid mirrors * download/contrib.php3: new page, split from the main page, and somewhat rearranged * download/start.php3: add link to contrib page JMarc
Re: Graphics: file loading problems
On Fri, 12 Apr 2002, Angus Leeming wrote: 1) BUG: Bounding-box implementation on the LyX view is not consistent with the final DVI/Postscript output. Is this still the case? Is your Bounding Box consistent with the eps data, or have you modified it? eg, if the postscript points lie in the range -100 x 100 and you have modified the Bounding Box to 0 y1 100 y2, then the two are inconsistent. There's little we can do about this. This also works, because we transform this bb-values to 100 y1 200 y2 of the corresponding xpm-file, which gives exactly the right view! means: All bounding boxes are viewed well in the lyx-window. Herbert
Re: Graphics: file loading problems
~On Fri, 12 Apr 2002, R. Lahaye wrote: 1) BUG: Bounding-box implementation on the LyX view is not consistent with the final DVI/Postscript output. Also, the use of the Top-right y-coordinate in the LyX View is bogus! Use 'clip to boundingbox' to check this. as Angus wrote, this cannot be with the latest cvs from yesterday evening. think so ... ;-) 2) WISH: Is it possible to make the file Pattern in the graphics file browser dynamical, so that it finds the file extensions of all convertable graphics format-extensions itself? Everytime I have to add agr to that list. Would be nice if the graphics-file-browser can find out itself about that, by using the Format/Conversion information from Preferences. makes sense and should be possible 3) DIALOG-POLICY: When I do Insert-Graphics... and then immediatly click on the [Close] button, I'm left with a No image-square on my canvas. However, it would be better if such a nill-action would not affect the canvas at all. NB: Change [Close] into [Cancel] when implementing this behaviour. Actually this dialog-policy-violation also applies to BibTeX-database dialog Include-file dialog Edit-external-file dialog yes, this is a bit annoying Herbert
Re: FW: Graphics: file loading problems
On Fri, 12 Apr 2002, Lasgouttes, J.M. wrote: I think the following patch addresses the issue. Rob, Herbert, could you please test it and tell me whether it works? at weekend, I have no lyx on this machine in my office. the other one is outer space ... did tonight an update to suse8.0 ... it was my 11th update with suse since 4.1 and my machine NEVER runs after an update Herbert
Re: FW: Graphics: file loading problems
On Fri, Apr 12, 2002 at 02:07:22PM +0200, Herbert Voss wrote: it was my 11th update with suse since 4.1 and my machine NEVER runs after an update Which should have taught you to backup /etc, and /home and install from scratch after the third time or so ;-) Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
possible bug...
Thinking about Herbert and Rob's list of loadable graphics formats, I
discover the following code:
string const findTargetFormat(string const from)
{
typedef GImage::FormatList FormatList;
FormatList const formats = GImage::loadableFormats();
Now GImage::loadableFormats() returns a FormatList, not a FormatList , so
why does this not die horribly?
Angus
Re: Graphics: file loading problems
On Friday 12 April 2002 1:04 pm, Herbert Voss wrote:
~On Fri, 12 Apr 2002, R. Lahaye wrote:
1) BUG:
Bounding-box implementation on the LyX view is not consistent with
the final DVI/Postscript output.
Also, the use of the Top-right y-coordinate in the LyX View is bogus!
Use 'clip to boundingbox' to check this.
as Angus wrote, this cannot be with the latest cvs from yesterday
evening. think so ... ;-)
2) WISH:
Is it possible to make the file Pattern in the graphics file browser
dynamical, so that it finds the file extensions of all convertable
graphics format-extensions itself? Everytime I have to add agr
to that list.
Would be nice if the graphics-file-browser can find out itself about
that, by using the Format/Conversion information from Preferences.
makes sense and should be possible
The clean solution is to :
1. Add a new method to the GraphicsCache
std::vectorstring loadableFormats() const
{
return GImage::loadableFormats();
}
(You need to create the method, because the GraphicsCache connects up the
appropriate signals, so you need to ensure that this has been done).
You can now access the list of formats loadable natively by the image loader
as
std::vectorstring native_formats = GCache::get().loadableFormats();
2. Loop over the list of all formats known to LyX and discover which ones can
be converted to one of these native formats. Something similar to
findTargetFormat in GrapgicsCacheItem.
Off the top of my head:
vectorstring native_formats = GCache::get().loadableFormats();
// We can load any format that can be loaded natively together with those
// that can be converted to one of these native formats.
vectorstring browsable_formats = native_formats;
grfx::GConverter const gconverter = grfx::GConverter::get();
vectorstring::const_iterator to_end = native_formats.end();
Formats::const_iterator from_it = formats.begin();
Formats::const_iterator from_end = formats.end();
for (; from_it != from_end; ++from_it) {
string const from = from_it-name();
vectorstring::const_iterator to_it = native_formats.begin();
for (; to_it != to_end; ++to_it) {
if (gconverter.isReachable(from, *to_it)) {
browsable_formats.push_back(from);
break;
}
}
}
That should give you a vector of all graphics formats loadable by LyX.
I'm sure someone, somewhere, will tell us to use the std algorithms, rather
than roll our own loops, but the above (or something close to it) should work.
Alternatively, why not just add agr to that string!
Angus
Re: possible bug...
Angus Leeming [EMAIL PROTECTED] writes:
| Thinking about Herbert and Rob's list of loadable graphics formats, I
| discover the following code:
| string const findTargetFormat(string const from)
| {
| typedef GImage::FormatList FormatList;
| FormatList const formats = GImage::loadableFormats();
| Now GImage::loadableFormats() returns a FormatList, not a FormatList , so
| why does this not die horribly?
The const perhaps.
--
Lgb
Re: [Devel] Another bug list!
On Sun, Apr 07, 2002 at 09:40:55AM +0200, Michael Schmitt wrote: - Create math formula; enter ^, ^, cursorleft,shift-cursorright; delete - Create math formula; enter ^, shift-cursorleft, delete - same procedure as above - Create math formula; enter ^, ^, shift-cursorright, shift-cursorright, shift-delete I can fix all of these by disabling a part of the 'remove empty scripts automatically' - mechanism. The problem is that it will be possible to create completely empty mathatoms (i.e empty base and neither sub- or superscript). I think this won't hurt much, but I am not completely sure. I'll commit anyway since this fixes all three cases and I can't get a crash anymore. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Bug: Clicking in a needfullrow inset actually selects
Open the attached document and click in the footnote. You get a selection. This is wrong... Same result with a displayed math equation. Juergen, is it your doing? JMarc newfile1.lyx Description: Binary data
Re: possible bug...
On Friday 12 April 2002 2:07 pm, Lars Gullik Bjønnes wrote:
Angus Leeming [EMAIL PROTECTED] writes:
| Thinking about Herbert and Rob's list of loadable graphics formats, I
| discover the following code:
|
| string const findTargetFormat(string const from)
| {
| typedef GImage::FormatList FormatList;
| FormatList const formats = GImage::loadableFormats();
|
| Now GImage::loadableFormats() returns a FormatList, not a FormatList ,
| so why does this not die horribly?
The const perhaps.
I take it you'd like me to make it more secure?
- FormatList const formats = GImage::loadableFormats();
+ FormatList const formats = GImage::loadableFormats();
Angus
Re: possible bug...
On Fri, Apr 12, 2002 at 03:00:11PM +0100, Angus Leeming wrote: The const perhaps. I take it you'd like me to make it more secure? - FormatList const formats = GImage::loadableFormats(); + FormatList const formats = GImage::loadableFormats(); By 12.2.5., the temporary object bound to the const reference should live as long as the reference in this case, i.e. the end of the block. But I am not completely sure about it, and if it is not a performance bottleneck, I'd create a copy there... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Mathed delimiters bug
When trying to use M-m [ or M-m (, I get respectively formulabase::LFUN_MATH_DELIM, arg: '[ ]' can't parse delimeters from '[ ]' formulabase::LFUN_MATH_DELIM, arg: '( )' can't parse delimeters from '( )' This can't be right. JMarc PS: and delimeters should be delimiters
[PATCH] Re: Graphics: file loading problems
Angus Leeming wrote:
I'm sure someone, somewhere, will tell us to use the std algorithms, rather
than roll our own loops, but the above (or something close to it) should work.
Alternatively, why not just add agr to that string!
here is the alternative:
Herbert
--
http://www.lyx.org/help/
Index: src/frontends/controllers/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/ChangeLog,v
retrieving revision 1.158
diff -u -r1.158 ChangeLog
--- src/frontends/controllers/ChangeLog 11 Apr 2002 17:40:44 - 1.158
+++ src/frontends/controllers/ChangeLog 12 Apr 2002 14:39:27 -
@@ -1,5 +1,9 @@
2002-04-11 Herbert Voss [EMAIL PROTECTED]
+ * ControlGraphics.C: expand browse-string to all available formats
+
+2002-04-11 Herbert Voss [EMAIL PROTECTED]
+
* ControlGraphics.C: read BoundingBox also from non (e)ps files.
2002-04-08 Adrien Rebollo [EMAIL PROTECTED]
Index: src/frontends/controllers/ControlGraphics.C
===
RCS file:
/usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/ControlGraphics.C,v
retrieving revision 1.32
diff -u -r1.32 ControlGraphics.C
--- src/frontends/controllers/ControlGraphics.C 11 Apr 2002 17:40:44 - 1.32
+++ src/frontends/controllers/ControlGraphics.C 12 Apr 2002 14:39:28 -
@@ -46,6 +46,18 @@
using std::pair;
using std::make_pair;
using std::ifstream;
+
+namespace {
+
+// FIXME: currently we need the second '|' to prevent mis-interpretation!
+// All supported graphic formats with their file-extension and the
+// gzip-ext for zipped (e)ps-files.
+string const grfx_pattern =
+ *.(agr|bmp|eps|epsi|fits|gif|jpg|obj|pdf|pbm|pgm|png|
+ ppm|ps|tif|tiff|xbm|xpm|xwd|gz)|;
+
+}
+
ControlGraphics::ControlGraphics(LyXView lv, Dialogs d)
: ControlInsetInsetGraphics, InsetGraphicsParams(lv, d)
@@ -90,8 +102,6 @@
string const ControlGraphics::Browse(string const in_name)
{
string const title = _(Select graphics file);
- // FIXME: currently we need the second '|' to prevent mis-interpretation
- string const pattern = *.(ps|eps|png|jpeg|jpg|gif|gz)|;
// Does user clipart directory exist?
string clipdir = AddName (user_lyxdir, clipart);
@@ -103,7 +113,7 @@
pairstring, string dir2(_(Documents|#o#O), string(lyxrc.document_path));
// Show the file browser dialog
return browseRelFile(lv_, in_name, lv_.buffer()-filePath(),
-title, pattern, dir1, dir2);
+title, ::grfx_pattern, dir1, dir2);
}
RE: Bug: Clicking in a needfullrow inset actually selects
On 12-Apr-2002 Jean-Marc Lasgouttes wrote: Open the attached document and click in the footnote. You get a selection. This is wrong... Same result with a displayed math equation. Juergen, is it your doing? Yes! I fixed it in my tree but I like a bit more testing before commiting so I probably commit this only on Monday! Have a nice Weekend! Ciao, 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ The most difficult thing in the world is to know how to do a thing and to watch someone else doing it wrong, without commenting. -- T.H. White
Re: Bug: Clicking in a needfullrow inset actually selects
Juergen Vigna [EMAIL PROTECTED] writes: | On 12-Apr-2002 Jean-Marc Lasgouttes wrote: Open the attached document and click in the footnote. You get a selection. This is wrong... Same result with a displayed math equation. Juergen, is it your doing? | Yes! I fixed it in my tree but I like a bit more testing before commiting | so I probably commit this only on Monday! If you have a chance, please commit as soon as possible, I'd really like to have a pre4 soon. -- Lgb
Re: Mathed delimiters bug
On Fri, Apr 12, 2002 at 04:18:52PM +0200, Jean-Marc Lasgouttes wrote: When trying to use M-m [ or M-m (, I get respectively formulabase::LFUN_MATH_DELIM, arg: '[ ]' can't parse delimeters from '[ ]' I see the first line, but not the second. And it inserts () and []. I just removed the spurious message. 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: small mathed annoyance
Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Jean-Marc Another problem. With the attachaed file, the macros do not Jean-Marc redisplay correctly when you do pageup/down. I have also Jean-Marc seen cases where the contents of the macro got drawn Jean-Marc outside of the purple box (I'll have to reproduce it). Another way to look at the same problem: open user guide, go to section 5.5 (macros) and move a bit the scrollbar when you have a macro definition visible. Then look how the macros redraw themselves ouside of their purple box... This is definitely annoying. JMarc
Re: Bug: Clicking in a needfullrow inset actually selects
On 12-Apr-2002 Lars Gullik Bjønnes wrote: | Yes! I fixed it in my tree but I like a bit more testing before commiting | so I probably commit this only on Monday! If you have a chance, please commit as soon as possible, I'd really like to have a pre4 soon. Well I commited what I had it should work, but I have to admit that I didn't test it very well. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ The greatest of faults is to be conscious of none.
Re: small mathed annoyance
On Fri, Apr 12, 2002 at 05:54:35PM +0200, Jean-Marc Lasgouttes wrote: This is definitely annoying. But easy to fix... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Math character bug in pre3
This bug was around a long time ago; I don't remember if it was fixed and got broken again, or if it was ignored and declared correct behavior. I use Alt-m g m m in text mode in 1.1.5fix2 all the time to make the micrometer abbreviation - in TeX it is $\mu$m. In 1.2.0pre3, the above sequence generates a math box with the greek letter mu, then leaves the cursor just of the left of the box and inserts the m before it - I get m$\mu$. If I am already in mathed, the Alt-m g m m works as expected: a mu followed by an m. Can this be fixed? Mike -- Mike Ressler [EMAIL PROTECTED] OK, I'm lame: I don't have my own website ...
Graphics: Bug in Alert window ?
Hi, While having trouble with the Graphics routine, I have deleted the EPS-XPM and PNG-XPM converters in Preferences in a trial to solve my problems. After that, LyX cannot anymore load my EPS file and pops up the Alert window which looks like in the attachment. The message-text area is transparent; only the [Dismiss]-button area has the proper grey background. Somehow, the failing conversion seems to disturb the Alert window's background. Is that possible? When I load a graphics file with totally unrelated format (e.g. a silly .txt file), the popped up Alert is sort of OK. Sort of OK: the message-text doesn't fit in the window! - Is this a bug in LyX (in Graphics, where the Alert is created?), or is this due to XForms 0.88.1 ? Regards, Rob.
Graphics: Waiting for draw request to start loading ?
Hi, A graphics picture in mode Don't display gets one of two messages in the graphics inset: Draw request to start loading... or Loaded but not displaying I find both messages typical info for developers, not relevant to the average LyX user. All the user needs to know is that the picture is in mode Don't display I recommend to replace both messages by Don't display. Then this message also equals the text in Graphics-LyX View-Screen display and in Preferences-LookFeel-Misc-Display Graphics. Regards, Rob.
RE: Give insets a full Row
On 11-Apr-2002 Juergen Vigna wrote: > The attached small patch changes LyX's behaviour for NeedFullRow insets in > that it does give them ALWAYS the full row for drawing and does not care if > there is some indent or depth. IMO this is correct and should be done, also > this fixes a few problems we have and makes things easier to handle. > > Comments!? Hmm, I did not get any complaints so I will commit this patch later this morning. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Machines take me by surprise with great frequency. - Alan Turing
Re: Give insets a full Row
Juergen Vigna <[EMAIL PROTECTED]> writes: | The attached small patch changes LyX's behaviour for NeedFullRow insets in | that it does give them ALWAYS the full row for drawing and does not care if | there is some indent or depth. IMO this is correct and should be done, also | this fixes a few problems we have and makes things easier to handle. What problems? What things? | + Inset * ins; | + if ((row->par()->getChar(row->pos()) == Paragraph::META_INSET) && | + (ins=row->par()->getInset(row->pos())) && | + (ins->needFullRow() || ins->display())) | + return LYX_PAPER_MARGIN; | + Should probably be in a function of its own. -- Lgb
Re: Give insets a full Row
Juergen Vigna <[EMAIL PROTECTED]> writes: | On 11-Apr-2002 Juergen Vigna wrote: >> The attached small patch changes LyX's behaviour for NeedFullRow insets in >> that it does give them ALWAYS the full row for drawing and does not care if >> there is some indent or depth. IMO this is correct and should be done, also >> this fixes a few problems we have and makes things easier to handle. >> >> Comments!? > | Hmm, I did not get any complaints so I will commit this patch later this | morning. What bugnumber does this fix? -- Lgb
Re: Give insets a full Row
On Fri, Apr 12, 2002 at 10:31:15AM +0200, Lars Gullik Bjønnes wrote: > | + Inset * ins; > | + if ((row->par()->getChar(row->pos()) == Paragraph::META_INSET) && > | + (ins=row->par()->getInset(row->pos())) && > | + (ins->needFullRow() || ins->display())) > | + return LYX_PAPER_MARGIN; > | + > > Should probably be in a function of its own. And since every term uses row->(...) it probably should be a function of the row... 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: Give insets a full Row
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes: Juergen> The attached small patch changes LyX's behaviour for Juergen> NeedFullRow insets in that it does give them ALWAYS the full Juergen> row for drawing and does not care if there is some indent or Juergen> depth. IMO this is correct and should be done, also this Juergen> fixes a few problems we have and makes things easier to Juergen> handle. If you are giving the whole window width, it means that the depth markers in left margin will be overwritten. This is not nice. JMarc
Re: Give insets a full Row
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes: Juergen> On 11-Apr-2002 Juergen Vigna wrote: >> The attached small patch changes LyX's behaviour for NeedFullRow >> insets in that it does give them ALWAYS the full row for drawing >> and does not care if there is some indent or depth. IMO this is >> correct and should be done, also this fixes a few problems we have >> and makes things easier to handle. >> >> Comments!? Juergen> Hmm, I did not get any complaints so I will commit this patch Juergen> later this morning. Huh? I just posted my own complaint one minute ago... JMarc
Re: Give insets a full Row
On 12-Apr-2002 Lars Gullik Bjønnes wrote: > | + Inset * ins; > | + if ((row->par()->getChar(row->pos()) == Paragraph::META_INSET) && > | + (ins=row->par()->getInset(row->pos())) && > | + (ins->needFullRow() || ins->display())) > | + return LYX_PAPER_MARGIN; > | + > > Should probably be in a function of its own. Yes I already thought about that. Should it be an inlined function? >| Hmm, I did not get any complaints so I will commit this patch later this >| morning. > > What bugnumber does this fix? Well in general we have problems with getting the right width of an inset when we have indent as paragraph spacing and also when we have paragraph which are in a deeper depth. Also this are insets which use more space as they also contain more paragraphs and so IMO when editing them we should give them more space. You surely saw in the commitlog official bug this fixes but IMO this fixes also bugs which are not on the list, but which bugged me since quite a time. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ QOTD: "I haven't come far enough, and don't call me baby."
Re: Graphics: file loading problems
On Friday 12 April 2002 5:23 am, R. Lahaye wrote:
> Hi,
>
> I have attached a tar file that contains an example lyx-file
> and a graphics file, that hopefully demonstrate the problem.
>
> Please start LyX-CVS from beginning (don't use an already
> running LyX) and open the attached GraphicsTest.lyx, which
> has "figures/MyGraph.jpg" as a graphics-float inset.
>
> All you need to do is: View->DVI, which will generate an error.
>
> See the attached png files for my LyX-canvas and the LaTeX-Error
> window.
> (sorry for all attachments, don't know howelse to show this).
>
> Can you reproduce this error?
> If so, please notice that in the process LyX generates a file
> "figures/MyGraph.eps". This shouldn't happen, should it?
>
> But since we now have that eps file there, please open next
> the graphics dialog and change the filename to the eps file.
> All of a sudden View->DVI works fine!
>
> There is something wrong here with non-(e)ps files.
>
> Am I the only one experiencing this?
>
> Regards,
> Rob.
No, Rob, you aren't the only one experiencing this. It will be fixed before
1.2 comes out. we're currently trying to do it "right" as opposed to hack a
solution.
The hack is to modify insetgraphics.C, so:
string const InsetGraphics::prepareFile(Buffer const *buf) const
{
...
//
// if it's a zipped one, than let LaTeX do the rest!!!
- string filename_ = params().filename;
+ string filename_ = MakeAbsPath(params().filename, buf->filePath());
bool const zipped = zippedFile(filename_);
That should at least enable you to do some work.
Regards,
Angus
Re: Give insets a full Row
On 12-Apr-2002 Jean-Marc Lasgouttes wrote: >> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes: > > Juergen> The attached small patch changes LyX's behaviour for > Juergen> NeedFullRow insets in that it does give them ALWAYS the full > Juergen> row for drawing and does not care if there is some indent or > Juergen> depth. IMO this is correct and should be done, also this > Juergen> fixes a few problems we have and makes things easier to > Juergen> handle. > > If you are giving the whole window width, it means that the depth > markers in left margin will be overwritten. This is not nice. You may be right but we overwirte it only if the depth > 5, should I add code anyway to put it more to the right? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ The man who sees, on New Year's day, Mount Fuji, a hawk, and an eggplant is forever blessed. -- Old Japanese proverb
Re: Give insets a full Row
On 12-Apr-2002 Jean-Marc Lasgouttes wrote: > Juergen> Hmm, I did not get any complaints so I will commit this patch > Juergen> later this morning. > > Huh? I just posted my own complaint one minute ago... Well I did not get it until now so! Anyway if you think this is wrong we can always revert it it's really small (just a few lines in the start of LeftMargin and RightMargin!). Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 go to a doctor whose office plants have died. -- Erma Bombeck
Re: Graphics: file loading problems
Angus Leeming wrote: > > No, Rob, you aren't the only one experiencing this. It will be fixed before > 1.2 comes out. we're currently trying to do it "right" as opposed to hack a > solution. One point of serious concern is that LyX apparently is dumping and removing(!!) the corresponding eps files in/from the user's working directory, instead of doing these things in the LyX's-tmp directory. I have been already a few times confused, when corresponding eps-files, generated by me manually, all of a sudden were gone when I was using their GRACE counterparts in LyX; until I realized that LyX was actually deleting them "on the fly". Dangerous! Well, that's the risk of using CVS :). Cheers, Rob.
Re: Graphics: file loading problems
On Friday 12 April 2002 9:55 am, R. Lahaye wrote: > Angus Leeming wrote: > > No, Rob, you aren't the only one experiencing this. It will be fixed > > before 1.2 comes out. we're currently trying to do it "right" as opposed > > to hack a solution. > > One point of serious concern is that LyX apparently is dumping and > removing(!!) the corresponding eps files in/from the user's working > directory, instead of doing these things in the LyX's-tmp directory. > > I have been already a few times confused, when corresponding eps-files, > generated by me manually, all of a sudden were gone when I was using > their GRACE counterparts in LyX; until I realized that LyX was actually > deleting them "on the fly". Dangerous! > > Well, that's the risk of using CVS :). > > Cheers, > Rob. Just for my information, what are the current bugs associated with the graphics inset. I know about: * LaTeX is unable to find the generated eps file if the original non-eps file lies in a directory deeper than the document. * If LyX loads a graphics some_path/graphics.ext, it will place the generated eps file at some_path/graphics.eps. This will overwrite any eps file of the same name. I think Herbert has cured all the other bugs ;-) Feel free to add to this list. Angus
Re: Graphics: file loading problems
> "R" == R Lahaye <[EMAIL PROTECTED]> writes: R> Hi, R> I have attached a tar file that contains an example lyx-file and a R> graphics file, that hopefully demonstrate the problem. I think the following patch addresses the issue. Rob, Herbert, could you please test it and tell me whether it works? JMarc Index: src/insets/ChangeLog === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/ChangeLog,v retrieving revision 1.386 diff -u -p -r1.386 ChangeLog --- src/insets/ChangeLog 11 Apr 2002 18:40:59 - 1.386 +++ src/insets/ChangeLog 12 Apr 2002 09:04:03 - @@ -1,7 +1,12 @@ +2002-04-12 Jean-Marc Lasgouttes <[EMAIL PROTECTED]> + + * insetgraphics.C (prepareFile): fix bug when graphics is a + relative path + 2002-04-08 Herbert Voss <[EMAIL PROTECTED]> - * insetgraphic.C (write): write the rotating angle as - a float as is. test only for != 0.0 + * insetgraphic.C (write): write the rotating angle as + a float as is. test only for != 0.0 2002-04-11 Juergen Vigna <[EMAIL PROTECTED]> Index: src/insets/insetgraphics.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetgraphics.C,v retrieving revision 1.103 diff -u -p -r1.103 insetgraphics.C --- src/insets/insetgraphics.C 8 Apr 2002 17:26:33 - 1.103 +++ src/insets/insetgraphics.C 12 Apr 2002 09:04:04 - @@ -635,7 +635,7 @@ string const InsetGraphics::prepareFile( return filename_; } - string const temp = AddName(buf->tmppath, filename_); + string const temp = MakeAbsPath(filename_, buf->tmppath); string const outfile_base = RemoveExtension(temp); lyxerr[Debug::GRAPHICS] << "tempname = " << temp << "\n"; @@ -644,7 +644,7 @@ string const InsetGraphics::prepareFile( lyxerr[Debug::GRAPHICS] << "outfile_base = " << outfile_base << endl; converters.convert(buf, filename_, outfile_base, from, to); - return outfile_base; + return RemoveExtension(filename_); }
Re: Bug in graphics rotation (Was: Cant rotate by 270 degrees)
Angus wrote. >> In other words I can not get a 270 degree rotation no matter how the >> figure was recently rotated. >> >> Claus > >Why the hell are the output images affected? I _really_ don't believe >you >there. Well it _really_ happens :-). I just noticed that I got this error message on the terminal when failing to rotate by 270 (or -90) degrees: In RotateMatrix [image_rotate.c 239] InternalError: bad special angle Claus
Re: Bug in graphics rotation (Was: Cant rotate by 270 degrees)
On Friday 12 April 2002 10:46 am, Claus Hindsgaul wrote: > Angus wrote. > > >> In other words I can not get a 270 degree rotation no matter how the > >> figure was recently rotated. > >> > >> Claus > > > >Why the hell are the output images affected? I _really_ don't believe > >you > >there. > > Well it _really_ happens :-). I just noticed that I got this error > message on the terminal when failing to rotate by 270 (or -90) degrees: > > In RotateMatrix [image_rotate.c 239] InternalError: bad special angle > > Claus Sure, you can't rotate the image on the LyX screen by 270 degs, but the latex output is correct. At least, it is here. Please tell me if you can't rotate the LaTeX output image by 270 degs. == As for the image on the LyX screen, well you have two options: 1. rotate by 270.1 degs ;-) 2. patch the open source version of the xforms library with the patch I posted a day or so ago. See: http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg36385.html Apparently it works fine. Angus
Re: Give insets a full Row
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes: Juergen> On 12-Apr-2002 Jean-Marc Lasgouttes wrote: Juergen> Hmm, I did not get any complaints so I will commit this patch Juergen> later this morning. >> Huh? I just posted my own complaint one minute ago... Juergen> Well I did not get it until now so! Anyway if you think this Juergen> is wrong we can always revert it it's really small (just a Juergen> few lines in the start of LeftMargin and RightMargin!). It seems my mail is very slow today... JMarc
Re: Bug in graphics rotation (Was: Cant rotate by 270 degrees)
fre, 2002-04-12 kl. 12:01 skrev Angus Leeming: > Please tell me if you can't rotate the LaTeX output image by 270 degs. > == The LaTeX-output is fine, so this is only a display problem after all - and obviously known and being fixed. Thanks. Claus
FW: Graphics: file loading problems
Since my e-mail seems to arrive very slowly, let's try to post this one in a different way. People, please try this patch. -Original Message- From: Jean-Marc Lasgouttes [mailto:[EMAIL PROTECTED]] Sent: vendredi 12 avril 2002 12:05 To: [EMAIL PROTECTED] Subject: Re: Graphics: file loading problems > "R" == R Lahaye <[EMAIL PROTECTED]> writes: R> Hi, R> I have attached a tar file that contains an example lyx-file and a R> graphics file, that hopefully demonstrate the problem. I think the following patch addresses the issue. Rob, Herbert, could you please test it and tell me whether it works? JMarc Index: src/insets/ChangeLog === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/ChangeLog,v retrieving revision 1.386 diff -u -p -r1.386 ChangeLog --- src/insets/ChangeLog 11 Apr 2002 18:40:59 - 1.386 +++ src/insets/ChangeLog 12 Apr 2002 09:04:03 - @@ -1,7 +1,12 @@ +2002-04-12 Jean-Marc Lasgouttes <[EMAIL PROTECTED]> + + * insetgraphics.C (prepareFile): fix bug when graphics is a + relative path + 2002-04-08 Herbert Voss <[EMAIL PROTECTED]> - * insetgraphic.C (write): write the rotating angle as - a float as is. test only for != 0.0 + * insetgraphic.C (write): write the rotating angle as + a float as is. test only for != 0.0 2002-04-11 Juergen Vigna <[EMAIL PROTECTED]> Index: src/insets/insetgraphics.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetgraphics.C,v retrieving revision 1.103 diff -u -p -r1.103 insetgraphics.C --- src/insets/insetgraphics.C 8 Apr 2002 17:26:33 - 1.103 +++ src/insets/insetgraphics.C 12 Apr 2002 09:04:04 - @@ -635,7 +635,7 @@ string const InsetGraphics::prepareFile( return filename_; } - string const temp = AddName(buf->tmppath, filename_); + string const temp = MakeAbsPath(filename_, buf->tmppath); string const outfile_base = RemoveExtension(temp); lyxerr[Debug::GRAPHICS] << "tempname = " << temp << "\n"; @@ -644,7 +644,7 @@ string const InsetGraphics::prepareFile( lyxerr[Debug::GRAPHICS] << "outfile_base = " << outfile_base << endl; converters.convert(buf, filename_, outfile_base, from, to); - return outfile_base; + return RemoveExtension(filename_); }
Re: Graphics: file loading problems
Jean-Marc Lasgouttes wrote: > > > "R" == R Lahaye <[EMAIL PROTECTED]> writes: > > R> Hi, > > R> I have attached a tar file that contains an example lyx-file and a > R> graphics file, that hopefully demonstrate the problem. > > I think the following patch addresses the issue. Rob, Herbert, could > you please test it and tell me whether it works? Works for me here! At least the problem is solved. Will see whether undesired side-effects pop up while continue working on my paperbut for me this can go into CVS. Thanks! Rob.
Re: Graphics: file loading problems
Angus Leeming wrote: > > Just for my information, what are the current bugs associated with the > graphics inset. I know about: > > * LaTeX is unable to find the generated eps file if the original non-eps file > lies in a directory deeper than the document. > > * If LyX loads a graphics some_path/graphics.ext, it will place the generated > eps file at some_path/graphics.eps. This will overwrite any eps file of the > same name. > > I think Herbert has cured all the other bugs ;-) > > Feel free to add to this list. 1) BUG: Bounding-box implementation on the LyX view is not consistent with the final DVI/Postscript output. Also, the use of the Top-right y-coordinate in the LyX View is bogus! Use 'clip to boundingbox' to check this. 2) WISH: Is it possible to make the file Pattern in the graphics file browser dynamical, so that it finds the file extensions of all convertable graphics format-extensions itself? Everytime I have to add "agr" to that list. Would be nice if the graphics-file-browser can find out itself about that, by using the Format/Conversion information from Preferences. 3) DIALOG-POLICY: When I do "Insert->Graphics..." and then immediatly click on the [Close] button, I'm left with a "No image"-square on my canvas. However, it would be better if such a "nill-action" would not affect the canvas at all. NB: Change [Close] into [Cancel] when implementing this behaviour. Actually this dialog-policy-violation also applies to BibTeX-database dialog Include-file dialog Edit-external-file dialog Regards, Rob.
Re: Graphics: file loading problems
On Friday 12 April 2002 11:30 am, R. Lahaye wrote: > Angus Leeming wrote: > > Just for my information, what are the current bugs associated with the > > graphics inset. I know about: > > > > * LaTeX is unable to find the generated eps file if the original non-eps > > file lies in a directory deeper than the document. > > > > * If LyX loads a graphics some_path/graphics.ext, it will place the > > generated eps file at some_path/graphics.eps. This will overwrite any eps > > file of the same name. > > > > I think Herbert has cured all the other bugs ;-) > > > > Feel free to add to this list. > > 1) BUG: >Bounding-box implementation on the LyX view is not consistent with >the final DVI/Postscript output. Is this still the case? Is your Bounding Box consistent with the eps data, or have you modified it? eg, if the postscript points lie in the range -100 < x < 100 and you have modified the Bounding Box to 0 y1 100 y2, then the two are inconsistent. There's little we can do about this. Can you send me the offending image. >Also, the use of the Top-right y-coordinate in the LyX View is bogus! >Use 'clip to boundingbox' to check this. I suspect that this is the same as the above. With "reasonable" ps files all is fine. > 2) WISH: >Is it possible to make the file Pattern in the graphics file browser >dynamical, so that it finds the file extensions of all convertable >graphics format-extensions itself? Everytime I have to add "agr" >to that list. >Would be nice if the graphics-file-browser can find out itself about >that, by using the Format/Conversion information from Preferences. > > > 3) DIALOG-POLICY: >When I do "Insert->Graphics..." and then immediatly click on the >[Close] button, I'm left with a "No image"-square on my canvas. >However, it would be better if such a "nill-action" would not >affect the canvas at all. >NB: Change [Close] into [Cancel] when implementing this behaviour. > > Actually this dialog-policy-violation also applies to >BibTeX-database dialog >Include-file dialog >Edit-external-file dialog > > > Regards, > Rob. -- Dr Angus Leeming Dept. of Bioengineering Imperial College London SW7 2BX Tel +44 (0) 20 7594 5186 Fax +44 (0) 20 7584 6897
Web page tweaks
Hello, I did some work to separate the contrib stuff from the rest on the users site. The result can be seen here http://www.devel.lyx.org/~lasgouttes/www-user If it looks good to everyone, I'll commit it. ChangeLog entry is 2002-04-12<[EMAIL PROTECTED]> * navbar.inc: rename 'How to get it' to 'Download Links' * download/index.php3: remove contrib stuff comment out two invalid mirrors * download/contrib.php3: new page, split from the main page, and somewhat rearranged * download/start.php3: add link to contrib page JMarc
Re: Graphics: file loading problems
On Fri, 12 Apr 2002, Angus Leeming wrote: > > 1) BUG: > >Bounding-box implementation on the LyX view is not consistent with > >the final DVI/Postscript output. > > Is this still the case? Is your Bounding Box consistent with the eps data, or > have you modified it? > > eg, if the postscript points lie in the range -100 < x < 100 and you have > modified the Bounding Box to 0 y1 100 y2, then the two are inconsistent. > There's little we can do about this. This also works, because we transform this bb-values to 100 y1 200 y2 of the corresponding xpm-file, which gives exactly the right view! means: All bounding boxes are viewed well in the lyx-window. Herbert
Re: Graphics: file loading problems
~On Fri, 12 Apr 2002, R. Lahaye wrote: > 1) BUG: >Bounding-box implementation on the LyX view is not consistent with >the final DVI/Postscript output. >Also, the use of the Top-right y-coordinate in the LyX View is bogus! >Use 'clip to boundingbox' to check this. as Angus wrote, this cannot be with the latest cvs from yesterday evening. think so ... ;-) > 2) WISH: >Is it possible to make the file Pattern in the graphics file browser >dynamical, so that it finds the file extensions of all convertable >graphics format-extensions itself? Everytime I have to add "agr" >to that list. >Would be nice if the graphics-file-browser can find out itself about >that, by using the Format/Conversion information from Preferences. makes sense and should be possible > 3) DIALOG-POLICY: >When I do "Insert->Graphics..." and then immediatly click on the >[Close] button, I'm left with a "No image"-square on my canvas. >However, it would be better if such a "nill-action" would not >affect the canvas at all. >NB: Change [Close] into [Cancel] when implementing this behaviour. > > Actually this dialog-policy-violation also applies to >BibTeX-database dialog >Include-file dialog >Edit-external-file dialog yes, this is a bit annoying Herbert
Re: FW: Graphics: file loading problems
On Fri, 12 Apr 2002, Lasgouttes, J.M. wrote: > I think the following patch addresses the issue. Rob, Herbert, could > you please test it and tell me whether it works? at weekend, I have no lyx on this machine in my office. the other one is outer space ... did tonight an update to suse8.0 ... it was my 11th update with suse since 4.1 and my machine NEVER runs after an update Herbert
Re: FW: Graphics: file loading problems
On Fri, Apr 12, 2002 at 02:07:22PM +0200, Herbert Voss wrote: > it was my 11th update with suse since 4.1 and > my machine NEVER runs after an update Which should have taught you to backup /etc, and /home and "install from scratch" after the third time or so ;-) Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
possible bug...
Thinking about Herbert and Rob's list of loadable graphics formats, I
discover the following code:
string const findTargetFormat(string const & from)
{
typedef GImage::FormatList FormatList;
FormatList const & formats = GImage::loadableFormats();
Now GImage::loadableFormats() returns a FormatList, not a FormatList &, so
why does this not die horribly?
Angus
Re: Graphics: file loading problems
On Friday 12 April 2002 1:04 pm, Herbert Voss wrote:
> ~On Fri, 12 Apr 2002, R. Lahaye wrote:
> > 1) BUG:
> >Bounding-box implementation on the LyX view is not consistent with
> >the final DVI/Postscript output.
> >Also, the use of the Top-right y-coordinate in the LyX View is bogus!
> >Use 'clip to boundingbox' to check this.
>
> as Angus wrote, this cannot be with the latest cvs from yesterday
> evening. think so ... ;-)
>
> > 2) WISH:
> >Is it possible to make the file Pattern in the graphics file browser
> >dynamical, so that it finds the file extensions of all convertable
> >graphics format-extensions itself? Everytime I have to add "agr"
> >to that list.
> >Would be nice if the graphics-file-browser can find out itself about
> >that, by using the Format/Conversion information from Preferences.
>
> makes sense and should be possible
The clean solution is to :
1. Add a new method to the GraphicsCache
std::vector loadableFormats() const
{
return GImage::loadableFormats();
}
(You need to create the method, because the GraphicsCache connects up the
appropriate signals, so you need to ensure that this has been done).
You can now access the list of formats loadable natively by the image loader
as
std::vector native_formats = GCache::get().loadableFormats();
2. Loop over the list of all formats known to LyX and discover which ones can
be converted to one of these native formats. Something similar to
findTargetFormat in GrapgicsCacheItem.
Off the top of my head:
vector native_formats = GCache::get().loadableFormats();
// We can load any format that can be loaded natively together with those
// that can be converted to one of these native formats.
vector browsable_formats = native_formats;
grfx::GConverter const & gconverter = grfx::GConverter::get();
vector::const_iterator to_end = native_formats.end();
Formats::const_iterator from_it = formats.begin();
Formats::const_iterator from_end = formats.end();
for (; from_it != from_end; ++from_it) {
string const from = from_it->name();
vector::const_iterator to_it = native_formats.begin();
for (; to_it != to_end; ++to_it) {
if (gconverter.isReachable(from, *to_it)) {
browsable_formats.push_back(from);
break;
}
}
}
That should give you a vector of all graphics formats loadable by LyX.
I'm sure someone, somewhere, will tell us to use the std algorithms, rather
than roll our own loops, but the above (or something close to it) should work.
Alternatively, why not just add "agr" to that string!
Angus
Re: possible bug...
Angus Leeming <[EMAIL PROTECTED]> writes:
| Thinking about Herbert and Rob's list of loadable graphics formats, I
| discover the following code:
>
| string const findTargetFormat(string const & from)
| {
| typedef GImage::FormatList FormatList;
| FormatList const & formats = GImage::loadableFormats();
>
| Now GImage::loadableFormats() returns a FormatList, not a FormatList &, so
| why does this not die horribly?
The const perhaps.
--
Lgb
Re: [Devel] Another bug list!
On Sun, Apr 07, 2002 at 09:40:55AM +0200, Michael Schmitt wrote: > - Create math formula; enter "^", "^", cursorleft,shift-cursorright; >delete > > - Create math formula; enter "^", shift-cursorleft, delete > -> same procedure as above > > - Create math formula; enter "^", "^", shift-cursorright, >shift-cursorright, shift-delete I can fix all of these by disabling a part of the 'remove empty scripts automatically' - mechanism. The problem is that it will be possible to create completely empty mathatoms (i.e empty base and neither sub- or superscript). I think this won't hurt much, but I am not completely sure. I'll commit anyway since this fixes all three cases and I can't get a crash anymore. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Bug: Clicking in a needfullrow inset actually selects
Open the attached document and click in the footnote. You get a selection. This is wrong... Same result with a displayed math equation. Juergen, is it your doing? JMarc newfile1.lyx Description: Binary data
Re: possible bug...
On Friday 12 April 2002 2:07 pm, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> | Thinking about Herbert and Rob's list of loadable graphics formats, I
> | discover the following code:
> |
> | string const findTargetFormat(string const & from)
> | {
> | typedef GImage::FormatList FormatList;
> | FormatList const & formats = GImage::loadableFormats();
> |
> | Now GImage::loadableFormats() returns a FormatList, not a FormatList &,
> | so why does this not die horribly?
>
> The const perhaps.
I take it you'd like me to make it more secure?
- FormatList const & formats = GImage::loadableFormats();
+ FormatList const formats = GImage::loadableFormats();
Angus
Re: possible bug...
On Fri, Apr 12, 2002 at 03:00:11PM +0100, Angus Leeming wrote: > > The const perhaps. > > I take it you'd like me to make it more secure? > - FormatList const & formats = GImage::loadableFormats(); > + FormatList const formats = GImage::loadableFormats(); By 12.2.5., the temporary object bound to the const reference should live as long as the reference in this case, i.e. the end of the block. But I am not completely sure about it, and if it is not a performance bottleneck, I'd create a copy there... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Mathed delimiters bug
When trying to use M-m [ or M-m (, I get respectively formulabase::LFUN_MATH_DELIM, arg: '[ ]' can't parse delimeters from '[ ]' formulabase::LFUN_MATH_DELIM, arg: '( )' can't parse delimeters from '( )' This can't be right. JMarc PS: and "delimeters" should be "delimiters"
[PATCH] Re: Graphics: file loading problems
Angus Leeming wrote:
> I'm sure someone, somewhere, will tell us to use the std algorithms, rather
> than roll our own loops, but the above (or something close to it) should work.
>
> Alternatively, why not just add "agr" to that string!
here is the alternative:
Herbert
--
http://www.lyx.org/help/
Index: src/frontends/controllers/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/ChangeLog,v
retrieving revision 1.158
diff -u -r1.158 ChangeLog
--- src/frontends/controllers/ChangeLog 11 Apr 2002 17:40:44 - 1.158
+++ src/frontends/controllers/ChangeLog 12 Apr 2002 14:39:27 -
@@ -1,5 +1,9 @@
2002-04-11 Herbert Voss <[EMAIL PROTECTED]>
+ * ControlGraphics.C: expand "browse-string" to all available formats
+
+2002-04-11 Herbert Voss <[EMAIL PROTECTED]>
+
* ControlGraphics.C: read BoundingBox also from non (e)ps files.
2002-04-08 Adrien Rebollo <[EMAIL PROTECTED]>
Index: src/frontends/controllers/ControlGraphics.C
===
RCS file:
/usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/ControlGraphics.C,v
retrieving revision 1.32
diff -u -r1.32 ControlGraphics.C
--- src/frontends/controllers/ControlGraphics.C 11 Apr 2002 17:40:44 - 1.32
+++ src/frontends/controllers/ControlGraphics.C 12 Apr 2002 14:39:28 -
@@ -46,6 +46,18 @@
using std::pair;
using std::make_pair;
using std::ifstream;
+
+namespace {
+
+// FIXME: currently we need the second '|' to prevent mis-interpretation!
+// All supported graphic formats with their file-extension and the
+// gzip-ext for zipped (e)ps-files.
+string const grfx_pattern =
+ "*.(agr|bmp|eps|epsi|fits|gif|jpg|obj|pdf|pbm|pgm|png|"
+ "ppm|ps|tif|tiff|xbm|xpm|xwd|gz)|";
+
+}
+
ControlGraphics::ControlGraphics(LyXView & lv, Dialogs & d)
: ControlInset(lv, d)
@@ -90,8 +102,6 @@
string const ControlGraphics::Browse(string const & in_name)
{
string const title = _("Select graphics file");
- // FIXME: currently we need the second '|' to prevent mis-interpretation
- string const pattern = "*.(ps|eps|png|jpeg|jpg|gif|gz)|";
// Does user clipart directory exist?
string clipdir = AddName (user_lyxdir, "clipart");
@@ -103,7 +113,7 @@
pair dir2(_("Documents|#o#O"), string(lyxrc.document_path));
// Show the file browser dialog
return browseRelFile(_, in_name, lv_.buffer()->filePath(),
-title, pattern, dir1, dir2);
+title, ::grfx_pattern, dir1, dir2);
}
RE: Bug: Clicking in a needfullrow inset actually selects
On 12-Apr-2002 Jean-Marc Lasgouttes wrote: > > Open the attached document and click in the footnote. You get a > selection. This is wrong... Same result with a displayed math > equation. > > Juergen, is it your doing? Yes! I fixed it in my tree but I like a bit more testing before commiting so I probably commit this only on Monday! Have a nice Weekend! Ciao, 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ The most difficult thing in the world is to know how to do a thing and to watch someone else doing it wrong, without commenting. -- T.H. White
Re: Bug: Clicking in a needfullrow inset actually selects
Juergen Vigna <[EMAIL PROTECTED]> writes: | On 12-Apr-2002 Jean-Marc Lasgouttes wrote: >> >> Open the attached document and click in the footnote. You get a >> selection. This is wrong... Same result with a displayed math >> equation. >> >> Juergen, is it your doing? > | Yes! I fixed it in my tree but I like a bit more testing before commiting | so I probably commit this only on Monday! If you have a chance, please commit as soon as possible, I'd really like to have a pre4 soon. -- Lgb
Re: Mathed delimiters bug
On Fri, Apr 12, 2002 at 04:18:52PM +0200, Jean-Marc Lasgouttes wrote: > When trying to use M-m [ or M-m (, I get respectively > formulabase::LFUN_MATH_DELIM, arg: '[ ]' > can't parse delimeters from '[ ]' I see the first line, but not the second. And it inserts () and []. I just removed the spurious message. 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: small mathed annoyance
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: Jean-Marc> Another problem. With the attachaed file, the macros do not Jean-Marc> redisplay correctly when you do pageup/down. I have also Jean-Marc> seen cases where the contents of the macro got drawn Jean-Marc> outside of the purple box (I'll have to reproduce it). Another way to look at the same problem: open user guide, go to section 5.5 (macros) and move a bit the scrollbar when you have a macro definition visible. Then look how the macros redraw themselves ouside of their purple box... This is definitely annoying. JMarc
Re: Bug: Clicking in a needfullrow inset actually selects
On 12-Apr-2002 Lars Gullik Bjønnes wrote: >| Yes! I fixed it in my tree but I like a bit more testing before commiting >| so I probably commit this only on Monday! > > If you have a chance, please commit as soon as possible, I'd really > like to have a pre4 soon. Well I commited what I had it should work, but I have to admit that I didn't test it very well. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ The greatest of faults is to be conscious of none.
Re: small mathed annoyance
On Fri, Apr 12, 2002 at 05:54:35PM +0200, Jean-Marc Lasgouttes wrote: > This is definitely annoying. But easy to fix... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Math character bug in pre3
This bug was around a long time ago; I don't remember if it was fixed and got broken again, or if it was ignored and declared correct behavior. I use "Alt-m g m m" in text mode in 1.1.5fix2 all the time to make the micrometer abbreviation - in TeX it is "$\mu$m". In 1.2.0pre3, the above sequence generates a math box with the greek letter mu, then leaves the cursor just of the left of the box and inserts the m before it - I get "m$\mu$". If I am already in mathed, the "Alt-m g m m" works as expected: a "mu" followed by an "m". Can this be fixed? Mike -- Mike Ressler [EMAIL PROTECTED] OK, I'm lame: I don't have my own website ...
Graphics: Bug in Alert window ?
Hi, While having trouble with the Graphics routine, I have deleted the "EPS->XPM" and "PNG->XPM" converters in Preferences in a trial to solve my problems. After that, LyX cannot anymore load my EPS file and pops up the Alert window which looks like in the attachment. The message-text area is transparent; only the [Dismiss]-button area has the proper grey background. Somehow, the failing conversion seems to disturb the Alert window's background. Is that possible? When I load a graphics file with totally unrelated format (e.g. a silly .txt file), the popped up Alert is sort of OK. Sort of OK: the message-text doesn't fit in the window! - Is this a bug in LyX (in Graphics, where the Alert is created?), or is this due to XForms 0.88.1 ? Regards, Rob.
Graphics: "Waiting for draw request to start loading" ?
Hi, A graphics picture in mode "Don't display" gets one of two messages in the graphics inset: "Draw request to start loading..." or "Loaded but not displaying" I find both messages typical info for developers, not relevant to the average LyX user. All the user needs to know is that the picture is in mode "Don't display" I recommend to replace both messages by "Don't display". Then this message also equals the text in Graphics->LyX View->Screen display and in Preferences->Look>Misc->Display Graphics. Regards, Rob.
