Are you sure it hasn't been updated for so long? Take a look at the
PostScript 3 reference manual.
OK, 5 years instead of 6 (1998). But in today's world,
that's a HUGE time...
What you're looking at is a mature standard. Surely that's a good thing!
If it ain't broke, don't fix it.
Hi,
On Thu, 2003-08-14 at 22:58, Nathan Carl Summers wrote:
I haven't heard a single good argument for it except that it can do
most of the things that the XML/archive approach can do.
s/most/all, and many other good things besides.
Which are?
There was however nothing mentioned that
I won't take any stand on either side (or how many sides are there?) in
the ongoing discussion, just air some fresh thoughts...
Many of the image formats suggested are some kind of archive formats
(zip, ar) on the outside.
I understand that one important benefit from this is that you can
store
On Fri, 15 Aug 2003 13:49:41 +0300 (EET DST), Tor Lillqvist [EMAIL PROTECTED] wrote:
I won't take any stand on either side (or how many sides are there?) in
the ongoing discussion, just air some fresh thoughts...
taking a deep breath of fresh thoughts
[...]
Now, what concept do the ar, zip,
On Fri, Aug 15, 2003 at 01:57:35PM +0200, Raphaël Quinet wrote:
There is unfortunately one thing that most of these filesystems have
in common: they are designed to store their data in a partition that
has a fixed size. If you create such a filesystem in a regular file,
you have to
On Fri, Aug 15, 2003 at 01:57:35PM +0200, Raphal Quinet [EMAIL PROTECTED] wrote:
included directly while others are included by reference. The main
advantage of using XML is that it can easily be debugged by hand. The
other arguments that have been discussed so far (for or against XML)
are
I could be mistaken, but it doesn't seem that a file system with an
extensible size would be a big problem...
We make a request to store a file in our file system within a file, and
what we want to store exceeds the available capacity of our present file
system. No problem. Our file system's
On Thu, Aug 14, 2003 at 09:10:37PM +0200, Sven Neumann [EMAIL PROTECTED] wrote:
point where no image manipulation program has gone before. However there
is still the need for a good format for exchanging layered images
between applications. So perhaps it makes sense to also develop such an
I
On Fri, Aug 15, 2003 at 07:45:28AM -0500, Kevin Myers wrote:
| BTW, Microsoft Windows registry is already basically an extensible file
| system within a file. A high end business product that I use called also
| SAS has something similar. I would guess there are others out there as
| well.
You
[Re-sending this because I sent it to Kevin instead of the list. Grumble...]
On Fri, 15 Aug 2003 07:45:28 -0500, Kevin Myers [EMAIL PROTECTED] wrote:
I could be mistaken, but it doesn't seem that a file system with an
extensible size would be a big problem...
It may be a problem with
On Fri, Aug 15, 2003 at 03:02:46PM +0200, Tino Schwarze wrote:
| Subversion (http://subversion.tigris.org/) implements a versioned FS
| using a Sleepycat's Berkeley DB database. It has a full library
| implementation which any application could use.
|
| Well, using a database as container
On Fri, 15 Aug 2003, Tor Lillqvist wrote:
Date: Fri, 15 Aug 2003 13:49:41 +0300 (EET DST)
From: Tor Lillqvist [EMAIL PROTECTED]
To: The Gimp Developers' list [EMAIL PROTECTED]
Subject: Re: [Gimp-developer] Portable XCF
I won't take any stand on either side (or how many sides are there?) in
Tor wrote:
[filesystem within a file]
It's a nice idea in theory, but makes it quite hard to write a parser for.
MS Word files (until recently) were basically FAT filesystems, which makes
it easy to handle under Windows but harder to parse when you don't have a
convenient DLL to do it lying
On Fri, Aug 15, 2003 at 02:22:03PM +0100, Mukund wrote:
| Subversion (http://subversion.tigris.org/) implements a versioned FS
| using a Sleepycat's Berkeley DB database. It has a full library
| implementation which any application could use.
|
| Well, using a database as container might
Hi,
On Fri, 2003-08-15 at 15:22, Mukund wrote:
Even if your images are black and white, they are most likely stored in a
compressed format (if a Subversion based GIMP file format was ever
invented), and if such compressed files are revisioned, no
generic algorithm is going to give you a good
[EMAIL PROTECTED] (2003-08-15 at 1357.35 +0200):
There is unfortunately one thing that most of these filesystems have
in common: they are designed to store their data in a partition that
has a fixed size. If you create such a filesystem in a regular file,
you have to pre-allocate the space
On Fri, Aug 15, 2003 at 03:51:53PM +0200, Sven Neumann wrote:
Even if your images are black and white, they are most likely stored in a
compressed format (if a Subversion based GIMP file format was ever
invented), and if such compressed files are revisioned, no
generic algorithm is going
[EMAIL PROTECTED] (2003-08-15 at 1541.28 +0200):
BTW: Would it be possible to get a sparse file by zeroing the unused
bits? Then it would be quite space efficient (at least with some file
systems).
Yes, try it with dd and cp (GNU version only?):
dd if=/dev/zero of=/tmp/zero-test count=1000
cp
Yes, try it with dd and cp (GNU version only?):
dd if=/dev/zero of=/tmp/zero-test count=1000
cp --sparse=always /tmp/zero-test /tmp/zero-sparse
ls -l /tmp/zero-test /tmp/zero-sparse
du -cs /tmp/zero-test /tmp/zero-sparse
[...]
What I do not know is how many fs support it, and if they can
Leonard Rosenthol wrote:
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
Hi,
On Friday 15 August 2003 2:30 pm, Austin Donnelly wrote:
When this discussion started, I didn't like the idea of XML with binary
data portions. I liked the current binary, tagged, format we have, and
thought that it should just be extended. However, after the recent
discussion I've
Leonard Rosenthol wrote:
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
Nathan Carl Summers wrote:
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
Stephen J Baker wrote:
It seems to me that XML was just *made* to do (1) nicely. It's also
rather
nice that this is human readable and the parsers for it are likely to
be easy.
XML is nice and modern and there are loads of supporters of it. I
don't think
this should even be a matter of
BTW, what happened to GNOME's libefs? From quickly browsing the
sources, it seems to have been included in bonobo still in
bonobo-1.0.22, but then bonobo was renamed to libbonobo, and I don't
see any trace of it in libbonobo-2.3.6. Was it such a badly designed
disaster that it was dropped? Or did
Austin Donnelly wrote:
Yes, try it with dd and cp (GNU version only?):
dd if=/dev/zero of=/tmp/zero-test count=1000
cp --sparse=always /tmp/zero-test /tmp/zero-sparse
ls -l /tmp/zero-test /tmp/zero-sparse
du -cs /tmp/zero-test /tmp/zero-sparse
[...]
What I do not know is how many fs
26 matches
Mail list logo
