6.12.2: Text Handling

[SilentWolfie]

Whoa. Hmm, so text speed isn't implemented yet... I was kinda wondering if there's an option in the system like {slow} or what not to emphasize certain words my character is using. But wow, this system is actually great. It's not that hard at all to actually implement things using renpy. Just declare stuff and we're ready to go. I doubt I even use 10% of what the system has.

[backansi]

- aren't most languages either left-to-right or right-to-left nowadays, at least for the primary display of computer text?

Korean used to be written text vertically when it's used in movie subtitle. So I wanted vertical text to which can make the visual impression of my game more classic(Nowadays, subtitle is written horizontally like any other languages', because convenience of use & read, or the problem of authority-it's related with Korean history and culture....).

..And aren't Japanese is written vertically in publications, especially comic books and magazines?(I'm not sure 'cuz I haven't read it since 3 years ago)
If you're considering adding speech balloon to Ren'Py- I've read the thread before about balloon thing - and when it's added, Japanese users might want to print Japanese vertically to make their game like comic book style, I think.
(Of course they possibly have different opinion than me which I can't know exactly)

[Aleema]

All of the vertical text I've seen in (Japanese) VNs has been images, and even then I don't have many examples. I don't see any reason to pursue it unless you're really out of things to do. =P

[PyTom]

After spending some time experimenting with it, I'm pretty sure that I'm going to leave vertical text out, at least for the moment. The way fonts represent vertical text is actually quite different then how horizontal text is laid out - different enough that I think the easiest way to do it would be to write a second Text class, just for vertical text.

I'd need a really strong demand for vertical text to spend the time to implement it, and even if I did, I'd probably leave out many of the features the horizontal text layout engine has.

[SilentWolfie]

Not too sure how the text speed is going about for now or if it's already implemented somehow, but besides a {slow} function, I will also like a {delay} function. Example,



Killer "I will {slow}KILL you. I will enjoy {delay} THIS!!! {nw}"
play sound "sound/epic boom.wav"
extend "Hahahahaha!!!"

#where delay =0.5 seconds, and slow = 0.5x speed, then maybe {/slow} to restore to original settings...

[backansi]

PyTom//That's too bad. Then I wish the many want vertical text at a later date or you have plenty time for work with it. *_*
By the way,
http://lemmasoft.renai.us/forums/viewto ... =8&t=10430
could it be solved in 6.12.2?

[PyTom]

I've been putting a lot of time into Newtext. Right now, the English (and hence most western language) path is done, and I'm now working on some of the international stuff. I've already finished support for furigana/ruby text. Here's an example of it, for people who don't follow my twitter:



There are two new text tags that support ruby text. The {rt} tag (short for ruby top) encloses text that will be displayed above the current text. The size and style of the ruby text is controlled by the new ruby_style style property - I'll document that properly in the docs. By default, ruby text is centered over the character preceding it. This makes sense for furigana, but we also support using ruby for interlinear annotations*, where we might want to center it over an English word. To support that, we have a new {rb} (ruby bottom) tag that lets a range of glyphs be used as the bottom part of a ruby instance.

The code for the example above is:

Code: Select all

"Ren'Py will soon support furigana (東{rt}とう{/rt} 京{rt}きょう{/rt}) and other kinds of ruby text ({rb}東京{/rb}{rt}Tokyo{/rt})."

Or at least, that will be the code when I finally hook newtext up.

Another big change is that I've added the Unicode line breaking algorithm to Ren'Py. This does the right thing in the vast majority of cases, handling both western and eastern languages correctly. It also is a lot less ad-hoc than the current method.The only language it has problems with is Korean, and that's because there are two versions of Korean line breaking.

- The default Unicode algorithm treats Korean as a language similar to Chinese and Japanese, where you can break between any two blocks. (This is apparently used in typeset books.)
- Most Korean that I see (for example, the Korean Wikipedia) has treated it similar to a western language, with breaking only occuring on spaces.

To deal with this second (unfortunately, probably the more common) case, I've added a new value for the language property, "korean-with-spaces". Setting style.default.language to "korean-with-spaces" will disable line breaking between arbitrary blocks, which means that breaking will only occur at spaces and other similar characters.

Does this make sense?

* Or, more likely, for being a total weaboo.

[Samidarenina]

Looks great so far. I'm only currious how it behaves with different "style.default.line_spacing" settings.

Edit:
Also, what's next on your priority list?

[PyTom]

Looks great so far. I'm only currious how it behaves with different "style.default.line_spacing" settings.

It breaks down somewhat if lines happen to overlap vertically. Apart from that, the line_spacing and new line_leading properties give a decent amount of control over the look of the line. There's a lot of control over the placement of Ruby text, if that was the question - the user does have to do some work to ensure that the rendering is acceptable.

Also, what's next on your priority list?

Well, I spent a couple of days implementing the Knuth and Plass line-breaking algorithm. That's the one used in TeX, and it attempts to minimize the raggedness of line endings in a paragraph, which should make the text look less ragged. It's a subtle improvement, too be sure, but it should make games just a little bit nicer. This has landed in the newtext branch already.

While optimizing newtext, I discovered a fairly major performance loss in the OpenGL texture upload code, on the order of 10ms on my 1.2 ghz core i5. So I'm going to be making another release of 6.12.1, that fixes this and several other bugs that people have reported - basically, anything that can be fixed simply without a full test cycle. I'm hoping to get this out early next week, in time for the Ludum Mini-Dare that might have several Ren'Py games made for it.

When that's done, it's back to finishing newtext, which I think I'm a week or so away from. Open issues are Right-to-left language support, support for interpolating variable and field values, and several more speed improvements. (newtext is already more than twice as fast as the current text code, BTW.)

The next release (codename: meat) will consist of:

* Newtext (mostly done)
* A set of new themes and colorings contributed by Aleema.
* A set of default screens when running on Android. (Based on the TCAST screens.)
* A screen-based image gallery system.

The release after that (codename: potatoes*) will be focused on a screen-based launcher rewrite, one that will also include code-navigation features.

I'd also like to add some sort of pervasive support for game translations, but exactly how that would work and how to balance the interests of creators, translators, and players is something I haven't figured out yet.

[jack_norton]

(newtext is already more than twice as fast as the current text code, BTW.)

Awesome Cool also about the texture loading speed improvement!

[Samidarenina]

Well, I spent a couple of days implementing the Knuth and Plass line-breaking algorithm. That's the one used in TeX, and it attempts to minimize the raggedness of line endings in a paragraph, which should make the text look less ragged. It's a subtle improvement, too be sure, but it should make games just a little bit nicer. This has landed in the newtext branch already.

Wow, while it may be just subtle improvements, it will mean a lot for text-heavy games like visual novels. Honestly, that's something I've been hoping for a long time but I honestly didn't think that anyone else was concerned about it. This release is probably my most sought-after for a long time, with all those improvements to text.
You always manage to surprise me on how dedicated you are to Ren'Py and the community.

Edit: Also looking forward to character fade-in and similar effects.

[duanemoody]

This is what I would expect from any VN text renderer as basic functionality:

• Robust metrics calculation. This means that styles that require more calculations to derive a bounding box are still available at the character level rather than block level (e.g. outline style composed from 8 shadows). If a web browser can manage rendering a line with multiple shadow offset styles, so can Ren'Py.
• Standardized measurements for letter/word/line spacing which can go by pixels or percentages. Line spacing calculated by height, not by offset.
• Accurate metrics. Pygame ignores a font's own em-size, ascent and descent metadata and instead returns the height of the tallest character it finds, which means any font containing stacked diacriticals is going to have an artificially tall line spacing across the board that doesn't match that font's rendering in applications using standard font rendering libraries. Get the value directly from the font using Freetype's own API instead.
• Vertical rendering for CJK. These characters are monospace AND mono-height, so it theoretically ought to be easier to implement than LTR proportional-width text rendering.
• BMfont caching/prediction. The game I built with a BMfont slowed down before every page that required loading a new font image. It also crashed Ren'Py unless I restricted the code ranges output to the BMfont.
• NVL managing paging by itself. If ADV mode can calculate the bounding box of a chunk of text and draw a background box based on it, NVL can count the lines on the screen and place a CTC icon on the last line, clear the text, and start the next NVL screen.
• Extend is the symptom of a problem, not the solution to it. It would be more versatile to have text rendering be considered an animation governed like ATL that defaults to having an interaction at its end, not BE the interaction itself. Let me have a dialogue chunk where at one point in the text the character's sprite changes expression, or two side by side boxes where one person is speaking and as soon the first speaker's text ends, the other character interrupts.

Code: Select all

show doris smiling
drs "It's so nice of you to say that about my sister, she really thinks the world of you {nb}"
show doris thoughtful with dissolve:
  drs "and if I had a nickel for every time she's come over to visit when I was gone... {nb}"
show doris worried with dissolve:
  drs "Hey, wait a second."

Rollback would consider the original state to be doris smiling before the text begins rendering, and the end state to be doris worried with all the text rendered. The main concern with this approach is that the question is raised as to what happens if the transition takes longer than the text to render.

[PyTom]

Wow, it's been a month since this was posted - but now that I'm feeling a bit better and back to newtext work, I'll answer this.

Robust metrics calculation. This means that styles that require more calculations to derive a bounding box are still available at the character level rather than block level (e.g. outline style composed from 8 shadows). If a web browser can manage rendering a line with multiple shadow offset styles, so can Ren'Py.

I'm not quite sure what this has to do with robust metrics calculations. While both metrics and style information are available at the glyph level, that's not enough to get good shadow rendering - shadow/outline rendering needs to be layered, so that the entire shadow layer is drawn before any of the text layer. This tends to mitigate against having per-character shadows, and I don't plan to support such shadows.

Standardized measurements for letter/word/line spacing which can go by pixels or percentages. Line spacing calculated by height, not by offset.

The spacing goes by pixels, as it's hard to think of another unit for spacing. (Font-height? Em? There are several, but none are very good.) Line spacing is based on the height of the font, with leading and spacing added to it.

Accurate metrics. Pygame ignores a font's own em-size, ascent and descent metadata and instead returns the height of the tallest character it finds, which means any font containing stacked diacriticals is going to have an artificially tall line spacing across the board that doesn't match that font's rendering in applications using standard font rendering libraries. Get the value directly from the font using Freetype's own API instead.

Pygame doesn't do that. The SDL_ttf library queries the font height from the SDL API, and Ren'Py follows that. Diacriticals shouldn't change this.

Vertical rendering for CJK. These characters are monospace AND mono-height, so it theoretically ought to be easier to implement than LTR proportional-width text rendering.

While theoretically easier, it's an entirely separate code path that I suspect very few people will use. It isn't worth the implementation effort.

BMfont caching/prediction. The game I built with a BMfont slowed down before every page that required loading a new font image. It also crashed Ren'Py unless I restricted the code ranges output to the BMfont.

I'll look into font prediction for imagemap-based fonts.

NVL managing paging by itself. If ADV mode can calculate the bounding box of a chunk of text and draw a background box based on it, NVL can count the lines on the screen and place a CTC icon on the last line, clear the text, and start the next NVL screen.

The ADV case is far simpler than the NVL one. In the ADV case, we simply need to display the next block of text. For the NVL case, we need to figure out what will be displayed next, and decide if it will fit on the screen or not. That's a lot of prediction work, and I'm not sure it's something I can make work reliably.

I'm also not sure this is a good idea. A visual novel isn't an ebook reader, and the paging scheme can be controlled by the creator for effect. Autopagination would tend to lose some of this effect.

Changing the handling of extend is also out of the scope of newtext - it's a different layer of Ren'Py entirely.

[backansi]

To deal with this second (unfortunately, probably the more common) case, I've added a new value for the language property, "korean-with-spaces". Setting style.default.language to "korean-with-spaces" will disable line breaking between arbitrary blocks, which means that breaking will only occur at spaces and other similar characters.

!! How kind you are. Thanks. If Korean users know your effort for them, they shall willingly use RenPy more than now.
(Of course I'm in love with it already)

[PyTom]

Just landed the support for the new version of text substitutions.

Now, you'll be able to use square-bracket-enclosed strings to interpolate variables in the middle of dialogue. So we can have:

Code: Select all

"Hello, [player], how are you doing?

We use the new python 2.6 string formatting syntax, so it's possible to interpolate fields and keys from dictionaries:

Code: Select all

"Watch out, [player.name], you have [player.hp] hit points left!"

"It's dark. You might be eaten by an [enemy[name]]."