Update:
In 4_9s, if connected over sgifaceserver, a command that outputs a gif
image to standard output:
> gif map mymap;gifdump -
will include the trailing NULL (from the C-string?) after the first line:
// 11052 bytes
^@GIF89a....
Only sgifaceserver will do this. The giface client will not include
trailing NULLs if printing to standard output.
AcePerl's obj->asGif method will fail producing a valid gif-file from this
output, as it will not split away the NULL byte in front of GIF89a.
Following change in Ace::Object.pm will fix it. It's not the correct fix
(which should be made in AceDB source, not in AcePerl), however, just a
workaround.
Object.pm line 1764, Aceperl 1.86:
- return unless ($bytes, $trim) = $data=~m!^// (\d+) bytes\n(.+)!sm;
+ return unless ($bytes, $trim) = $data=~m!^// (\d+) bytes\n\x0?(.+)!sm;
But I'm still interested to know if others have seen this problem, or if I
just screwed something up. I have it on two diffent machines though..
MHu
On Mon, 7 Jul 2003, Morten Hulden wrote:
>> After upgrading to ACEDB_4.9s, sgifserver seems to provide gif-images
> where the first byte is NULL and the last byte is dropped.
>> AcePerl now outputs faulty gifs with the obj->asGif method (Object.pm). As
> AcePerl has not changed, and giface client produces good gifs I assume
> something changed in sgifserver. Anyone else seen this?
>> I also tested 4.9u with same results.
> Compiled with gcc 3.2.2 on Linux RH9, -O2/-03 optimation.
>> MHu
>
