Re: [pygame] Good code for text wrapping?

["René Dudfield" <renesd@xxxxxxxxx>]

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
>>>
>>
>