I like Greg's suggestion, it sounds like the sanest way to handle this. I'll go ahead and rough out a skeleton system.
René - Yeah, I'm thinking we'll just use a bare class, since it's got somewhat nicer syntax than a dict. (style.bold instead of style["bold"]) As far as inheritance goes, the default should probably be to clobber everything, but it might be nice to allow bleed-through too. Useful, for instance, if you wanted to set the entire passage bold but it already had individual colors/italics/underline in place. -FM On 9/25/08, René Dudfield <[EMAIL PROTECTED]> wrote: > hey, > > I like the idea of doing it as a separate module. > > ---- > let's work on it here... > http://code.google.com/p/pygame/ > > branches/text/ > > I've added you to the project... (if anyone else wants to help with > it, please send me your email off list). > ---- > > > A simple style dict/class which goes along with each part of text > would work fine I think. This method seems to work ok for html/css > etc. > > We need to make sure that styles can be applied inside of styles. I > guess a simple inheritance would work there? > > Either: > - child styles inherit from the top, over riding what they declare? > - child styles are completely new, inheriting nothing? > > I think the simplest implementation would to make the style be applied > as is... with nothing inherited from the parent. Then we can mess > with inheritance of child styles separately. > > > cheers, > > > > > > On Thu, Sep 25, 2008 at 4:16 PM, Charlie Nolan <[EMAIL PROTECTED]> > wrote: >> Sure, I'm always happy to help. I guess the first issue to look at is >> where to put this. >> >> One possibility would be methods on the font.Font class. >> Pro: >> * Right next to the normal render method and hence an obvious place to >> look. >> * We might even be able to fold it into the main render function. >> Con: >> * Forces us to stick with a single font for the entire text. >> * Clutters up that class. If we merge with render instead, we make it >> much more complicated. >> * Forced to use C, since we're working in a C class. (AFAIK, there's >> no way to mix like that without monkeypatching.) >> >> Another possibility would be in its own module, just as naked functions. >> Pro: >> * Simple to use. >> * Everything's grouped together and easy to scan through. >> Con: >> * When we start incorporating styles, naked functions get clumsy (as >> my example already shows). There's just too much extra data that has >> to be shoved into the function call. >> >> And the third that comes to mind is building a class that represents a >> block of text with various properties and giving it a render method. >> Pro: >> * Styles, especially, benefit from the complexity segmentation this >> provides. The final attributes can be built piecemeal and in a >> sensible order, instead of trying to shove everything into one >> function call. >> * This gives us an easy place to store glyph position data for >> handling click/drag. >> Con: >> * Not as easy to use as naked functions, as creating an ordinary block >> of wrapped text is now a two-step process. >> >> My preference would be either the class or a hybrid of class and naked >> functions. The hybrid would put the functionality into the naked >> functions, with the class essentially acting as a "make this sane" >> wrapper around the complex parts of the naked functions. >> >> -FM >> >> On 9/24/08, René Dudfield <[EMAIL PROTECTED]> wrote: >>> hey, >>> >>> would you like to work with me in creating something for inclusion in >>> pygame? >>> >>> This would mean working out a simple api, making docs, examples, and >>> unittests. >>> >>> Something basic that we can have a look at, for adding the most easy >>> and useful features. We can try and avoid most of the tricky issues >>> for now. >>> >>> >>> >>> If anyone else is interested, we can set up a google host page or >>> something to work on it? >>> >>> cheers, >>> >>> >>> >>> >>> On Tue, Sep 23, 2008 at 10:11 PM, Charlie Nolan <[EMAIL PROTECTED]> >>> wrote: >>>> A fair amount of this is already in that file, down in print_string >>>> and print_line. (You're welcome to as much of the file as you like, >>>> but I'd strongly suggest you look into refactoring it. It's good >>>> enough for one isolated project, but probably not up to library >>>> quality.) >>>> >>>>> - aligning text, left, right, center etc. >>>>> - vertical alignment... top, bottom, center. >>>>> - text color >>>> Check. >>>> >>>>> - each part of text having a separate font/attributes. So you can >>>>> then do words with bold, italics etc. >>>> Everything but the font is easy to extend (the font's ugly to do, and >>>> probably overkill). I've already got underline in there. Might want >>>> to swap the style list for a style dict/object, though, to avoid >>>> degenerating into positional hell. >>>> >>>>> - selecting text. Based on mouse click, which letter and word does it >>>>> collide with? >>>> I've already got the baseline in for this, by way of EditableText's >>>> handle_click function. >>>> >>>>> - breaking words (word-break), so it can add a long word like >>>>> "complexifcation" as "complexif-\ncation" >>>> >>>> More-or-less present. Right now, it'll break on any character, >>>> without adding a hyphen, but extending it shouldn't be hard. Of >>>> course, if you want intelligent hyphenation, that's an icky can of >>>> worms all by itself. >>>> >>>>> - justify text. >>>>> - letter spacing >>>>> - line spacing >>>>> - word spacing >>>>> - indenting >>>>> - padding around text. >>>> Somewhat annoying, mostly because they affect selecting text. With >>>> this many weird things, it might be a good idea to look for a way to >>>> merge the layout and select code, possibly by storing a map as you lay >>>> things out. >>>> >>>>> - flowing around areas... >>>>> - eg( place an image, and the text flows around it) >>>>> - example here: http://www.csstextwrap.com/example_for_demo.php >>>> This one gets a bit ugly, and also runs into the layout/select >>>> duplication mentioned above. >>>> >>>>> - splitting text up into 'pages', >>>>> - different sized pages or Rects could be useful too. >>>> Not too hard. When the printing clips off the end of the available >>>> area, you move on to the next one. >>>> >>>>> - scrolling text. >>>> Are you thinking marquee or scrollbar? Either one seems out of scope. >>>> >>>>> - text render method. >>>> Not sure we need/want this, but it would be easy enough to add. You'd >>>> also want to add a way to replace the related methods (metrics, >>>> get_linesize, etc.). My main worry here is scope creep. Actually, if >>>> you're going into this much depth, wouldn't you just subclass >>>> pygame.Font? >>>> >>>> --- >>>> >>>>> - text flow other than left->right (right->left, mixed, top->down) >>>> I think this really belongs upstream in SDL, assuming it's not there >>>> already. Once it renders a string correctly, this is just another >>>> easy layout/select issue. >>>> >>>>> - support for non-letter fonts (e.g. button glyphs for help text) -- >>>>> although I suppose you could handle it by something you described, >>>>> flowing text around images, if the images could be floated as well >>>> I'm pretty sure you can do this already. As long as you have the >>>> font, you can render whatever you like in it. >>>> >>>>> - support for non-breaking spaces and hyphens >>>> NBSP is handled correctly. Hyphens fall under breaking words properly. >>>> >>>>> - proper handling of line-breaking in different languages (e.g., >>>>> French inserts a space or two between the last letter of a sentence >>>>> and a final exclamation point, don't want to break there, some >>>>> languages consider certain combinations of letters to really be only >>>>> one, can't break in between them, etc.) >>>> Most of this falls under word breaks again. French's pre-! space is >>>> kinda annoying, unless they already use an NBSP. >>>> >>>>> - proper support for full Unicode fonts >>>> I haven't run into anything broken here. DejaVu seems to render >>>> perfectly well. Most of this is up to SDL, though we'd have to pay >>>> attention to control characters (switching RTL/LTR without warning >>>> does ugly things). >>>> >>>> --- >>>> >>>> Most of this isn't too bad to add to what I've already got, but you'd >>>> want to be really careful with adding them one-by-one. It'd be really >>>> easy to get scope creep or just turn the entire thing into hacks of >>>> hacks. >>>> >>>> In some ways, I'd be relieved if you didn't use my code, because it's >>>> already held together with duct tape and baling wire. Unfortunately, >>>> I'm not sure there *is* a sane way to handle this stuff, there are >>>> just too many special cases. >>>> >>>> I think the important thing is to get something in soonish that >>>> handles as many of the common cases as we can. We don't want this >>>> degenerating into something that will come out shortly after Duke >>>> Nukem Forever. >>>> >>>> -FM >>>> >>> >> >