[PATCH] Re: Graphics: file loading problems
Angus Leeming wrote: Bingo! xforms 0.88 has noimage support. You're using the image loader I wrote based on the libXpm library. The relevant code is to be found in src/graphics/GraphicsImageXPM.C. $Bingo^2$ !! Thanks for your hints and help. Instead of dimension const * start_row = old_data; we need dimension const * start_row = old_data + image_.width() * (image_.height() - params.bb.yt); Please apply attached patch! Regards, Rob. graphics.diff.gz Description: GNU Zip compressed data
Re: [PATCH] Re: Graphics: file loading problems
On Monday 15 April 2002 4:22 pm, R. Lahaye wrote: Angus Leeming wrote: Bingo! xforms 0.88 has noimage support. You're using the image loader I wrote based on the libXpm library. The relevant code is to be found in src/graphics/GraphicsImageXPM.C. $Bingo^2$ !! Thanks for your hints and help. Instead of dimension const * start_row = old_data; we need dimension const * start_row = old_data + image_.width() * (image_.height() - params.bb.yt); dimension const * start_row = old_data + image_.width() * (image_.height() - params.bb.yt); Excuse me a momement, but why is that: (image_.height() - params.bb.yt) not params.bb.yb ? Angus
Re: [PATCH] Re: Graphics: file loading problems
Angus Leeming wrote: On Monday 15 April 2002 4:22 pm, R. Lahaye wrote: Angus Leeming wrote: Bingo! xforms 0.88 has noimage support. You're using the image loader I wrote based on the libXpm library. The relevant code is to be found in src/graphics/GraphicsImageXPM.C. $Bingo^2$ !! Thanks for your hints and help. Instead of dimension const * start_row = old_data; we need dimension const * start_row = old_data + image_.width() * (image_.height() - params.bb.yt); dimension const * start_row = old_data + image_.width() * (image_.height() - params.bb.yt); Excuse me a momement, but why is that: (image_.height() - params.bb.yt) not params.bb.yb ? Ah, took me also some time to realize. The picture is stored in memory from upper-left to lower-right (see attachement). Horizontally you still run from xl to xr, but vertically you run from yt to yb, NOT reversed as you're thinking. So you have to recalculate from the top, not the bottom. The top is height - yt. Does that make sense to you? The patch works beautifully here! Regards, Rob. Angus -- dr. R.J.W.E. Lahaye Center for Ion-Surface Reaction Department of Chemistry Pohang University of Science and Technology San 31 Hyojadong, Namgu 790-784 Pohang, Kyungbuk Republic of Korea Tel : +82-54-279-2780 Fax : +82-54-279-8157 email: [EMAIL PROTECTED]
Re: [PATCH] Re: Graphics: file loading problems
On Monday 15 April 2002 5:37 pm, R. Lahaye wrote: Excuse me a momement, but why is that: (image_.height() - params.bb.yt) not params.bb.yb ? Ah, took me also some time to realize. The picture is stored in memory from upper-left to lower-right (see attachement). Horizontally you still run from xl to xr, but vertically you run from yt to yb, NOT reversed as you're thinking. So you have to recalculate from the top, not the bottom. The top is height - yt. Does that make sense to you? Indeed. I probably knew this once upon a time, but my mind is like a seive and it's easier to question than to remember. The patch works beautifully here! And here. I'll apply presently. Angus Regards, Rob. Angus
[PATCH] Re: Graphics: file loading problems
Angus Leeming wrote: > > Bingo! xforms 0.88 has noimage support. You're using the image loader I > wrote based on the libXpm library. The relevant code is to be found in > src/graphics/GraphicsImageXPM.C. $Bingo^2$ !! Thanks for your hints and help. Instead of dimension const * start_row = old_data; we need dimension const * start_row = old_data + image_.width() * (image_.height() - params.bb.yt); Please apply attached patch! Regards, Rob. graphics.diff.gz Description: GNU Zip compressed data
Re: [PATCH] Re: Graphics: file loading problems
On Monday 15 April 2002 4:22 pm, R. Lahaye wrote: > Angus Leeming wrote: > > Bingo! xforms 0.88 has noimage support. You're using the image loader I > > wrote based on the libXpm library. The relevant code is to be found in > > src/graphics/GraphicsImageXPM.C. > > $Bingo^2$ !! Thanks for your hints and help. > > Instead of > >dimension const * start_row = old_data; > > we need > > dimension const * start_row = old_data > + image_.width() * (image_.height() - > params.bb.yt); dimension const * start_row = old_data + image_.width() * (image_.height() - params.bb.yt); Excuse me a momement, but why is that: (image_.height() - params.bb.yt) not params.bb.yb ? Angus
Re: [PATCH] Re: Graphics: file loading problems
Angus Leeming wrote: > > On Monday 15 April 2002 4:22 pm, R. Lahaye wrote: > > Angus Leeming wrote: > > > Bingo! xforms 0.88 has noimage support. You're using the image loader I > > > wrote based on the libXpm library. The relevant code is to be found in > > > src/graphics/GraphicsImageXPM.C. > > > > $Bingo^2$ !! Thanks for your hints and help. > > > > Instead of > > > >dimension const * start_row = old_data; > > > > we need > > > > dimension const * start_row = old_data > > + image_.width() * (image_.height() - > > params.bb.yt); > > dimension const * start_row = old_data + image_.width() * > (image_.height() - params.bb.yt); > > Excuse me a momement, but why is that: > (image_.height() - params.bb.yt) > not > params.bb.yb > ? Ah, took me also some time to realize. The picture is stored in memory from upper-left to lower-right (see attachement). Horizontally you still run from xl to xr, but vertically you run from yt to yb, NOT reversed as you're thinking. So you have to recalculate from the top, not the bottom. The top is "height - yt". Does that make sense to you? The patch works beautifully here! Regards, Rob. > Angus -- dr. R.J.W.E. Lahaye Center for Ion-Surface Reaction Department of Chemistry Pohang University of Science and Technology San 31 Hyojadong, Namgu 790-784 Pohang, Kyungbuk Republic of Korea Tel : +82-54-279-2780 Fax : +82-54-279-8157 email: [EMAIL PROTECTED]
Re: [PATCH] Re: Graphics: file loading problems
On Monday 15 April 2002 5:37 pm, R. Lahaye wrote: > > Excuse me a momement, but why is that: > > (image_.height() - params.bb.yt) > > not > > params.bb.yb > > ? > > Ah, took me also some time to realize. > The picture is stored in memory from upper-left to lower-right > (see attachement). > Horizontally you still run from xl to xr, but vertically > you run from yt to yb, NOT reversed as you're thinking. > So you have to recalculate from the top, not the bottom. > The top is "height - yt". > > Does that make sense to you? Indeed. I probably knew this once upon a time, but my mind is like a seive and it's easier to question than to remember. > > The patch works beautifully here! And here. I'll apply presently. Angus > > Regards, > Rob. > > > Angus
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: 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_); }
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
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)
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
[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: 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: 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_); }
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
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)
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
[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);
}
Graphics: file loading problems
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. GraphicsTest.tar.gz Description: GNU Zip compressed data
Graphics: file loading problems
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. GraphicsTest.tar.gz Description: GNU Zip compressed data
