Re: Graphics: newer ImageMagick version causes trouble for LyX-View
Jean-Marc Lasgouttes wrote: > > R> Why the configure script can't find it there? It doesn't look in > R> /usr/local/include and /usr/local/lib ? A mistery to me. Any ideas? > R> I may investigate a bit on this. > > I don't know really. However the error message is quite clear in this > respect: > > configure:12094: checking for jpeg_read_header in -ljpeg > configure:12127: gcc -o conftest -g -O2 -isystem /usr/X11R6/include conftest.c > -ljpeg -lforms -lXpm -lSM -lICE -lc -lm -L/usr/X11R6/lib -lX11 >&5 > /usr/libexec/elf/ld: cannot find -ljpeg OK. Solved it temporarily by "setenv LDFLAGS -L/usr/local/lib", but then I run again into trouble, as you can see in message http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg41160.html which confuses me once more. Rob.
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
> "R" == R Lahaye <[EMAIL PROTECTED]> writes: R> In the CVS-diff, I see that you swapped a black/white string to fix R> this. Right? Yes. R> John seemed to have objections to this change. But I have not :). R> It works wonderful here! Excellent. R> Why the configure script can't find it there? It doesn't look in R> /usr/local/include and /usr/local/lib ? A mistery to me. Any ideas? R> I may investigate a bit on this. I don't know really. However the error message is quite clear in this respect: configure:12094: checking for jpeg_read_header in -ljpeg configure:12127: gcc -o conftest -g -O2 -isystem /usr/X11R6/include conftest.c -ljpeg -lforms -lXpm -lSM -lICE -lc -lm -L/usr/X11R6/lib -lX11 >&5 /usr/libexec/elf/ld: cannot find -ljpeg JMarc
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
Jean-Marc Lasgouttes wrote: > > > "R" == R Lahaye <[EMAIL PROTECTED]> writes: > > Yes, I have fixed that in 1.2.x cvs yesterday and in 1.3.0cvs > yesterday evening. So now everything should be fine. In the CVS-diff, I see that you swapped a black/white string to fix this. Right? John seemed to have objections to this change. But I have not :). It works wonderful here! > Now that you have confirmed that the old XPM lader works fine, I can > give you the secret to use the much better xforms loader: as seen in > your config.log, the loader did not get used because you do not have > the jpeg library installed. Install it and everything should be fine > again. Oh. I see. But I actually have jpeg-6b library installed: /usr/local/include/jconfig.h /usr/local/include/jerror.h /usr/local/include/jinclude.h /usr/local/include/jmorecfg.h /usr/local/include/jpegint.h /usr/local/include/jpeglib.h /usr/local/lib/libjpeg.a /usr/local/lib/libjpeg.so /usr/local/lib/libjpeg.so.9 Why the configure script can't find it there? It doesn't look in /usr/local/include and /usr/local/lib ? A mistery to me. Any ideas? I may investigate a bit on this. Regards, Rob.
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
> "R" == R Lahaye <[EMAIL PROTECTED]> writes: R> Uh, the problem seems to be gone with yesterday's cvs update. Don't R> know what has changed. R> Leave this problems for what it is. I'll make noise again as soon R> as the same problem resurfaces with CVS. Yes, I have fixed that in 1.2.x cvs yesterday and in 1.3.0cvs yesterday evening. So now everything should be fine. Now that you have confirmed that the old XPM lader works fine, I can give you the secret to use the much better xforms loader: as seen in your config.log, the loader did not get used because you do not have the jpeg library installed. Install it and everything should be fine again. JMarc
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
Jean-Marc Lasgouttes wrote: > > > "R" == R Lahaye <[EMAIL PROTECTED]> writes: > > R> I'm using a fairly recent version of ImageMagick (5.4.7). This > R> version's convert produces a color output line > R> " c opaque" > R> which causes a horrible quality in the LyX-View. > > Hmm, I just see that the code in GraphicsImageXPM does: > > // some image magick versions use this > xpm_col[1].name = 0; > xpm_col[1].value = "opaque"; > xpm_col[1].pixel = lyxColorHandler->colorPixel(LColor::white); Uh, the problem seems to be gone with yesterday's cvs update. Don't know what has changed. Leave this problems for what it is. I'll make noise again as soon as the same problem resurfaces with CVS. Regards, Rob.
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
On Tue, Jul 16, 2002 at 03:32:35PM +0100, Angus Leeming wrote: > If you can think of a more elegant solution, then I'm all ears. > Angus I've already suggested a XGraphicsImage class which GraphicsImageXPM and xformsImage derive from ... then case to XGraphicsImage regards john -- "i am sorey I cant reads yuor emale because my emale box has filtar on it whitch says, "NO EMALES FROM PEOAPAL UNDER IQ OF 1" - jeffk
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
On Tue, Jul 16, 2002 at 01:36:44PM +0200, Jean-Marc Lasgouttes wrote: > xpm_col[1].value = "opaque"; > xpm_col[1].pixel = lyxColorHandler->colorPixel(LColor::white); > > Shouldn't that be LColor::black? John, why did you choose white > instead of black? Hmm, because it's going to get printed on white paper no ? I'm not bothered either way john -- "i am sorey I cant reads yuor emale because my emale box has filtar on it whitch says, "NO EMALES FROM PEOAPAL UNDER IQ OF 1" - jeffk
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
On Tuesday 16 July 2002 4:31 pm, Jean-Marc Lasgouttes wrote: > > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> Good idea, actually. John, since you broke it would you like to > Angus> fix it? A > > Another thought: didn't you write that ImageXPM will go away before > 1.3.0? In this case, your patch may just be good enough... How much noise has the xforms list been making at your end? Here it's been nearly deadly silent. The fact that I don't even receive acknowledgement when I submit a small and safe patch doesn't endear me to the bloody thing.
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Good idea, actually. John, since you broke it would you like to Angus> fix it? A Another thought: didn't you write that ImageXPM will go away before 1.3.0? In this case, your patch may just be good enough... JMarc
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
On Tuesday 16 July 2002 4:14 pm, Jean-Marc Lasgouttes wrote: > > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> Because John and Qt don't have a Pixmap getPixmap() method. > Angus> Apparently Pixmaps are X-specific and that's a limitation they > Angus> can do without. > > Angus> If you can think of a more elegant solution, then I'm all ears. > > Have a XImage class which derives from Image and have ImageXPM and > xformsImage derive from it? More code, but less #ifdef. > > JMarc Good idea, actually. John, since you broke it would you like to fix it? A
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Because John and Qt don't have a Pixmap getPixmap() method. Angus> Apparently Pixmaps are X-specific and that's a limitation they Angus> can do without. Angus> If you can think of a more elegant solution, then I'm all ears. Have a XImage class which derives from Image and have ImageXPM and xformsImage derive from it? More code, but less #ifdef. JMarc
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
On Tuesday 16 July 2002 3:50 pm, Jean-Marc Lasgouttes wrote:
> > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> On Tuesday 16 July 2002 3:26 pm, R. Lahaye wrote:
> >> Jean-Marc Lasgouttes wrote: > > "R" == R Lahaye
> >>
> >> <[EMAIL PROTECTED]> writes:
> >> > R> I would test that right away, but GraphicsImageXPM.C is badly
> >> > R> broken in CVS right now. Please fix that first:
> >> >
> >> > Try the following patch.
> >> >
> >> > grxpm.patchName: grxpm.patch > Type: text/x-patch
> >>
> >> Nope. Get a little further though, but now it breaks at:
> >>
> >> ): undefined reference to `grfx::xformsImage::getPixmap(void)
> >> const' ***
>
> Angus> Well that's just nasty of it. The reason it does this is
> Angus> because of a static_cast in xforms/XPainter.C.
>
> Can you enlighten me on why the cast to xformsImage is needed at all?
>
> JMarc
Because John and Qt don't have a Pixmap getPixmap() method. Apparently
Pixmaps are X-specific and that's a limitation they can do without.
If you can think of a more elegant solution, then I'm all ears.
Angus
Here's the QT Painter code:
class QLImage : public Image
{
public:
QPixmap const & qpixmap() const { return xformed_pixmap_; }
};
Painter & QLPainter::image(int x, int y,
int w, int h,
grfx::Image const & i)
{
qp_->drawPixmap(x, y, static_cast(i).qpixmap(), 0, 0,
w, h);
return *this;
}
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> On Tuesday 16 July 2002 3:26 pm, R. Lahaye wrote: >> Jean-Marc Lasgouttes wrote: > > "R" == R Lahaye >> <[EMAIL PROTECTED]> writes: >> > >> > R> I would test that right away, but GraphicsImageXPM.C is badly >> > R> broken in CVS right now. Please fix that first: >> > >> > Try the following patch. >> > >> > grxpm.patchName: grxpm.patch > Type: text/x-patch >> >> Nope. Get a little further though, but now it breaks at: >> >> ): undefined reference to `grfx::xformsImage::getPixmap(void) >> const' *** Angus> Well that's just nasty of it. The reason it does this is Angus> because of a static_cast in xforms/XPainter.C. Can you enlighten me on why the cast to xformsImage is needed at all? JMarc
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
On Tuesday 16 July 2002 3:26 pm, R. Lahaye wrote:
> Jean-Marc Lasgouttes wrote:
> > > "R" == R Lahaye <[EMAIL PROTECTED]> writes:
> >
> > R> I would test that right away, but GraphicsImageXPM.C is badly
> > R> broken in CVS right now. Please fix that first:
> >
> > Try the following patch.
> >
> >grxpm.patchName: grxpm.patch
> > Type: text/x-patch
>
> Nope. Get a little further though, but now it breaks at:
>
>): undefined reference to `grfx::xformsImage::getPixmap(void) const' ***
Well that's just nasty of it. The reason it does this is because of a
static_cast in xforms/XPainter.C.
try this.
A
Index: src/frontends/xforms/XPainter.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/XPainter.C,v
retrieving revision 1.9
diff -u -p -r1.9 XPainter.C
--- src/frontends/xforms/XPainter.C 15 Jul 2002 17:17:56 - 1.9
+++ src/frontends/xforms/XPainter.C 16 Jul 2002 14:43:12 -
@@ -23,7 +23,11 @@
#include "encoding.h"
#include "language.h"
+#ifdef USE_XFORMS_IMAGE_LOADER
#include "xformsImage.h"
+#else
+#include "graphics/GraphicsImageXPM.h"
+#endif
#include "support/LAssert.h"
#include "support/lstrings.h"
@@ -152,7 +156,12 @@ Painter & XPainter::image(int x, int y,
int w, int h,
grfx::Image const & i)
{
+#ifdef USE_XFORMS_IMAGE_LOADER
grfx::xformsImage const & image = static_cast(i);
+#else
+ grfx::ImageXPM const & image = static_cast(i);
+#endif
+
XGCValues val;
val.function = GXcopy;
GC gc = XCreateGC(fl_get_display(), owner_.getPixmap(),
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
Jean-Marc Lasgouttes wrote: > > > "R" == R Lahaye <[EMAIL PROTECTED]> writes: > > R> I would test that right away, but GraphicsImageXPM.C is badly > R> broken in CVS right now. Please fix that first: > > Try the following patch. > >grxpm.patchName: grxpm.patch > Type: text/x-patch Nope. Get a little further though, but now it breaks at: [...] g++ -g -O -Wno-non-template-friend -W -Wall -o lyx BufferView.o BufferView2.o BufferView_pimpl.o Bullet.o Chktex.o CutAndPaste.o DepTable.o FloatList.o Floating.o FuncStatus.o LColor.o LaTeX.o LaTeXFeatures.o LyXAction.o MenuBackend.o ParagraphParameters.o Spacing.o TextCache.o Thesaurus.o ToolbarDefaults.o box.o buffer.o bufferlist.o bufferparams.o bufferview_funcs.o chset.o converter.o debug.o encoding.o exporter.o gettext.o importer.o intl.o iterators.o kbmap.o kbsequence.o language.o lastfiles.o lengthcommon.o lyx_cb.o lyx_main.o lyx_sty.o lyxcursor.o lyxfont.o lyxfind.o lyxfunc.o lyxgluelength.o lyxlayout.o lyxlength.o lyxlex.o lyxlex_pimpl.o lyxrc.o lyxrow.o lyxserver.o lyxtextclass.o lyxtextclasslist.o lyxvc.o main.o paragraph.o paragraph_pimpl.o sp_spell.o tabular.o tabular-old.o tabular_funcs.o tex-accent.o tex-strings.o texrow.o text.o text2.o trans.o trans_mgr.o undo.o undo_funcs.o vc-backend.o version.o vspace.o mathed/.libs/libmathed.a insets/.libs/libinsets.a frontends/.libs/libfrontends.a -lforms graphics/.libs/libgraphics.a support/.libs/libsupport.a ../boost/libs/regex/src/.libs/libboostregex.a ../boost/libs/signals/src/.libs/libboostsignals.a ../intl/libintl.a -lXpm -lSM -lICE -lc -lm -L/usr/X11R6/lib -lX11 frontends/.libs/libfrontends.a(XPainter.o): In function `XPainter::image(int, int, int, int, grfx::Image const &)': /home/lahaye/SOFTWARE/lyx-devel/src/frontends/xforms/XPainter.C(.text+0x42c): undefined reference to `grfx::xformsImage::getPixmap(void) const' *** Error code 1 Regards, Rob.
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
> "R" == R Lahaye <[EMAIL PROTECTED]> writes: R> Also have a look at the warnings that autogen.sh produce; it's in R> an earlier message of mine: R> http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg40925.html I've seen and fixed it. I have removed a couple warnings in my tree. Concerning the autoconf 2.53 warnings, I plan to have a go at that soon. JMarc
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
> "R" == R Lahaye <[EMAIL PROTECTED]> writes: R> Argh, no I can't. The machine where I have FreeBSD 4.6 + latest R> ImageMagick (thus that opaque problem), does not compile 1.2.x. The R> reason is not that clear to me, but there seem to be a problem in R> src/config with HAVE_UNISTD_H and defining pid_t, off_t and mode_t. R> These redefinitions jam my make. I have no idea how to solve this, R> so I gave up on 1.2.x .. Aha! This is a problem with autoconf 2.5x that I know about, but do not see. Can you send me the relevant config.log? R> For some obscure reason, this is going well in 1.3.0cvs. Obscure is the right word in this case, indeed. JMarc
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
> "R" == R Lahaye <[EMAIL PROTECTED]> writes:
R> I would test that right away, but GraphicsImageXPM.C is badly
R> broken in CVS right now. Please fix that first:
Try the following patch.
JMarc
Index: src/graphics/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/graphics/ChangeLog,v
retrieving revision 1.95
diff -u -p -r1.95 ChangeLog
--- src/graphics/ChangeLog 15 Jul 2002 17:17:56 - 1.95
+++ src/graphics/ChangeLog 16 Jul 2002 12:29:45 -
@@ -1,3 +1,8 @@
+2002-07-16 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
+
+ * GraphicsImageXPM.C (isDrawable): implement
+ (setPixmap): the opaque color is black, not white
+
2002-07-15 John Levon <[EMAIL PROTECTED]>
* GraphicsImage.h: remove getPixmap/X, add isDrawable()
@@ -272,6 +277,7 @@
pretty temperamemtal at the moment.
2002-04-16 Rob Lahaye <[EMAIL PROTECTED]>
+
* GraphicsImageXPM.C: fix clipping for boundingbox y-coordinates
2002-04-08 Angus Leeming <[EMAIL PROTECTED]>
Index: src/graphics/GraphicsImageXPM.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/graphics/GraphicsImageXPM.C,v
retrieving revision 1.25
diff -u -p -r1.25 GraphicsImageXPM.C
--- src/graphics/GraphicsImageXPM.C 15 Jul 2002 10:19:45 - 1.25
+++ src/graphics/GraphicsImageXPM.C 16 Jul 2002 12:29:45 -
@@ -95,6 +95,12 @@ unsigned int ImageXPM::getHeight() const
}
+bool ImageXPM::isDrawable() const
+{
+ return pixmap_;
+}
+
+
Pixmap ImageXPM::getPixmap() const
{
if (!pixmap_status_ == PIXMAP_SUCCESS)
@@ -207,7 +213,7 @@ bool ImageXPM::setPixmap(Params const &
// some image magick versions use this
xpm_col[1].name = 0;
xpm_col[1].value = "opaque";
- xpm_col[1].pixel = lyxColorHandler->colorPixel(LColor::white);
+ xpm_col[1].pixel = lyxColorHandler->colorPixel(LColor::black);
attrib.numsymbols = 2;
attrib.colorsymbols = xpm_col;
Index: src/graphics/GraphicsImageXPM.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/graphics/GraphicsImageXPM.h,v
retrieving revision 1.5
diff -u -p -r1.5 GraphicsImageXPM.h
--- src/graphics/GraphicsImageXPM.h 15 Jul 2002 10:19:45 - 1.5
+++ src/graphics/GraphicsImageXPM.h 16 Jul 2002 12:29:45 -
@@ -48,6 +48,8 @@ public:
/// Get the image height
unsigned int getHeight() const;
+ bool isDrawable() const;
+
/** Load the image file into memory.
* In this case (ImageXPM), the process is blocking.
*/
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
Jean-Marc Lasgouttes wrote: > > > "R" == R Lahaye <[EMAIL PROTECTED]> writes: > > R> Jean-Marc Lasgouttes wrote: > >> > >> > >> Hmm, I just see that the code in GraphicsImageXPM does: > >> > >> // some image magick versions use this xpm_col[1].name = 0; > >> xpm_col[1].value = "opaque"; xpm_col[1].pixel = > >> lyxColorHandler->colorPixel(LColor::white); > >> > >> Shouldn't that be LColor::black? John, why did you choose white > >> instead of black? > > R> I would test that right away, but GraphicsImageXPM.C is badly > R> broken in CVS right now. Please fix that first: > > I'll try to do it. In the meantime, could you try that on 1.2.1cvs? Argh, no I can't. The machine where I have FreeBSD 4.6 + latest ImageMagick (thus that opaque problem), does not compile 1.2.x. The reason is not that clear to me, but there seem to be a problem in src/config with HAVE_UNISTD_H and defining pid_t, off_t and mode_t. These redefinitions jam my make. I have no idea how to solve this, so I gave up on 1.2.x .. For some obscure reason, this is going well in 1.3.0cvs. If you have clue, let me know. Otherwise, I'll wait till the fix in 1.3.0 for GraphicsImageXPM.C. Thanks, Rob.
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
> "R" == R Lahaye <[EMAIL PROTECTED]> writes: R> Jean-Marc Lasgouttes wrote: >> >> >> Hmm, I just see that the code in GraphicsImageXPM does: >> >> // some image magick versions use this xpm_col[1].name = 0; >> xpm_col[1].value = "opaque"; xpm_col[1].pixel = >> lyxColorHandler->colorPixel(LColor::white); >> >> Shouldn't that be LColor::black? John, why did you choose white >> instead of black? R> I would test that right away, but GraphicsImageXPM.C is badly R> broken in CVS right now. Please fix that first: I'll try to do it. In the meantime, could you try that on 1.2.1cvs? JMarc
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
Jean-Marc Lasgouttes wrote: > > > Hmm, I just see that the code in GraphicsImageXPM does: > > // some image magick versions use this > xpm_col[1].name = 0; > xpm_col[1].value = "opaque"; > xpm_col[1].pixel = lyxColorHandler->colorPixel(LColor::white); > > Shouldn't that be LColor::black? John, why did you choose white > instead of black? I would test that right away, but GraphicsImageXPM.C is badly broken in CVS right now. Please fix that first: source='GraphicsImageXPM.C' object='GraphicsImageXPM.lo' libtool=yes depfile='.deps/GraphicsImageXPM.Plo' tmpdepfile='.deps/GraphicsImageXPM.TPlo' depmode=gcc /bin/sh ../../config/depcomp /bin/sh ../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../../boost -isystem /usr/X11R6/include -g -O -Wno-non-template-friend -W -Wall -c -o GraphicsImageXPM.lo `test -f GraphicsImageXPM.C || echo './'`GraphicsImageXPM.C g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../../boost -isystem /usr/X11R6/include -g -O -Wno-non-template-friend -W -Wall -c GraphicsImageXPM.C -Wp,-MD,.deps/GraphicsImageXPM.TPlo GraphicsImageXPM.C: In function `static class boost::shared_ptr grfx::ImageXPM::newImage()': GraphicsImageXPM.C:45: cannot allocate an object of type `grfx::ImageXPM' GraphicsImageXPM.C:45: since the following virtual functions are abstract: GraphicsImage.h:73: bool grfx::Image::isDrawable() const GraphicsImageXPM.C: In method `class grfx::Image * grfx::ImageXPM::clone() const': GraphicsImageXPM.C:82: cannot allocate an object of type `grfx::ImageXPM' GraphicsImageXPM.C:82: since type `grfx::ImageXPM' has abstract virtual functions GraphicsImageXPM.C: In method `void grfx::ImageXPM::clip(const grfx::Params &)': GraphicsImageXPM.C:273: warning: comparison between signed and unsigned *** Error code 1 Cheers, Rob.
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
> "R" == R Lahaye <[EMAIL PROTECTED]> writes: R> Hi, R> After a useful communication with Herbert on my problem displaying R> xpm-files on the LyX canvas, we came to the following conclusion: R> I'm using a fairly recent version of ImageMagick (5.4.7). This R> version's convert produces a color output line R> " c opaque" R> which causes a horrible quality in the LyX-View. R> Manually I have to do R> convert -opaque black Hmm, I just see that the code in GraphicsImageXPM does: // some image magick versions use this xpm_col[1].name = 0; xpm_col[1].value = "opaque"; xpm_col[1].pixel = lyxColorHandler->colorPixel(LColor::white); Shouldn't that be LColor::black? John, why did you choose white instead of black? JMarc
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
Jean-Marc Lasgouttes wrote: > Note that autoconf 2.53 is not really supposed to work for lyx, > but we might as well try to make it work. 2.53 ships with FreeBSD 4.6 and it's around for quite some time already. It's too much work to get the older version of autoconf on my system (need to compile myself; the older packages have the wrong dependecies blabla). Anyway, I don't think it's related to 2.53, since I remember to have had the same problem when I still used the older version! > Send me your config.log and I'll have a look. Attached. Also have a look at the warnings that autogen.sh produce; it's in an earlier message of mine: http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg40925.html Thanks Rob. config.log.bz2 Description: Binary data
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
> "R" == R Lahaye <[EMAIL PROTECTED]> writes: R> Jean-Marc Lasgouttes wrote: >> With xforms 1.0.0, you should not be using the XPM loader. 'lyx >> -version' should confirm that you are using the xforms loader, R> Confirm? How? This is my output: R> Special build flags: warnings assertions OK, so your are not using the xforms image loader. That should not happen. Could you send your config.log file? Note that autoconf 2.53 is not really supposed to work for lyx, but we might as well try to make it work. R> PS: I have to modify *manually* my configure script after the R> autogen.sh, to make the -lforms check work with xforms 1.0.0; it R> needs a "-lXpm": LIBS="-lforms -lXpm $LIBS" R> Shouldn't we add that anyway? But where? configure.in? or R> config/*.m4 ? Send me your config.log and I'll have a look. JMarc
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
Jean-Marc Lasgouttes wrote: > > With xforms 1.0.0, you should not be using the XPM loader. 'lyx > -version' should confirm that you are using the xforms loader, Confirm? How? This is my output: $ lyx -version LyX 1.3.0cvs of Fri, May 3, 2002 Built on Jul 15 2002, 18:12:56 Configuration Host type: i386-unknown-freebsd4.6 Special build flags:warnings assertions C Compiler: gcc C Compiler flags: -g -O2 C++ Compiler: g++ (2.95.3) C++ Compiler flags: -g -O -Wno-non-template-friend -W -Wall Linker flags: Frontend: xforms libXpm version: 4.11 libforms version: 1.0.0 LyX binary dir: /opt/bin LyX files dir: /opt/share/lyx Rob. PS: I have to modify *manually* my configure script after the autogen.sh, to make the -lforms check work with xforms 1.0.0; it needs a "-lXpm": LIBS="-lforms -lXpm $LIBS" Shouldn't we add that anyway? But where? configure.in? or config/*.m4 ?
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
> "R" == R Lahaye <[EMAIL PROTECTED]> writes: R> How do I know whether I'm using that code from GraphicsImageXPM or R> not? With xforms 1.0.0, you should not be using the XPM loader. 'lyx -version' should confirm that you are using the xforms loader, actually. The question now is to know whether we can make it understand this opaque color. JMarc
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
Jean-Marc Lasgouttes wrote: > > > "R" == R Lahaye <[EMAIL PROTECTED]> writes: > > R> Jean-Marc Lasgouttes wrote: > >> > "Rob" == R Lahaye <[EMAIL PROTECTED]> writes: > Rob> I'm using a fairly recent version of ImageMagick (5.4.7). This > Rob> version's convert produces a color output line " c opaque" which > Rob> causes a horrible quality in the LyX-View. Manually I have to do > Rob> convert -opaque black > >> Do you use the xforms image loader or the LyX one? There is code > >> in GraphicsImageXPM to handle the opaque thing, normally. > > R> I'm now using xforms 1.0.0, but the same behaviour was there with > R> 0.88.1. > > R> How do I know whether I'm using that code from GraphicsImageXPM or > R> not? > > Is this from latest cvs? Trunk or 1.2.x branch? The problem is there for both, though I'm now only working with 1.3.0cvs. I believed it's a problem with ImageMagick recent convert implementation. However, if it's related to code in GraphicsImageXPM, we need to investigate further Any hints as of where the culprit could be, if it's somewhere in LyX? Rob.
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
> "R" == R Lahaye <[EMAIL PROTECTED]> writes: R> Jean-Marc Lasgouttes wrote: >> > "Rob" == R Lahaye <[EMAIL PROTECTED]> writes: Rob> I'm using a fairly recent version of ImageMagick (5.4.7). This Rob> version's convert produces a color output line " c opaque" which Rob> causes a horrible quality in the LyX-View. Manually I have to do Rob> convert -opaque black >> Do you use the xforms image loader or the LyX one? There is code >> in GraphicsImageXPM to handle the opaque thing, normally. R> I'm now using xforms 1.0.0, but the same behaviour was there with R> 0.88.1. R> How do I know whether I'm using that code from GraphicsImageXPM or R> not? Is this from latest cvs? Trunk or 1.2.x branch? JMarc
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
Jean-Marc Lasgouttes wrote: > > > "Rob" == R Lahaye <[EMAIL PROTECTED]> writes: > Rob> I'm using a fairly recent version of ImageMagick (5.4.7). This > Rob> version's convert produces a color output line > Rob> " c opaque" > Rob> which causes a horrible quality in the LyX-View. > Rob> Manually I have to do > Rob> convert -opaque black > > Do you use the xforms image loader or the LyX one? There is code in > GraphicsImageXPM to handle the opaque thing, normally. I'm now using xforms 1.0.0, but the same behaviour was there with 0.88.1. How do I know whether I'm using that code from GraphicsImageXPM or not? Cheers, Rob.
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
> "Rob" == R Lahaye <[EMAIL PROTECTED]> writes: Rob> Hi, Rob> After a useful communication with Herbert on my problem Rob> displaying xpm-files on the LyX canvas, we came to the following Rob> conclusion: Rob> I'm using a fairly recent version of ImageMagick (5.4.7). This Rob> version's convert produces a color output line Rob> " c opaque" Rob> which causes a horrible quality in the LyX-View. Rob> Manually I have to do Rob> convert -opaque black Do you use the xforms image loader or the LyX one? There is code in GraphicsImageXPM to handle the opaque thing, normally. JMarc
