LÖVE

I actually like the whole rich text idea ... a lot. As I'll most likely be able to use it in some way or another.

I'm not entirely sure about the syntax at all since this subject can debated for ages.
Seems to me one of the simplest solutions. The fact that big is a font and smile is an image does not need to be reflected in the text itself since one defines these by themselves (and in case by someone else the possible options and images can be documented).

On another note it would most likely be nice if this rich text can somehow be serialized to file and thus loaded from file as well.

With this in mind an alteration to the tags would be handy.
Basically you just provide the arguments for the respective love.graphics.newFont and love.graphics.newImage methods and allow for the previous suggested method (Would be nice if anything that is a drawable can be used).

However this has a down side when in a text a certain image appears multiple times. As far as I know there is no caching of image data done with love.graphics.newImage so this would increase the memory usage and io. However in most longer texts it does not happen often that a larger image is repeated.

Another idea although I tend to dislike it myself is embedding the hex data of images. Would work nicely on generate "documents" but would kinda need an editor to make these kinds of "exported" texts.
Either way a rich text module would be greatly appreciated especially if the data is serializable and loadable from file.

Some other things one might want to think about is:
- Text orientation (angling)
- color (fore- and background)
- animation (i.e. quads that can be altered or images that at runtime can be replaced)
Then again these ideas may complicate things beyond its simplistic function that is most appreciated.

Oh, great ideas!

CyaNox wrote:On another note it would most likely be nice if this rich text can somehow be serialized to file and thus loaded from file as well.

I like this, especially with the path-tags. A solution for the caching problem would be to let the RT lib cache them itself, either globally or per object.

CyaNox wrote:Another idea although I tend to dislike it myself is embedding the hex data of images. Would work nicely on generate "documents" but would kinda need an editor to make these kinds of "exported" texts.

Oh, yeah, I don't like that either.

CyaNox wrote:Some other things one might want to think about is:
- Text orientation (angling)
- color (fore- and background)
- animation (i.e. quads that can be altered or images that at runtime can be replaced)
Then again these ideas may complicate things beyond its simplistic function that is most appreciated.

Well, rotation could prove difficult to implement for anything other than what love.graphics.rotate() can do, but colors could be done as or perhaps .
Animation will probably give caching problems, as it would mean you can't just use a single framebuffer and draw that each frame.

This should be a subset of HTML or easy to convert from and to HTML, so you could write your game's manual and other docs in HTML and display them both in game and in a browser with little trouble. If you make your own format that is not compatible with anything else, you could get a visit from the tooth fairy. The other one, which knocks them out.

Well animation aren't really needed in rich text. Rotation however I can see some useful applications there. Color is indeed easily doable.

With regards to HTML as a backing language I'm not sure. Even though HTML is partially meant for rich text it is also quite a mess. Something that looks like HTML and is not seems to me something very bad as well. People will see it and assume its HTML and go on doing things that the parser can't handle. Or the parser will become so complex that it has no use anymore.

Same with other markups like latex, xml, rtf or related. It will be a hell of a lot of work to make a parser for those.

So to keep it simple a new format that potentially grows bigger is in my opinion better. We already established some basic functionality that should be in there (i.e. font, images, color) and some potential things for the future. The above mentioned "standards" have way more then what we need at first. So it seems logical not to use them in favor of something much simpler we write.

If needed one can easily write a converter from for instance xml to our rich text as a separate script that strips all unused stuff from the xml and converts the rest into our language. I think for xml and xslt would do quite well. But as said that is something for later if it is deemed needed.

But if you really want to go HTML ... well then implementing something like http://sourceforge.net/projects/offscreengecko/ would be more useful.

Yeah, I think there are two problems with HTML/XML/anything else in existence for this lib:

1. They are over-powered. No-one will want to use complex, bulky HTML or XML for simply displaying some text in a game. (I sure don't!)
2. They are under-powered. You can't reference an Image or Font from HTML. Images need to be located by file location, and selecting Fonts in HTML would be completely horrible. What font is <b>? And <i>? And something else entirely?

No, HTML is not for games. I understand your problems with willy nilly ignoring standards and mashing together a new syntax, but we don't use SVG to write websites in or ODT to write scripts. We use a standard when it's appropriate for the context, and here no appropriate standard exists yet (that I am aware of).

I think where on the same line of thought there

I've read this post, pressed the "post reply" button, started writing, and then realized I had nothing to contribute, so I stopped.

Let me try again.

Rich text = cool.

HTML = not so cool. I'm against. Reasons stated above, so I'm not repeating.

I'm also a bit against writing the "path to images" and the "path to fonts" inside the text.

If I'm understanding this correctly, the "draw this rich text" order would be invoked in "draw time". Fonts and images specified "by path" would have to be loaded up in draw time. That kind of behaviour should be discouraged, imho.

kikito wrote:If I'm understanding this correctly, the "draw this rich text" order would be invoked in "draw time". Fonts and images specified "by path" would have to be loaded up in draw time. That kind of behaviour should be discouraged, imho.

Actually, my plan was to make it draw to a framebuffer when you call rich.new{}, and only draw the framebuffer when calling rt:draw().

You were wrong when you claimed a subset of HTML is not something people want to use to mark up rich text. This is exactly what some people do. See this page. It's from the docs for a popular cross platform GUI library called Qt.

http://doc.trolltech.com/4.6/richtext-html-subset.html

However, I won't press the point. If your thinking is that a specious analogy to using SVG to write websites is a valid argument, I don't really want to argue with you.

The problems I pointed out still exists: what would you use div for? Or table? meta? head? pre? CSS? Would every piece of text need to be wrapped in <html><body></body></html>? How would you choose between fonts? (Remember, you can't use just use <b> and be done with it*, nor can you use system fonts.)

* because it needs another font object.

So you need to have a much smaller subset, which makes about as much sense as Booleans as a subset of integers. Oh, and also introduce extensions, which doesn't make me very happy.

I couldn't see what was at the bottom of your reply, because I've got Flash-troubles. Oh, right, the Argument Clinic sketch.