[Xcb] XRenderCompositeString32

[Russell Shaw]

Josh Triplett wrote:
> Russell Shaw wrote:
> 
>>Vincent Torri wrote:
>>
>>>On Thu, 12 Oct 2006, Russell Shaw wrote:
>>>
...

>>The params dst_x and dst_y are also missing. I made a patch.
> 
> Thank you very much for reporting this.  The lack of dst_x and dst_y
> definitely constitutes a bug in our description of the Render extension,
> which becomes a bug in the generated stubs.  I've filed this as bug 8614
> at https://bugs.freedesktop.org/show_bug.cgi?id=8614 so we don't lose
> track of it, added you to the CC list for that bug, and made that bug a
> blocker of the 1.0 release.
> 
> However, the use of uint8_t (aka "BYTE") does not actually constitute a
> bug here, and glyphcmds_len *does* represent the byte length.  We did
> this intentionally, because each item in "glyphcmds" can represent
> either a GLYPHELT32 (which has x, y, and a variable-length list of
> glyphs) or a GLYPHABLE (either a GLYPHSET or a FONTABLE).  This means
> that the elements of the list "glyphcmds" have varying lengths, and thus
> a C array plus length cannot correctly represent them.  (The previous
> description of this request, based on the extension documentation, just
> plain didn't work.)  Thus, you need to construct an appropriate list of
> bytes and pass it to the function.  In the future, we may supply a set
> of functions to construct such a list of bytes by incrementally adding
> GLYPHELTs or GLYPHABLEs, and do similarly for other requests with lists
> of variable-length types.
> 
> You may want to look at the recent thread 'Anyone ever used
> "XCBRenderCompositeGlyphs"', started by Yang Jianjun on 10/11/2006,
> which discusses this same issue, as well as the bug report
> https://bugs.freedesktop.org/show_bug.cgi?id=8602; as pointed out in
> that thread and report, you may want to wait for us to implement the
> higher-level "xcb_renderutil_composite_string_{8,16,32}" functions,
> rather than directly using the underlying protocol requests via XCB,
> which do not do exactly the same thing as the Xrender functions you want.

Hi,
I studied XRenderCompositeString8/16/32 some time ago and concluded they
are fatally flawed, because they don't take per-glyph kernings. Instead,
i just render strings *one* glyph at a time, so each character can get
its own kerning. I won't use any higher-level string functions in xcb unless
they also take per-glyph kernings.