john@acorn.co.uk (John Bowler) (01/05/90)
The ImageText8 and ImageText16 protocol requests are defined to fill in a background rectangle of width ``overallWidth''; where overallWidth is the sum of the character width metrics. So what happens if this quantity is negative? (Quite likely with a RightToLeft font). The sensible interpretation is to fill in a rectangle of width overall-width with an upper *right* corner at (x, y-fontAscent). This achieves what the application program probably expects with a RightToLeft font (ie that the background of each character gets set, so long as the character origins are at the right hand side of the character). If this interpretation is correct, is the pixel (x,y-fontAscent) filled in? If it is this means that the upper left corner of the rectangle is at (x-overallWidth+1,y-fontAscent) (which therefore disagrees with the protocol specification). John Bowler (jbowler@acorn.co.uk)
keith@EXPO.LCS.MIT.EDU (Keith Packard) (01/06/90)
> The ImageText8 and ImageText16 protocol requests are defined to fill in > a background rectangle of width ``overallWidth''; where overallWidth > is the sum of the character width metrics. So what happens if this > quantity is negative? (Quite likely with a RightToLeft font). > > The sensible interpretation is to fill in a rectangle of width > overall-width with an upper *right* corner at (x, y-fontAscent). This > achieves what the application program probably expects with a > RightToLeft font (ie that the background of each character gets set, so > long as the character origins are at the right hand side of the > character). If this interpretation is correct, is the pixel > (x,y-fontAscent) filled in? If it is this means that the upper left > corner of the rectangle is at (x-overallWidth+1,y-fontAscent) (which > therefore disagrees with the protocol specification). > > John Bowler (jbowler@acorn.co.uk) The R4 image text implementation does not use this interpretation, rather the rectangle starts at (x-overallWidth,y-fontAscent). This was combined with an interpretation of negative-width characters which places them to the left of the left edge of the starting coordinate (i.e. an ink-inside negative-width character will never pixelate any bits along the x origin): -w x w | | | ............... bg bits xxxxxxx negative character width fg bits xx bg bits xxxxxxx positive character width fg bits xx If you don't agree with this interpretation of the protocol document, I'd have to say I'm not surprised as the ImageText description does not cover negative width characters at all. However, the section describing QueryFont (page 392 in the X book) does describe the bounding rectangle for the character pretty clearly, and this interpretation does lead reasonable logically to the image text interpretation shown above. Besides, Bob agreed with me when we typed in the current code. Keith Packard MIT X Consortium