maybe OT, but ...

[Helge Blischke]

Michael Sweet wrote:
> Helge Blischke wrote:
> 
>> Michael Sweet wrote:
>>
>>> Helge Blischke wrote:
>>>
>>>> Today I encountered a weird thing:
>>>>
>>>> printing the same job (consisting of pages of scanned images, the data
>>>> runlength and ascii85 encoded) from an intel based box (both Linux and
>>>> UnixWare) prints OK, but when printing from a sparc-solaris box 
>>>> (Solaris 9)
>>>> produces weird PostScript errors just after the first or 3rd image.
>>>>
>>>> The issue is independent of the data transfer protocol used - I tested
>>>> IPP, AppSocket, and FTP.
>>>>
>>>> Has enybody encountered similar errors?
>>>
>>>
>>>
>>> Not here.
>>>
>>> Can you run the pstops filter manually on each system and diff the
>>> output?
>>>
>>
>> Well, forget my last reply - I just compared/printed only the first pages
>> which *where* (and still *are*) identical. The differences occur later 
>> on.
>> It is obviously a matter of the pages array in the pstops filter 
>> (remember,
>> I'm still using CUPS 1.1). I suspect there is some quirk with the 
>> large file
>> support on Solaris - I'll have to compile in a couple or diagnostic 
>> messages,
>> and see what happens.
> 
> 
> Keep in mind that CUPS 1.1.x does *not* support print files larger
> than 2GB - that requires CUPS 1.2.
> 

Issue solved. It affects only the alternate pstops filter when suing the same-up option.

The issue is as follows:
- on Solaris, the temporary file which is opened for update ("wb+") requires a fseek call
   when a file read is followed by a write, even if the file position after the
   read should be the correct one. Obviously on Solaris the file pointer for writing
   gets disturbed by reading in an unpredictable way. (tested on Solaris 2.5.1 and 9).
   The same is true for SunOS 4.1.1
- On Linux (various distributions/kernel versions) and UnixWare this additional seek
   is not required.

One more bug I found with SunOS 4.1.1: the fdopen call with type "wb+" produced no
error but prevented reading from the file (errno == 2), but "w+b" works as expected.
As both variants are permitted according to the POSIX rules, the latter should be
preferred whereever the "b" for "binary" is requested (though it is irrelevant
on all UNIXes I know of).

Helge


-- 
Helge Blischke
Softwareentwicklung
SRZ Berlin | Firmengruppe besscom
http://www.srz.de