Re: [Gnome-print] Universal binary file format
- From: Lauris Kaplinski <lauris ariman ee>
- To: Miguel de Icaza <miguel helixcode com>
- cc: Morten Welinder <terra diku dk>, gnome-print helixcode com
- Subject: Re: [Gnome-print] Universal binary file format
- Date: Wed, 19 Apr 2000 11:10:04 +0200 (CEST)
On 19 Apr 2000, Miguel de Icaza wrote:
> > Then we'll start having compatibility problems - what if a program creates
> > gnome-print-metafile-1.2, but renderer can handle only 1.1? Current format
> > does not allow it to skip unknown commands, so it has simply give up -
> > thing I hate with most commercial programs/file formats - they refuse to
> > open file which contains only one bit information they cannot handle.
>
> Lauris, but this will happen with many many things more.
>
> In this case we do have an advantage over the example you illustrated
> before: you just need to upgrade the gnome-print library, as the new
> version of the library would contain the code to handle the new file
> format.
Maybe free software will change the way upgrade cycles are done in
corporate environment. But at moment many places are very reluctant
against upgrades, if they have already working solution.
If applications are bonoboized they should be ready for large
installations of mixed architectures and different file versions. So
forward compatibility really has its place.
> > The actual format of integers/floats can be different. Important point is
> > the possibility of skipping unknown chunks.
>
> I think this is actually a work-around the problem, but it would not
> guarantee correct output (while upgrading the library would).
>
> Ie, consider that one such command is "rotate 90 degrees", the output
> will be completely messed.
I hope that basic display capabilities will soon be good enough, that we
does not need to change anything in foreseeable future. And while
introducing new capabilities, it is usually possible to have nice backdrop
capability. That problem with current file format is, that ANY new command
will break completely the ability of older app/lib to render it.
Just imagine something like:
Command: set_hint
Value: "Use envelope feeder for this page"
It will break DISPLAY compatibility :(
I would still vote for adding chunk size parameter to metafile commands.
As of standard binary file format, does anybody know cases, where Gnome
applications need to create/parse large structured binary files:
- which are always single-stream (no need for efs)
- which need fast parsing/searching/skipping (no xml)
I just downloaded iff file format spec and will study it.
Lauris
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]