Xft/fontconfig questions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Around 10 o'clock on Jun 20, Dmitry Karasik wrote:

> - The font/glyph data information, located in XftFont/XGlyphInfo
> is somewhat cryptic. For example, what are x,y,xOff,yOff fields for?
> I guess these are related to lbearing/rbearing etc in XCharStruct,
> but how? 

Yes, they're mystic and broken.  I'm sure I had a good reason for changing 
the names and semantics of these fields, but I sure can't think of what 
that might have been.

x,y are the distance from the upper left corner of the bounding box
containing the glyphs to the glyph origin.

xOff,yOff are the distance from the glyph origin to the next glyph origin

width,height are the dimensions of the bounding box.

Note that 'x,y' are *not* the distance from the glyph origin to the upper 
left corner of the bounding box, so instead of *adding* x,y to the glyph 
origin, you *subtract* it.

	Render/Xft	Core X
	-------------------------------
	x 		leftSideBearing
	y 		-ascent
	xOff		width
	yOff		(not defined in X)
	width		rightSideBearing - leftSideBearing
	height		ascent + descent

(I sure hope this is right).

> - I need to access the font/glyph information like underline position,
> underline thickness, average character width, etc. Under the core
> protocol, these could be read via the corresponding font properties -
> XA_UNDERLINE_POSITION,XA_UNDERLINE_THICKNESS, and so on. How would I
> access these data from under Xft?

You ask FreeType directly.  Use XftLockFace/XftUnlockFace to get at the 
FT_Face object.

> - How does UCS4 endianness work for Xft? For example, if I try to
> output the glyphs, corresponding to the font charset, the glyphs are 
> not shown up unless I reverse the byte order. Do I have to always 
> reverse the byte order or only for little-endian machines?

Xft provides three separate APIs for UCS4 strings:

	XftTextRender32		- native machine byte order
	XftTextRender32BE	- big endian byte order
	XftTextRender32LE	- little endian byte order

I note that Xft is missing TextExtents varients for BE/LE and uses the
FcEndian value for Utf16 tet.  Sigh.  I suggest that we create UCS4
APIs which use FcEndian values and FcChar8* strings with 4 bytes per 
character.

-keith




[Index of Archives]     [Fedora Fonts]     [Fedora Users]     [Fedora Cloud]     [Kernel]     [Fedora Packaging]     [Fedora Desktop]     [PAM]     [Gimp Graphics Editor]     [Yosemite News]

  Powered by Linux