Angus Leeming wrote:
> Let's not say wrong, but that libXPM doesn't like it.
>
> I seem to remember that it had problems when there was more than one char per
> pixel.
I installed a converter from tgif->gif and than all works
well.
Herbert
--
http://www.lyx.org/help/
On Tuesday 12 February 2002 8:18 pm, Herbert Voss wrote:
> Angus we had this error some days ago. Is this also a wrong xpm image?
>
> from: tgif -> xpm
> Tgif Version 4.1 (patchlevel 40)
>
> Copyright (C) 1990-2000, William Chia-Wei Cheng
>
> Reading 'testconfiguration-inres.obj'...
> XPM file
On Tue, Feb 12, 2002 at 07:38:27PM +, Angus Leeming wrote:
> + string const possible_output_file = RemoveExtension(params.filename) + to;
> + if (isFileReadable(possible_output_file)) {
> + // the output file is already present.
> + return possible_output_file;
Angus we had this error some days ago. Is this also a wrong xpm image?
from: tgif -> xpm
Tgif Version 4.1 (patchlevel 40)
Copyright (C) 1990-2000, William Chia-Wei Cheng
Reading 'testconfiguration-inres.obj'...
XPM file [321x301] printed into 'testconfiguration-inres.xpm'.
imageConverted, conve
On Tuesday 12 February 2002 7:55 pm, Herbert Voss wrote:
> Angus Leeming wrote:
>
> > A dumb quetion perhaps: why are we converting thes graphics files without
> > first checking that the desired output file doesn't already exist. This
is
> > the suggested code in InsetGraphics::prepareFile, b
Angus Leeming wrote:
> A dumb quetion perhaps: why are we converting thes graphics files without
> first checking that the desired output file doesn't already exist. This is
> the suggested code in InsetGraphics::prepareFile, but it's equally true in
> GraphicsCacheItem::convert.
>
> Am I mis
A dumb quetion perhaps: why are we converting thes graphics files without
first checking that the desired output file doesn't already exist. This is
the suggested code in InsetGraphics::prepareFile, but it's equally true in
GraphicsCacheItem::convert.
Am I missing something obvious?
Angus
s
I can't make sense of this. Why do we check the display status before
converting to EPS or other output format?
I'm going to scrap it if nobody explains else.
A
string const InsetGraphics::prepareFile(Buffer const *buf) const
{
// first check if file is viewed in LyX. First local
On Friday 08 February 2002 1:41 pm, Herbert Voss wrote:
> Angus Leeming wrote:
>
> > My question: if the output file needs to be converted (to eps, png etc),
then
> > this conversion is always going to result in bitmap (rather than vector)
> > data. So, does it matter if we start from the orig
Angus Leeming wrote:
> My question: if the output file needs to be converted (to eps, png etc), then
> this conversion is always going to result in bitmap (rather than vector)
> data. So, does it matter if we start from the original file, or from the
> pixmap stored in memory (if it has been c
getting there...
I have a graphics cache that ALWAYS stores the image data, but only starts
loading the image if it receives an explicit request to do so from
InsetGraphics::draw(). Moreover, if the InsetGraphicsParams::display variable
is set to NONE, then it's intelligent enough not to start
On Monday 29 October 2001 5:29 pm, Dekel Tsur wrote:
> On Mon, Oct 29, 2001 at 05:11:40PM +, John Levon wrote:
> > On Mon, Oct 29, 2001 at 12:18:13PM +0100, Angus Leeming wrote:
> >
> > > I'm using "convert" to create my original pixmap and convert has a
-geometry
> > > option that enables
On Monday 29 October 2001 5:11 pm, John Levon wrote:
> On Mon, Oct 29, 2001 at 12:18:13PM +0100, Angus Leeming wrote:
>
> > I'm using "convert" to create my original pixmap and convert has a
-geometry
> > option that enables me to specify the dimensions of the final pixmap, but
the
> > colour
On Mon, Oct 29, 2001 at 05:11:40PM +, John Levon wrote:
> On Mon, Oct 29, 2001 at 12:18:13PM +0100, Angus Leeming wrote:
>
> > I'm using "convert" to create my original pixmap and convert has a -geometry
> > option that enables me to specify the dimensions of the final pixmap, but the
> > c
On Mon, Oct 29, 2001 at 12:18:13PM +0100, Angus Leeming wrote:
> I'm using "convert" to create my original pixmap and convert has a -geometry
> option that enables me to specify the dimensions of the final pixmap, but the
> colours of this scaled pixmap are junk:
>
> ". c #0b680b680b68",
Maybe someone can help.
I have been playing with my attempt to load graphics in the background so
that we can continue to use LyX whilst the conversion is taking place. I've a
little test program that works fine althoufh the conversion is currently
hardcoded. The pixmap is finally displayed as
On Sunday 21 October 2001 06:43, Garst R. Reese wrote:
> How do I get the LyX view to update?
> I have a .eps file generated from a .fig with export.
> Changing the .eps file has no effect in LyX, even if I change page %
> update ps shows the changes, but even closing and reopening the file
> does
On Friday 14 September 2001 17:36, Juergen Spitzmueller wrote:
> Am Freitag, 14. September 2001 17:13 schrieb Baruch Even:
> > I believe that the only place missing for jpg is the filename regex,
> > if my memory serves me right, there should be no problem beyond that.
>
> Nice. I didn't encounte
Am Freitag, 14. September 2001 17:13 schrieb Baruch Even:
> I believe that the only place missing for jpg is the filename regex,
> if my memory serves me right, there should be no problem beyond that.
Nice. I didn't encounter any problems either. Could then someone apply/
change this, please?
T
I believe that the only place missing for jpg is the filename regex, if my
memory serves me right, there should be no problem beyond that.
On Fri, 14 Sep 2001, Juergen Spitzmueller wrote:
> Michael Schmidt wrote:
> - The new graphics inset supports file extension ".jpeg" but not ".jpg".
> I thi
Michael Schmidt wrote:
- The new graphics inset supports file extension ".jpeg" but not ".jpg".
I think the latter is also commonly used. Can it be supported?
Is this really all that needs to be done (works for me) or are there real problems
with ".jpg"-files?
Excuse me if the answer is obvious
21 matches
Mail list logo
