[pygame] Good code for text wrapping?
René Dudfield
The cookbook has this entry, but it doesn't work with new lines.
http://www.pygame.org/wiki/TextWrapping
Anyone have any code like this that supports new lines?
cheers,
Douglas Bagnall
> http://www.pygame.org/wiki/TextWrapping
>
> Anyone have any code like this that supports new lines?
Batteries are included:
http://docs.python.org/lib/module-textwrap.html
does that help?
Douglas
Douglas Bagnall
Michael
Is this any use to you?
https://kamaelia.svn.sourceforge.net/svnroot/kamaelia/trunk/Code/Python/Kamaelia/Kamaelia/UI/Pygame/Text.py
The code can be used by itself but will look a little odd - it's got a
slightly wierd way of getting a surface to display on inside "initPygame"
and the equivalent of pygame.flip() is in the end of "updateLine" (the redraw
request), but other than than it's pretty normal normal code.
(The reason for the oddity is because it allows pygame based components to be
written as if they own the whole display, and then to be changed slightly in
small steps to share the display)
To see what it looks like quickly, it'd probably be easiest to grab the latest
kamaelia release:
http://edit.kamaelia.org/release/Kamaelia-0.6.0-rc7.tar.gz
Do the usual setup.py dance, and then:
~/Kamaelia-0.6.0-rc7> cd Examples/SimpleGraphicalApps/TextBox/
~/Kamaelia-0.6.0-rc7/Examples/SimpleGraphicalApps/TextBox> ./Textbox_TextDisplayer_Demo.py
Handles different font sizes etc happily. Only supports left justified text at
the moment.
Michael.
René Dudfield
If the width per character was fixed that could be used I think.
René Dudfield
The cookbook entry has been updated with a multiline function, that
seems to work ok.
http://www.pygame.org/wiki/TextWrapping
I guess for right justify, the lines could be blit from the right of
the screen minus text width. To center it, you would blit at the
(screen_width - text_width) / 2.
cheers,
Marius Gedminas
http://mg.pov.lt/pyspacewar/trac/browser/trunk/src/pyspacewar/ui.py#L466
Output example: http://mg.pov.lt/pyspacewar/pyspacewar-help-screen.png
It's GPL-ed, feel free to use or ask me for a licence change if that's
not suitable.
Marius Gedminas
--
If you are smart enough to know that you're not smart enough to be an
Engineer, then you're in Business.
Charlie Nolan
wouldn't this be a good candidate for adding to pygame.font.Font?
-FM
Ian Mallett
pymike
Charlie Nolan
point for pygame. It's not beautiful, but it does have a very nice
property:
orig_string[x] -> "".join(wrapped_string)[x]
They're not always equal, because it converts some spaces to a
zero-width character for alignment purposes. (The char was originally
\x00, hence strip_to_null, but that caused issues elsewhere,
presumably with C strings.)
http://code.google.com/p/endgame-singularity/source/browse/trunk/code/graphics/text.py?r=892
-FM
René Dudfield
yeah, maybe some text layout code would be a useful addition to
pygame.font ? Or even as a separate download.
Shall we start by making an ultimate list of features, or use cases...
- aligning text, left, right, center etc.
- vertical alignment... top, bottom, center.
- justify text.
- breaking words (word-break), so it can add a long word like
"complexifcation" as "complexif-\ncation"
- splitting text up into 'pages',
- different sized pages or Rects could be useful too.
- scrolling text.
- selecting text. Based on mouse click, which letter and word does it
collide with?
- each part of text having a separate font/attributes. So you can
then do words with bold, italics etc.
- letter spacing
- line spacing
- word spacing
- flowing around areas...
- eg( place an image, and the text flows around it)
- example here: http://www.csstextwrap.com/example_for_demo.php
- indenting
- padding around text.
- text color
- text render method.
Anything else?
Hugo Arts
René Dudfield
- CSS3 and CSS4 support.
- a pony.
Marius Gedminas
> oops, I also forgot...
> - CSS3 and CSS4 support.
> - a pony.
I'm sure the last one could be implemented easily, if you had SVG support
and Javascript.
Marius Gedminas
--
In short, at least give the penguin a fair viewing. If you still don't
like it, that's ok: that's why I'm boss. I simply know better than you
do.
-- Linus "what, me arrogant?" Torvalds, on c.o.l.advocacy
René Dudfield
> On Mon, Sep 22, 2008 at 02:41:28PM +1000, René Dudfield wrote:
>> oops, I also forgot...
>> - CSS3 and CSS4 support.
>> - a pony.
>
> I'm sure the last one could be implemented easily, if you had SVG support
> and Javascript.
>
Cool. I'll add x86 emulator onto the list. So we can get
SVG+javascript by installing linux + firefox.
Willy Lee
> Shall we start by making an ultimate list of features, or use cases...
<snip>
> Anything else?
Eventually, you'll want:
- text flow other than left->right (right->left, mixed, top->down)
- 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
- support for non-breaking spaces and hyphens
- 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.)
- proper support for full Unicode fonts
But this is a bit pie-in-the-sky, it can wait until the basics are in,
I just have text processing on the brain a bit lately :)
=wl
--
"The whole fist fight is over who gets locked up and thrown rudely to the
ground and tied into little greasy knots." -- Chas Clements
Charlie Nolan
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
René Dudfield
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,
Charlie Nolan
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
Greg Ewing
> 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.
Or the other way around -- implement the functionality as
a class, and provide one or more naked functions to make
it easier to use in the simple cases. This is the approach
used in various places in the stdlib, e.g. re and pickle.
--
Greg
René Dudfield
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,
Charlie Nolan
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
Aaron Maupin
2.5.2 win32 and Pygame 1.8.1.
The main character's location is defined by x and y floats. The levels
are stored in a tree format to allow for vast open spaces. Nothing
ground-breaking. I've been working on the collision system.
In certain situations, moving the game window (800x600) on the Windows
desktop sometimes causes the main character to teleport upwards on
screen to the next available platform. Does anyone know if moving the
pygame display window sends some kind of event to Pygame? Printing all
events in pygame.event.get() reveals no event occurring when the window
moves and the character teleports. It doesn't always happen, but when
it does it doesn't matter if I move the window 1 pixel or across the
desktop.
Where the character teleports and how is obviously because of my screwy
unfinished collision detection, because if I comment out the collision
detection calls the oddity doesn't appear.
But I just wondered if anyone knows why moving the window would trigger
anything?
Aaron
Aaron Maupin
causes the program to pause and thus when it comes back the delta time
difference between frames spikes. And then my screwy collision
detection teleports the character much further than should be possible.
René Dudfield
You should be able to put a maximum elapsed time for your frames.
That handles the moving window thing, and also if there's some other
pause from the OS. Like if firefox plays a flash animation in the
background that uses up heaps of cpu blocking your program for a
while.
cu.
Charlie Nolan
forgotten how many things I have to work on. Anybody got a cloning
device handy?
Failing that, give me a prod if there isn't a basic working version up
by Wednesday. It'll only take a couple hours, I just need to find a
couple hours when I'm alert, not doing something else, and interested
in coding.
-FM
René Dudfield
wrapping mood yet either.
I saw your mock font, for testing. That's a good idea.
cu,
Charlie Nolan
decided to die on Tuesday and it's in for repairs. Linux decided to
run fsck on the reboot as it was failing, and since then, I've got no
idea what it's up to, so I couldn't even bring it up to get files off.
Drive's sitting in front of me, but I don't have any way to connect
it to a different machine.
I'll get on this once Murphy leaves me alone again.
-FM