Oren@home.csc.ti.COM (LaMott Oren) (11/25/87)
While playing around with PolyText16 requests in CLX, I discovered that somewhere along the way the protocol was changed so font changes generate an odd number of bytes (5 instead of 6). Thus a strings16 after a font change is no-longer on a 16bit boundary. Why was this change made? Some feeble attempt at compatibility with PolyText8? Is it too late to fix it? While I'm asking, why was the decision made that the CLIENT do byte swapping for 16 bit text requests? Why are the formats of the ImageText requests different from PolyText? Everything else in the protocol seems (to me) to be very well thought out, so I figure there must be reasons for these text inconsistencies.
RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (11/26/87)
Date: Wed, 25 Nov 87 11:33:08 CST
From: LaMott Oren <Oren%home.csc.ti.com@RELAY.CS.NET>
While playing around with PolyText16 requests in CLX, I discovered that
somewhere along the way the protocol was changed so font changes
generate an odd number of bytes (5 instead of 6). Thus a strings16
after a font change is no-longer on a 16bit boundary. Why was this
change made? Some feeble attempt at compatibility with PolyText8?
Compatibility with PolyText8, and not deemed feeble. Also, given that
orientation is toward 2-bytes not 16-bit (see below), alignment was not
considered important.
Is it too late to fix it?
The answer should be obvious.
While I'm asking, why was the decision made
that the CLIENT do byte swapping for 16 bit text requests?
The client doesn't do byte swapping. You are under the misconception (I
don't fault you, it wasn't always this way) that PolyText16 is designed
for 16-bit indexes. It's really designed for 2-byte indexes, it's just
that we didn't change the name to PolyText2B. The two bytes are "first
byte" and "second byte", and there is no question of byte-swapping (the
first byte comes first, naturally). It was expected that clients would
actually pass in byte strings, with two bytes per glyph. However, we
permit folks to think of fonts with 16-bit indexes if they desire, but
we require them to always pass the indexes in big-endian order. The
issues and implications for Common Lisp were discussed in cl-windows a
while back, if you still have the mail.
Why are the
formats of the ImageText requests different from PolyText?
Umm, if you mean "why doesn't ImageText allow font changes and deltas",
the answer is that ImageText was designed for simple terminal emulators
using fixed-width fonts, where the complexity wasn't needed, and no one
asked for the capability (until too late).