Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-unix!sri-spam!mordor!lll-tis!ptsfa!dual!ucbvax!OHIO-STATE.ARPA!bob
From: bob@OHIO-STATE.ARPA (Bob Sutterfield)
Newsgroups: comp.windows.x
Subject: XReadBitmapF.c limit - feature or bug?
Message-ID: <8706161632.AA09966@ohio-state.ARPA>
Date: Tue, 16-Jun-87 12:32:18 EDT
Article-I.D.: ohio-sta.8706161632.AA09966
Posted: Tue Jun 16 12:32:18 1987
Date-Received: Sun, 21-Jun-87 08:35:28 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 29

Regarding Xv10r4 under SunOS 3.2 - I'm not sure whether this is a bug
report with a fix, or a request for clarification and enlightenment.
Since I didn't see an answer to the similar question posed by Dave
Curry (davy@pur-ee.uucp), I figure I'll ask again.

I wondered why xsetroot wouldn't do larger bitmaps, even with the
changes from dcmartin@postgres.mit.edu (David C. Martin) to go beyond
the 16x16 limitation.  Then in Xlib/XReadBitmapF.c, when looping for
the width, height, x_hot, and y_hot lines in the bitmap, we see:

    while ((status = fscanf (file, "#define %80s %2d\n", variable, &value))==2)
    	{...

The `%2d' specification limits us to 99x99 bitmaps.  When the `%2d' is
changed to `%d' the XReadBitmapFile() function seems to successfully
handle arbitrarily-large bitmaps, which is what I needed to put up
fullmoon.bitmap (1152x900) as my background pattern.

Is this an oversight, or an architectural feature, or a performance
sensitive limitation of this implementation, to guard against shipping
huge bitmaps to and fro?  What will break if I change the copy of
XReadBitmapFile() in our generally-accessible libX.a?

Thanks for any light you can shed.
------
 Bob Sutterfield, Department of Computer and Information Science
 The Ohio State University; 2036 Neil Ave. Columbus OH USA 43210-1277
 bob@ohio-state.{arpa,csnet} or ...!cbosgd!osu-eddie!bob
 soon: bob@aargh.cis.ohio-state.edu