At 8:45 AM -0700 8/12/03, Nathan Carl Summers wrote:
Not necessarily. You should be able to do it with any format
with a good catalog system, but some will be easier than others.
How would you handle resizes? Either we could do immediate compaction or
garbage collection. Both have their
At 6:13 AM -0700 8/14/03, Nathan Carl Summers wrote:
AFAICT, there is nothing stopping Gimp developers from creating a
potatoshop plugin that can read XCF.
That is definitely true! Absolutely nothing prevents this -
and certainly sounds like a great idea for someone...
You could get that
Hi,
I'd like to mention that none of the proposed formats except the XML
approach would be capable of supporting the stuff we want to add to GIMP
with GEGL. I don't think any existing format could be sanely extended to
support complex render graphs as will be introduced with GEGL. We are
not
At 8:32 PM -0300 8/13/03, Joao S. O. Bueno wrote:
People have considered TIFF, PSD in this newer thread - before the
Camp, on the list, we were almost closed in an ar archive, with XML
informatin and possibly PNG raster data inside.
Which is still a valid approach, but would DEFINITELY require
On Thu, 21 Aug 2003, Leonard Rosenthol wrote:
At 1:47 PM +0200 8/14/03, Sven Neumann wrote:
I'd like to mention that none of the proposed formats except the XML
approach would be capable of supporting the stuff we want to add to GIMP
with GEGL.
Well, that pretty much settles that
On Wed, Aug 20, 2003 at 08:54:55PM -0400, Leonard Rosenthol wrote:
At 11:42 PM + 8/13/03, Phil Harper wrote:
as for TIFF, you wouldn't be able to do it in a standard readable TIFF,
This, however, is wrong! We can represent EVERYTHING in
GIMP today, and EVERYTHING for GEGL (etc.)
Leonard Rosenthol wrote:
At 8:47 AM -0700 8/12/03, Nathan Carl Summers wrote:
This is what I mean by a standard that people can have confidence in --
people should trust that if their program writes good XCF's that a good
program will be able to read it.
Right!
If a program writes GOOD
[EMAIL PROTECTED] (2003-08-21 at 1016.13 -0400):
At 11:42 PM -0700 8/13/03, Manish Singh wrote:
Supports IEEE floats, but not float16 (a 32-bit float cut in half). RH
added this to filmgimp since they had established this format in their
workflow with other tools already.
Why would you only use
I've been trying now for three days to get 1.3 to work. When I compile the
latest source it seems to work fine. But when I run the gimp-1.3 it just
exits with the message:
The program 'gimp-1.3' received an X Window System error.
This probably reflects a bug in the program.
The error was
Phil Harper wrote:
From: Leonard Rosenthol [EMAIL PROTECTED]
To: Nathan Carl Summers [EMAIL PROTECTED]
CC: The Gimp Developers' list [EMAIL PROTECTED]
Subject: Re: [Gimp-developer] GimpCon RFC: Portable XCF
Date: Wed, 20 Aug 2003 10:40:51 -0400
At 8:45 AM -0700 8/12/03, Nathan Carl Summers wrote:
At 8:26 PM -0400 8/13/03, Carol Spears wrote:
What about mng? It contains png and has layers and comments.
Yes, but still has the limitations of no-CMYK (Lab, ICC,
etc.) colorspaces (among other things) out of the box...
Seems to be basically unmaintained.
PNG/MNG/JNG is fully supported and
On Thu, 14 Aug 2003, Øyvind Kolås wrote:
* Adam D. Moss [EMAIL PROTECTED] [030814 09:59]:
Stephen J Baker wrote:
So, I think what is needed to make a reliable file format is to provide
a well written library for reading and writing the files that's freely
available and properly
At 5:40 PM +0100 8/14/03, Mukund wrote:
On Wed, Aug 20, 2003 at 07:45:33PM -0400, Leonard Rosenthol wrote:
| Because Postscript is dead.
PostScript is far from dead. You would be banishing the entire publishing
industry if you say PostScript is dead :-)
I guess I should say that Postscript
Thank you for the comments.
I quite much agree with all of them, I just threw it in because I think
it'd more interesting than TIFF or PSD alltogether.
Quite informative is the part about Adobe patents.
I will no longer mention PS as a native file format, GSview is quite
good as a PS loader as
On Fri, 25 Jul 2003 22:23:23 +0200, David Neary [EMAIL PROTECTED] wrote:
http://bugzilla.gnome.org/show_bug.cgi?id=63610
[...]
It would be nice if preferences for plug-ins survived session
changes. The way to do this might be in saving them to an rc file
without providing an interface to
On 9 Aug 2003 at 18:35, Leonard Rosenthol wrote:
At 8:36 PM +0200 8/9/03, Dave Neary wrote:
Another reason may be that it is difficult to build the development
version because it depends on released versions of some libraries that
are not included yet in the major GNU/Linux distributions
Leonard Rosenthol wrote:
At 11:42 PM -0700 8/13/03, Manish Singh wrote:
GEGL uses XYZ as a native format.
Why? Lab is a richer model esp. for handling chromanicity and is
also a standard in the print world natively. Why limit to XYZ??
I am not sure what you mean by a richer model.
Guillermo S. Romero / Familia Romero wrote:
To some extent, it reminds me of the Blender format (with the add on
that Blender files are 64 or 32 bit, little or big endian, and all the
plataforms can load them fine... Adam will love it :] ).
I wrote a Blender file reading C library as part of
my
* Leonard Rosenthol [EMAIL PROTECTED] [030814 18:06]:
At 4:41 PM +0200 8/14/03, Øyvind Kolås wrote:
The baseline GEGL library will be exactly the baseline functionality
needed to be able to something useful with the file,. compositing the
layers, layer groups, and effect layers into a single
On Tue, Aug 05, 2003 at 09:45:46AM +0200, Raphal Quinet [EMAIL PROTECTED] wrote:
It would be nice if preferences for plug-ins survived session
changes. The way to do this might be in saving them to an rc file
without providing an interface to changing them in the normal
I doubt that we
Adam D. Moss wrote:
Okay, in that case I think I must have made a mistake in
the forward-port of the 1.2.x fix to 1.3.x, because I can't
reproduce this in my 1.2.x tree with the equivilent GIF plugin
4.01.00 fix in it.
I'll try to spot what the forward-port does differently.
I can't see anything
Steven P. Ulrick wrote:
How do I reproduce the problem -- would I be right in thinking
that if I load the GIF above, then re-save it again and re-load
the result then the resulting GIF will have a pink background?
I answered this question in my response above, but to reiterate, the
answer is yes,
It is probably this checkin:
http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=contextwhitespace_mode=showfile=gifload.cbranch=root=/cvs/gnomesubdir=/gimp/plug-ins/commoncommand=DIFF_FRAMESETrev1=1.30rev2=1.31
The guchar - gchar change without correcting the code using the buf
isn't probably
Hi !
I have some problems, to print with gimp-1.3 and gimp-print.
Here is my setup:
I need =gimp-print-4.3.18, because with my Epson Photo 950, this is the
only
driver, that gives very good printing results. (with CUPS/KDE...)
gimp-print-4.3.18 with option --with-gimp needs gimp-1.2 to
Austin Donnelly wrote:
How is the serialization done then, just a raw 32-bit IEEE float
dump with a predefined endianness? 64-bit doubles just as easy?
The real problem comes when your code is running on a system without IEEE
float support, and you need to manually convert from IEEE float to your
Leonard Rosenthol wrote:
At 8:26 PM -0400 8/13/03, Carol Spears wrote:
What about mng? It contains png and has layers and comments.
Yes, but still has the limitations of no-CMYK (Lab, ICC, etc.)
colorspaces (among other things) out of the box...
The last time I got the mng libraries,
Leonard Rosenthol wrote:
At 6:51 PM -0700 8/13/03, Manish Singh wrote:
Does TIFF support, for example, float16 data, or a CIE XYZ colorspace?
Yes to both...
I'm somewhat concerned with going with an externally standardized
format,
then running into a wall with it at some later point,
On Mon, 11 Aug 2003, Adam D. Moss wrote:
Nathan Carl Summers wrote:
On Mon, 11 Aug 2003, Adam D. Moss wrote:
IIRC, the Loki guys. Some ramblings a few years ago on the
problems of interoperability of game data between
windows/mac/linuxx86/linuxalpha/etc over network and on disk.
They made
At 1:47 PM +0200 8/14/03, Sven Neumann wrote:
I'd like to mention that none of the proposed formats except the XML
approach would be capable of supporting the stuff we want to add to GIMP
with GEGL.
Well, that pretty much settles that discussion...
So let's start talking XML + archive again,
Jeff Trefftzs wrote:
On Mon, 2003-08-11 at 08:49, Adam D. Moss wrote:
Hi.
Jeff Trefftzs wrote:
Without getting fancy, I just tried this image in gimp-1.3.18 (Linux,
RedHat 9). It opened with the pink background
Wait, it OPENED with the pink background? You didn't have
to save it out again
At 10:06 AM +0200 8/14/03, Øyvind Kolås wrote:
Which is why I in an earlier mail suggested developing a GEGL file format
that gimp could extend and use a subset of. By doing it this way, gegl
would be the aforementioned file loading, and compositing library,.
But that seems like an EXTREMELY
Hi all,
So, I made my plane (thanks to Roman drc), and am now kind of recovered. I
had hoped to get some computer time after a few days to take care of some
backlog stuff, and keep abreast of bugs for 1.3.19... unfortunately, it now
looks like I'm going to have very limited time over the
On Thu, Aug 14, 2003 at 01:34:01PM -0400, Leonard Rosenthol wrote:
|
| Implementing a full PDF parser is definitely much harder than a full
| PostScript parser. PDF more or less encompasses PostScript.
|
| You are quite misinformed...
|
| PDF is a static file format of structured
At 3:33 PM -0400 8/14/03, Carol Spears wrote:
So this combination would answer your LAB CMYK issues and possibly
my need to use a greater than 256 color palette then?
No, it would not.
ICC profiling is a VERY different thing that actual raw
CMYK or Lab data...
Paletizing of an image is
Hello. Recently I posted the following enhancement proposal:
http://bugzilla.gnome.org/show_bug.cgi?id=119240
Basically, it's about adding dynamic brush features. Right now, the only non-tablet controled dynamic brush feature is color, with the gradient brush, so I'm suggesting that something
Stephen J Baker wrote:
Austin Donnelly wrote:
How is the serialization done then, just a raw 32-bit IEEE float
dump with a predefined endianness? 64-bit doubles just as easy?
The real problem comes when your code is running on a system without IEEE
float support, and you need to manually
Quoting Henrik Brix Andersen [EMAIL PROTECTED]:
On Mon, 2003-08-11 at 15:00, Raphaël Quinet wrote:
Here is what was discussed, according to the minutes of the Second
GIMPCon meeting written by Dave (and double-checked by comparing with
my own notes, just in case):
1 or 2 developer
At 7:52 PM +0200 8/14/03, Guillermo S. Romero / Familia Romero wrote:
The spec is only updated every 18-24 months when Adobe
releases a new version of Photoshop - so you definitely don't wait
for that! As for the other, yes, that is true you could wait, but
nobody does...
Where are those
On Wed, 20 Aug 2003, Leonard Rosenthol wrote:
At 11:42 PM + 8/13/03, Phil Harper wrote:
well, it'd be interesting to see if Adobe added XCF to Photo$hop,
after all, GIMP is the competition, it wouldn't be in their
interests to support a multilayered image format that it controlled
by
On Thu, 14 Aug 2003, Sven Neumann wrote:
[Note: quote blocks have been reordered for clarity]
Hi,
I'd like to mention that none of the proposed formats except the XML
approach would be capable of supporting the stuff we want to add to GIMP
with GEGL.
On the contrary, my proposal would
On Mon, 11 Aug 2003 12:30:10 +0100
Adam D. Moss [EMAIL PROTECTED] wrote:
Steven P. Ulrick wrote:
http://www.faith4miracle.org/FaithLogo-circle.gif
...
the image always displays properly before I open it in Gimp 1.3.17
or 1.3.18. Whenever I have saved one of the images that was given a
On Mon, 11 Aug 2003, Guillermo S. Romero / Familia Romero wrote:
[EMAIL PROTECTED] (2003-08-08 at 1801.54 -0700):
Portable XCF would use a chunk system similar to PNG, with two major
differences. First, chunk type would be a string instead of a 32-bit
value. Second, chunks can contain an
At 11:42 PM -0700 8/13/03, Manish Singh wrote:
Supports IEEE floats, but not float16 (a 32-bit float cut in half). RH
added this to filmgimp since they had established this format in their
workflow with other tools already.
Why would you only use half of a 32bit float?? That reduces
your
How is the serialization done then, just a raw 32-bit IEEE float
dump with a predefined endianness? 64-bit doubles just as easy?
Yup.
The real problem comes when your code is running on a system without IEEE
float support, and you need to manually convert from IEEE float to your
local
Several XCF formats have already been proposed; why should I propose
another? It seems to me like the existing proposals have all missed the
main point. While they have nice properties for certain extreme cases,
they miss the boat when it comes to the main point of a graphics format,
which is to
On Thu, Aug 21, 2003 at 01:33:50AM -0400, Leonard Rosenthol wrote:
why would i want to save to a file format that would render my image
that's built up of layer masks and vector text layers really badly
if opened in a standard viewer
Because at least you COULD open it up in a
On Wed, Aug 20, 2003 at 07:45:33PM -0400, Leonard Rosenthol wrote:
|
| Because Postscript is dead. It hasn't been updated in over 6
| years, and Adobe themselves are slowly moving towards PDF-based
| solutions, including printing.
PostScript is far from dead. You would be banishing the
[EMAIL PROTECTED] (2003-08-08 at 1801.54 -0700):
7 able to support many color depth and spaces
PNG certainly supports 1,2,6,7,9,10, and 11. Let us examine the other
IIRC (did I read the spec wrongly maybe?) the upper limit is RGBA with
16 bit per channel, no arbitrary color spaces or data
On 13 Aug 2003, at 5:32, Tor Lillqvist wrote:
www.gimp.org/win32/gimp-head-20030813.zip.
Perhaps I read over this somewhere, but GIMP HEAD for Windows also
seems to require libart. The libart for Windows I downloaded from
somewhere off the internet had to be renamed to libart_lgpl_2-2.dll.
On Sat, 9 Aug 2003, Leonard Rosenthol wrote:
I see fast loads as an absolute requirement.
Then we need to also look at the GIMP itself and what can be
done there.
Of course.
Hopefully, GIMP's file handling will improve to the point where it will
load thing on an as-needed basis.
[EMAIL PROTECTED] (2003-08-12 at 1721.12 +0100):
Right now, the only non-tablet controled dynamic brush feature is
color, with the gradient brush,
Direction works too.
Now, as I pointed out in Bugzilla, I've since found out that
Photoshop 7 has some new dynamic features (see screenshots
Nathan Carl Summers wrote:
On Mon, 11 Aug 2003, Adam D. Moss wrote:
IIRC, the Loki guys. Some ramblings a few years ago on the
problems of interoperability of game data between
windows/mac/linuxx86/linuxalpha/etc over network and on disk.
They made a special point of saying something like 'never,
On Tue, 12 Aug 2003, Austin Donnelly wrote:
How is the serialization done then, just a raw 32-bit IEEE float
dump with a predefined endianness? 64-bit doubles just as easy?
Yup.
The real problem comes when your code is running on a system without IEEE
float support, and you need to
On Tue, 5 Aug 2003 11:51:05 +0200, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote:
On Tue, Aug 05, 2003 at 09:45:46AM +0200, Raphaël Quinet [EMAIL PROTECTED] wrote:
It would be nice if preferences for plug-ins survived session
changes. The way to do this might be in saving them to an rc
At 6:29 PM +0200 8/14/03, Øyvind Kolås wrote:
Then you jsut want to be able to understand the XML file, which is the
reason I proposed using something like xml in the first place, the rest
of the logic would then be contained in your application.
Well, yes, I need to understand the FILE
On Thu, 14 Aug 2003, Sven Neumann wrote:
Hi,
I never understood the reasoning for this discussion anyway. IMHO the
format that Nathan suggested seems like something from the dark ages of
file formats (where TIFF and the like originated from).
PNG is something from the dark ages?
I
On 13 Aug 2003, at 21:00, Pedro Gimeno wrote:
Branko Collin [EMAIL PROTECTED] wrote:
I got mine from
http://gnuwin32.sourceforge.net/packages/libart.htm. That version
is more recent, though, so I had to rename it. I don't know if that
has any averse effects, but at least it allowed me to
On 11 Aug 2003 at 1:57, Tor Lillqvist wrote:
Michael Schumacher writes:
The result of make after creating the libintl.a libiconv.a files:
Creating library file: .libs/libgimpui-1.3.dll.a
.libs/gimpui.o(.text+0x159):gimpui.c: undefined reference to
`gimp_min_colors'
Leonard Rosenthol wrote:
At 9:33 PM -0400 8/13/03, Carol Spears wrote:
The last time I got the mng libraries, they came along with liblcms.
Are you sure that liblcms does not do all of this?
A quick reread of the PNG/MNG format reveals that you can use ICC
profiles, but NOT CMYK, Lab or
At 3:03 AM + 8/14/03, Phil Harper wrote:
the last thing Adobe wants to do is support XCF, it's a competing
format belonging to a competing(and competatively priced) app.
Actually, the fact that it comes from GIMP has NOTHING to do
with. The fact that few (if any) of theirs users are asking
Sven Neumann wrote:
I never understood the reasoning for this discussion anyway. IMHO the
format that Nathan suggested seems like something from the dark ages of
file formats (where TIFF and the like originated from). I haven't heard
a single good argument for it except that it can do most of the
On Wed, 13 Aug 2003 23:42:36 -0700, Manish Singh [EMAIL PROTECTED] wrote:
On Thu, Aug 21, 2003 at 01:38:01AM -0400, Leonard Rosenthol wrote:
At 8:12 PM -0700 8/13/03, Manish Singh wrote:
What's the turnaround time for that? Taking weeks or months isn't really
acceptable...
It's
At 4:41 PM +0200 8/14/03, Øyvind Kolås wrote:
The baseline GEGL library will be exactly the baseline functionality
needed to be able to something useful with the file,. compositing the
layers, layer groups, and effect layers into a single image. And in that
process handling the various kinds of
On Tue, 2003-08-12 at 20:02, Dave Neary wrote:
Being honest, I wanted to do a release wile I had Sven beside me :) And there
will still be another release in a couple of weeks when people commit what they
were working on/started in camp.
Ahh, good - that makes sense. I initially thought our
At 6:51 PM -0700 8/13/03, Manish Singh wrote:
Does TIFF support, for example, float16 data, or a CIE XYZ colorspace?
Yes to both...
I'm somewhat concerned with going with an externally standardized format,
then running into a wall with it at some later point, and not being able
to add a feature
Carol Spears wrote:
However, I read recently about artifacts appearing in compressed pngs,
so this might not be the miracle fix I had hoped for.
!!!
Where did you see that?
PNG uses a lossless compression scheme - if there are 'artifacts' in the
image that were not there when the image was
hmm...Agreeded.
I'd suggest 10 days instead of 5 (if I, for an example, am on a heavy
workload week, 5 days could not be enough to make my points, if they
need soem expermenting on the codebase), But since the decision was
taken, so mote it be - it's not gonna hurt.
later it was agreed
Branko Collin [EMAIL PROTECTED] wrote:
I got mine from
http://gnuwin32.sourceforge.net/packages/libart.htm. That version
is more recent, though, so I had to rename it. I don't know if that
has any averse effects, but at least it allowed me to run the GIMP.
Thank you very much. Now I've got
On Mon, 11 Aug 2003 14:57:00 +0200, Branko Collin [EMAIL PROTECTED] wrote:
On 11 Aug 2003, at 2:45, Dave Neary wrote:
This is the latest in the development series of the GIMP. This will
very soon be a pre-release version for the GIMP 2.0, so all testing
efforts are appreciated to help us
Leonard Rosenthol wrote:
At 8:26 PM -0400 8/13/03, Carol Spears wrote:
What about mng? It contains png and has layers and comments.
Yes, but still has the limitations of no-CMYK (Lab, ICC, etc.)
colorspaces (among other things) out of the box...
Has anyone considered going to the PNG
At 8:47 AM -0700 8/12/03, Nathan Carl Summers wrote:
This is what I mean by a standard that people can have confidence in --
people should trust that if their program writes good XCF's that a good
program will be able to read it.
Right!
If a program writes GOOD XCF...
As long as a program
[EMAIL PROTECTED] (2003-08-08 at 1801.54 -0700):
Portable XCF would use a chunk system similar to PNG, with two major
differences. First, chunk type would be a string instead of a 32-bit
value. Second, chunks can contain an arbitrary number of subchunks, which
of course can contain subchunks
On Thu, Aug 21, 2003 at 10:16:13AM -0400, Leonard Rosenthol wrote:
At 11:42 PM -0700 8/13/03, Manish Singh wrote:
Supports IEEE floats, but not float16 (a 32-bit float cut in half). RH
added this to filmgimp since they had established this format in their
workflow with other tools already.
* Leonard Rosenthol [EMAIL PROTECTED] [030814 16:33]:
At 10:06 AM +0200 8/14/03, Øyvind Kolås wrote:
Which is why I in an earlier mail suggested developing a GEGL file format
that gimp could extend and use a subset of. By doing it this way, gegl
would be the aforementioned file loading, and
On Wed, Aug 13, 2003 at 08:32:00PM -0300, Joao S. O. Bueno wrote:
| But on this new thread were proprietary formats batle along with mutant
| ideas, here I go:
| Why not settle for a Postscript subset?
PostScript is a proprietary format controlled by Adobe. Adobe has several
patents on various
At 8:12 PM -0700 8/13/03, Manish Singh wrote:
On Wed, Aug 20, 2003 at 10:53:14PM -0400, Leonard Rosenthol wrote:
At 6:51 PM -0700 8/13/03, Manish Singh wrote:
Does TIFF support, for example, float16 data, or a CIE XYZ colorspace?
Yes to both...
Hmm, got a reference to that? It wasn't
* Adam D. Moss [EMAIL PROTECTED] [030814 09:59]:
Stephen J Baker wrote:
So, I think what is needed to make a reliable file format is to provide
a well written library for reading and writing the files that's freely
available and properly maintained on every modern platform FROM DAY ONE.
I
Tor Lillqvist [EMAIL PROTECTED] wrote:
www.gimp.org/win32/gimp-head-20030813.zip.
Thank you so much!
I couldn't satisfy the dependency on libart_lgpl_2-2.dll though. Any clue on
where to find a working libart binary DLL?
Pedro Gimeno
___
On Thu, Aug 21, 2003 at 01:38:01AM -0400, Leonard Rosenthol wrote:
At 8:12 PM -0700 8/13/03, Manish Singh wrote:
On Wed, Aug 20, 2003 at 10:53:14PM -0400, Leonard Rosenthol wrote:
At 6:51 PM -0700 8/13/03, Manish Singh wrote:
Does TIFF support, for example, float16 data, or a CIE XYZ
* Nathan Carl Summers [EMAIL PROTECTED] [030813 15:39]:
dunno why an editor should do progressive load. Load smaller res in
case of problem? I would try to avoid that instead of try to fix it,
with proper storage and transmission. Load with proxy images? Too
rough, IMO, it is not a scaled
At 1:58 PM -0700 8/14/03, Nathan Carl Summers wrote:
XML is a text markup language. If the designers thought of using it for
raster graphics, it was an afterthought at best.
Completely agreed. Putting image data into the XML would be bad...
The XML/archive idea is the software equivalent of
Leonard Rosenthol [EMAIL PROTECTED] writes:
With a bunch of work, you can use GS to print to Windows - but not
to every printer (I don't believe GIMP-print, for example, works on
Windows).
There's nothing fundamental stopping you. I've built it under Cygwin
and run the testsuite, and there
From: Leonard Rosenthol [EMAIL PROTECTED]
To: Nathan Carl Summers [EMAIL PROTECTED]
CC: The Gimp Developers' list [EMAIL PROTECTED]
Subject: Re: [Gimp-developer] GimpCon RFC: Portable XCF
Date: Wed, 20 Aug 2003 10:40:51 -0400
At 8:45 AM -0700 8/12/03, Nathan Carl Summers wrote:
Not necessarily.
[EMAIL PROTECTED] (2003-08-14 at 1440.34 -0400):
The updates were originally done as technical notes, now they
are incorporated into the main TIFF v7 spec which is part of the
Photoshop SDK.
They seem to be very friendly and open about it:
From
On 13 Aug 2003, at 19:30, Pedro Gimeno wrote:
Tor Lillqvist [EMAIL PROTECTED] wrote:
www.gimp.org/win32/gimp-head-20030813.zip.
Thank you so much!
I couldn't satisfy the dependency on libart_lgpl_2-2.dll though. Any
clue on where to find a working libart binary DLL?
I got mine from
Stephen J Baker wrote:
So, I think what is needed to make a reliable file format is to provide
a well written library for reading and writing the files that's freely
available and properly maintained on every modern platform FROM DAY ONE.
I agree with this -- I think it's really important.
Adam D. Moss wrote:
Tom Mraz wrote:
The guchar - gchar change without correcting the code using the buf
isn't probably good idea?
I think you're right. That bogus change totally sneaked under
my radar... (heads will roll! :D :D :D )
If someone who sees the problem can test this fix:
On Mon, 2003-08-11 at 07:33, Adam D. Moss wrote:
Adam D. Moss wrote:
Okay, in that case I think I must have made a mistake in
the forward-port of the 1.2.x fix to 1.3.x, because I can't
reproduce this in my 1.2.x tree with the equivilent GIF plugin
4.01.00 fix in it.
I'll try to spot
www.gimp.org/win32/gimp-head-20030813.zip.
Haven't really tested GIMP HEAD much at all myself, but it starts OK
and some random painting and filtering did work.
Bug reports to bugzilla, please.
Plase don't tell end-users yet, until I have had a chance to do some
more testing myself, to avoid
Tom Mraz wrote:
If someone who sees the problem can test this fix:
http://icculus.org/~aspirin/gifload.c that'd be good.
I've tested it and it fixes the bug.
Thanks all, the fix is in.
--Adam
--
Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3
I am NOT a nut! I am the
On 11 Aug 2003, at 4:26, Steven P. Ulrick wrote:
I've had this problem for the last two development versions of the
Gimp: 1.3.17 and 1.3.18
Hopefully, to maximize the clarity of the information that I have to
give you, and minimize the size of this e-mail, I will proceed with a
series of
Nick Lamb wrote:
On Sun, Aug 10, 2003 at 03:02:41AM +0100, Adam D. Moss wrote:
Another data point is that floats are just a bastard to serialise
in a portable, precise manner. Personally I'd represent a 32-bit
float with a 32-bit integer and 32-bit fixed-point fractional part.
Redundant but
On Mon, 11 Aug 2003 10:58:10 +0100
Adam D. Moss [EMAIL PROTECTED] wrote:
Can you provide a copy of the GIF in question?
To be clear, this only happens to the GIF when when you SAVE it
out from .17 or .18? If so, do you see any warnings on the
console when you save from these versions?
On Mon, 2003-08-11 at 15:00, Raphaël Quinet wrote:
Here is what was discussed, according to the minutes of the Second
GIMPCon meeting written by Dave (and double-checked by comparing with
my own notes, just in case):
1 or 2 developer releases(one now, more or less, and another one in
Michael Schumacher writes:
The result of make after creating the libintl.a libiconv.a files:
Creating library file: .libs/libgimpui-1.3.dll.a
.libs/gimpui.o(.text+0x159):gimpui.c: undefined reference to `gimp_min_colors'
.libs/gimpui.o(.text+0x170):gimpui.c: undefined reference to
On Fri, 8 Aug 2003, [iso-8859-1] Øyvind Kolås wrote:
Date: Fri, 8 Aug 2003 21:36:05 +0200
From: [iso-8859-1] Øyvind Kolås [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Ideas for Gimp/GEGL file format.
Sven could you forward this to the list, my mailing possiblities from the
camp is
On Sun, 27 Jul 2003 14:23:03 +0200, David Neary [EMAIL PROTECTED] wrote:
Jakub Steiner wrote:
On Fri, 2003-07-25 at 22:27, David Neary wrote:
http://bugzilla.gnome.org/show_bug.cgi?id=78730
It would be nice if the Ctrl modifier did for the move tool what
it did for other tools and
Alan Horkan wrote:
I feel that way too, unfortunately it is so hard not to react in the same
way and get off the downward spiral. I only very grudginly subscribed to
the developer list at all.
I feel that the active lead developer(s) need to admit this is not a
democracy and be the bad guy, be
At 8:36 PM +0200 8/9/03, Dave Neary wrote:
Another reason may be that it is difficult to build the development
version because it depends on released versions of some libraries that
are not included yet in the major GNU/Linux distributions (e.g., GTK+
version 2.2.2). Also, the number of
Hi again,
Sorry I forgot to send the mail from yesterday to the users list - I will
correct that in a moment.
So here is my notes from the second big meeting we had last night, which covers
the upcoming release schedule, things which are considered blockers to 2.0
pre-releases, and how we plan
1 - 100 of 101 matches
Mail list logo
