Phil Endecott wrote: > Hi Denis, > > Denis Oliver Kropp wrote: >> Phil Endecott wrote: >>> I have thrown together some code for text rotation using FreeType2. > [snip] >>> I treat these rotation values as quarter-turns anti-clockwise, >>> 0<=rotation<=3. It would be straightforward to supply an arbitrary >>> angle to FreeType, but (a) I don't need it; (b) it would be much >>> harder to implement for any bitmap font providers, and (c) it could >>> make the DisplayString positioning stuff (see below) even more >>> complex. If people do want to allow an arbitrary rotation, we should >>> consider going further and allowing an arbitrary transformation. >> >> What about using degrees, but only allow 0, 90, 180 and 270? > > Is there any mechanism for a font provider to indicate its > capabilities? i.e. FONT_CAPABILITY_ROTATE_RIGHTANGLE vs > FONT_CAPABILITY_ROATE_ARBITRARY?
We could add IDirectFBFont::GetCapabilities() and DFBFontCapabilities with DFCAPS_ROTATE_90, DFCAPS_ROTATE_180, DFCAPS_ROTATE_270 and maybe DFCAPS_ROTATE_ANY. > Angles really need to be floating-point. Equality tests for > floating-point values are tricky. We can use fixed point values, either n.m or n/m, e.g. 16.16 or 1/10000th. >>> Unfortunately, there is more complexity; in particular there are the >>> string width calculating functions, and the logic for centering and >>> right-aligning text. I haven't even used most of this stuff. So: if >>> a user asks for the "width" of a string in a font that is rotated to >>> be vertical, what should they be told? >> >> I'd expect the vertical size, because I know the text is rotated and I >> break the text in vertical strips. > > OK. > I think this means that I need to either compute or store > sqrt(sqr(xadvance)+sqr(yadvance)). I'd compute the total string extents first and then do this. >> For string extents with rectangle return values, it should have the same >> orientation as usual. > > OK. Now think about a 45-degree rotation: > > +---+ > |F | > | o | > | o| > +---+ > > /\ > \F\ > \o\ > \o\ > \/ > > Does that return 3x3? Or should it actually be returning a > non-orthogonal box? It should return the bounding box, so 3x3. >>> A couple of other areas where I had to make temporary hacks to get it >>> to compile are dgiff fonts and fixed_advance. >> >> A font could refuse to implement rotated text. > > Ditto comment about FONT_CAPABILITES. Note that even FreeType will > refuse to apply a transformation if the font file it has read contains a > bitmap font. This would mean we'd have to rotate the bitmaps ourself anyhow. Maybe the straightforward method using the matrix is not the best option, though it's the easiest and with least code. >> Hmm, wouldn't it be >> possible to do the rotation in generic code, but with probably more >> overhead at load time. > > You could do it when copying the glyphs out of the cache, using a > rotating blit. (Have you made any more progress with that?) Only 180 degree so far. If the font is loaded as rotated, it should be rotated in the cache and use simple blitting. If we have a flag for DrawString(), e.g. DSTF_ROTATE180, it should use DSBLIT_ROTATE180 internally. >>> If someone who better understands all of this would like to help out, >>> that would be much appreciated. Otherwise, some suggestions about >>> how it should all work would be useful. >> >> So far it looks good. Feel free to ask more questions. > > There will be more! But if you (& anyone else) would like to offer a > checklist of things that I need to consider, that would be very useful. > There is a lot of the DirectFB code that I have never looked at. Most important is to keep the unrotated loading and drawing as fast as it is. For the cache it might be good to use vertical strips instead of cache rows, because glyphs vary in width much more than height. The disadvantage of a vertical strip is that a lot could be lost by pitch alignment. Better keep the code simple at that point for now. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
