Re: [pygame] Good code for text wrapping?

["Charlie Nolan" <funnyman3595@xxxxxxxxx>]

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 <renesd@xxxxxxxxx> 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 <funnyman3595@xxxxxxxxx>
> 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 <renesd@xxxxxxxxx> 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 <funnyman3595@xxxxxxxxx>
>>> 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
>>>>
>>>
>>
>