Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!pasteur!cory.Berkeley.EDU!dheller From: dheller@cory.Berkeley.EDU (Dan Heller) Newsgroups: comp.windows.x Subject: Re: Rotated text Message-ID: <14011@pasteur.Berkeley.EDU> Date: 20 May 89 18:46:01 GMT References: <105466@sun.Eng.Sun.COM> <169@ixi.UUCP> Sender: news@pasteur.Berkeley.EDU Reply-To: dheller@cory.Berkeley.EDU (Dan Heller) Organization: University of California, Berkeley Lines: 122 > In article <105466@sun.Eng.Sun.COM> argv@sun (Dan Heller) writes: > >Now that I'm talking about fonts, inspection of the code *appears* > >to be just shy of giving XDrawString the ability to render rotated > >text. The following changes would need to happen: there needs to > >be a height field in the XCharStruct data structure, and there needs > >to be an ability to communicate this new information about the font > >changes to the server. The application is responsible for rotating > >the glyphs of the characters, of course. In article <169@ixi.UUCP> clive@ixi.uucp (Clive Feather) writes: > Firstly, changing the XCharStruct data structure means changing the > protocol, and there's no way that the real world out there is going > to let you This is the biggest problem, of course and for that reason, it's all a moot point. However, this need not be in there were an -additional- font type which has different calling functions from the currently existing font types. Since for rotated text, calls such as XTextWidth doesn't make a lot of sense (since there is another dimension involved). A new set of functions could be introduced to support this stuff. I or anyone else isn't going to go to the effort to do so if X is definitively going to stay out of the page description aspect of graphics. > Next, isn't the "width" and "height" of the character going to change > as you change the angle ? Yes -- and that's why I'd like to have the ability to send a request to the server to modify this information. This wouldn't apply to any arbitrary font, it would apply only to fonts which have been "uploaded" by the application (uploaded fonts could be flaged as read/write).. If the application decides to rotate text, then it could send a request to the server to change the width/height attributes of a font. This doesn't necessarily require the glyphs to rotate of course. You can have chars which appear as steps. Similarly, you can rotate glyphs without affecting the way their orientation appears. These are all concepts in the printing industry that are not unusual. Since great efforts were made to make X suitable for creating a "Draw" package by supporting all sorts of geometric shapes, line styles, end caps, and so on, why not extend the protocol to do reasonable page description support. > Far more important - how is the application going to rotate the > glyphs ? They're not in the XFontStruct or anything that hangs off > it. This means that to get hold of them, you need to do something on > the lines of: The X server stores the glyphs somewhere (admittedly, I don't know the internals to this that well). However they are stored, it would be nice to be able to tell the server to change the glyph of a particular character. XSetFontGlyph(fid, c, glyph) XID fid; /* font id */ int c; /* index into the font table */ Pixmap glyph; /* change image to use this glyph */ > BTW, please describe an algorithm for rotating the characters *neatly*. There are many ways to store font information. So as not to threat anyone's technology, let's consider the most simple case -- fonts stored as bitmaps. Here, a simple bitmap rotation method is all you need. Again, this does not necessarily represent characters, even tho it's likely. The actual rotation of glyphs can be simple or complex depending on the needs (intelligence?) of the application. > Finally, there is no way to turn these rotated glyphs back into a font ! A font is nothing more than a set of glyphs and information about them. If I take an 'A' and use some magic to rotate it (again, use the bitmap rotation analogy), then the glyph, in my font book, still represents an A. It is still a font. A well designed application will obviously save its "initial" information about a font so numerous transformations don't degenerate the image into a set of random pixels. > The nearest that you can do is something like: > > Rotate the glyphs. > Write them out in BDF (Bitmap Distribution Format), wrapped > up to form a font. > Run bdftosnf on the font. > Install the font in an appropriate directory. > Run mkfontdir on that directory. This is *precisely* what I want to avoid. I want to be able to load a font directly into the server from an application -- and, I want to modify that font from the application. Clearly, there are restrictions on this special font that don't apply to the other fonts -- e.g. you don't get the font listed from xlsfonts; the font is read/write; the font is only available to the client using the font; the font is destroyed and all information about it is freed in case the application dies or sends a XFreeFont type of request. These are just issues from the top of my head -- I haven't gone into a design phase of this. > Reboot your server (or possibly, mess around with XSetFontPath). If XSetFontPath exists, then there are clearly the internal functions available to actually load a new font or change font info at runtime. Next, you provide a sample routine which demonstrates my point that the need for rotated font information should exist. first, a quick review of your routine: > for (i = 0, c = string; i < length; i++, c++) > { > int w; > > XDrawString (display, d, gc, xx, yy, c, 1); > w = XTextWidth (fs, c, 1); > xx += si * w; > yy += co * w; > } I should point out that this is just about what I *am* doing now in order to display rotated fonts because there is no other method available. The routine involves two expensive operations: XDrawString and XTextWidth. For one thing, both of these routines involve communication with the server -- in the case of XTextWidth, the glyph is gotten from the server for inspection. Both of these routines, when compounded by the length of the string, will generate lots of network traffic as well as poor performance. If the height and width information I described before were stored in the font or character somehow, then the string can be rendered with the single call to XDrawString and the server can handle the placement of the next character internally. It already does it for the width --the only change necessary would be for its height. Dan Heller