Esteban wrote:
> Thanks for the clarifications.  One minor suggestion on that function:
> zip builds a list with the tuples it generates (pre Python3K anyway).
> You only iterate through them, so you probably want to use the cheaper
> itertools.izip instead?
>   
Good idea.  I did not mean to discourage you from changing GlyphString's 
behaviour; it sounds like you have some good ideas to simplify it.  If 
you can come up with something better than the current 
implementation/interface that caters for both font.Text and 
contrib/layout I'd be more than happy to use it.

Alex.

> On 9/27/07, Alex Holkner <[EMAIL PROTECTED]> wrote:
>   
>> Esteban wrote:
>>     
>>> There are a couple things that strike me as counterintuitive in
>>> font.GlyphString.get_break_index.  I'd like to know your rationale for
>>> these:
>>>
>>>  - If no valid break index is found, the original from_index is
>>> returned. Why? Wouldn't it be better to return None (easier to tell
>>> from a valid index) or the length of the text (a sane default if the
>>> whole text fits the width)?
>>>
>>>       
>> Returning None might make sense, but I'm pretty sure having it return
>> the original index simplifies the inner loop of the calling code (at
>> least, for the code I've written).
>>     
>>>  - If text[from_index:] actually fits in the given width, I still get
>>> the index of the beginning of the last word. Why?
>>>       
>> get_break_index can't make the assumption that the end of the string is
>> a valid break point (otherwise you couldn't use it to for laying out
>> text with multiple styles).  font.Text adds a temporary space to the end
>> of the string (and discounts it later) because it doesn't handle
>> multiple styles.
>>
>> You might be interested to look at the contrib/layout package, which
>> does substantially more scary things with GlyphString than font.Text
>> does (and is what it was originally written for).
>>
>> Better APIs are good, if you can come up with something.  If you watch
>> the commit/issues logs you'll see that word-wrapping errors in font.Text
>> are not uncommon, it's quite tricky to get the correct behaviour with
>> the current API.
>>
>> Cheers
>> Alex.
>>
>>     
>
> >
>
>   

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"pyglet-users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/pyglet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to