-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Bryce Yancey
Sent: Saturday, August 07, 2004 11:09 AM
To: [EMAIL PROTECTED]
Subject: RE: Critical problem in new format (was: Support for new
Plucker features in the Parser.)
This will, however, make
This will break some old versions of the Zaurus (I think) viewer which
used the whole byte instead of bit 0 to mark continuation, but this was
before the official format for continuation markers was set, and it was
a long time ago, so I don't think we should worry about it.
Don't worry about
Michael Nordstrom wrote:
On Sun, Aug 08, 2004, Alexander R. Pruss wrote:
Then, if bit 1 is set, the last two bytes of the record
contain the byte offset to navigation data from start of record.
Putting the info at the end of the record is a great idea. Bit 1 is
already used to indicate that
On Mon, Aug 09, 2004, Alexander R. Pruss wrote:
It will be very easy to issue a patch for this.
Yes, a few lines of code added to UnDoc and UnZip. I think we should
provide patched versions of 1.6 and 1.8. Older versions could be
created on request.
/Mike
On Mon, Aug 09, 2004, Michael Nordstrom wrote:
Putting the info at the end of the record is a great idea.
I've updated the Plucker format description to include this info.
/Mike
___
plucker-dev mailing list
[EMAIL PROTECTED]
How about fixing the new format to be backwards-compatible, instead?
I think compatibility of the format extensions are paramount.
Bill
I found a critical problem in the new format when working on the
viewer implementation. The problem is that the viewer will not be
able to find
I think that a non-backwards-compatible file format change should be the
very last resort.
Doesn't the compressed data contain a compressed-length field somewhere
that the zlib library uses? If so, the viewer can use that to find the
end of the compressed data.
If not, then only a touch more
On Sun, Aug 08, 2004, Alexander R. Pruss wrote:
Then, if bit 1 is set, the last two bytes of the record
contain the byte offset to navigation data from start of record.
Putting the info at the end of the record is a great idea. Bit 1 is
already used to indicate that navigation data is
format
has been approved,
I found a critical problem in the new format when working on the
viewer implementation. The problem is that the viewer will not be
able to find the navigation data (put after the compressed text/image
data). One solution would be to add a new field to the header with
the size
It should be quite simple to write a script that could convert documents
from the new format to the old format (without the new features), though.
Would it be possible to make the viewer do this automagically, upon
opening an older format document? The problem I see with writing a script
to
On Sat, Aug 07, 2004, David A. Desrosiers wrote:
Would it be possible to make the viewer do this automagically, upon
opening an older format document?
Wrong direction ;-)
The problem with a non-backwards compatible change to the Plucker
format is that only new viewers would be able to
I found a critical problem in the new format when working on
the viewer implementation. The problem is that the viewer
will not be able to find the navigation data (put after the
compressed text/image data). One solution would be to add a
new field to the header with the size
On Sat, Aug 07, 2004, Bryce Yancey wrote:
do we want to consider changing the plucker format version
number (currently 2)?
Yes, the version number should be changed. At the moment the version
number isn't really much of a version number; it's more an indication
of the type of compression used
13 matches
Mail list logo
