On 2/16/07, S'orlok Reaves <[EMAIL PROTECTED]> wrote:
> --- Mike Caron <[EMAIL PROTECTED]> wrote:
>
> > On 2/15/07, S'orlok Reaves <[EMAIL PROTECTED]>
> > wrote:
> > >
> > > > > Technically, this makes these features
> > available
> > > > to plotscripting strings, but to use them, you'd
> > > > need to embed those characters directly into the
> > > > plotscript file, which while doable, isn't very
> > > > convenient. Or, you can use append ascii....
> > More
> > > > thought on this is required.
> > >
> > > You could always invent your own markup. Like,
> > "\n"
> > > for newline, then "\c5{some string} some other
> > string"
> > > to make "some string" be the fifth color, and
> > "some
> > > other string" be the default.
> >
> > I have every intention to support codes like this,
> > but not until I
> > rewrite the textbox code :)
> >
> > The reason is this:
> >
> > Textboxes are, essentially, 8 strings displayed on
> > top of eachother.
> > Each string is limited to 40 characters by the very
> > format they're
> > stored in, since long before any type of code was
> > possible. This means
> > that any code embedded in the textbox takes up
> > display character
> > space. In other words, lets say you have a textbox
> > in which Bob talks.
> > Bob is, of course, customizable, so you use a code
> > to sub in his name:
> >
> > "${H_}: Hello there, my friends and such!"
> >
> > That is exactly 40 characters. If the default name
> > is "Bob", then this
> > means that it will only take up 38 characters,
> > leaving two wasted!
> > Conversely, if the name is "Pedrovich" (shh), the
> > string balloons to a
> > massive 44 characters, and part of it is cut off.
> >
> > The solution is word wrapping, but this is not
> > possible due to the
> > "seprate strings" analogy. If you were to combine it
> > into a single
> > string (gluing it together with \n), then you get a
> > different problem:
> >
> > "Pedrovich: Hello there, my friends and\n
> > such!\n
> > This is a fine day, is it not?"
> >
> > Obviously, if that hard line break after "such" was
> > removed, this
> > would work properly. But, we can't assume it isn't a
> > hard break,
> > because there are situations where it is (I assume
> > you can think of
> > one yourself).
> >
> > What to do? Well, first off, kill the 8-strings
> > paradigm, and make a
> > textbox one big string. Then, change the editor so
> > that the user can
> > just type, and it word wraps for them, and inserts
> > hard line breaks
> > when they hit enter, instead of after every physical
> > line. Then,
> > everything works nicely.
> >
> > I'm considering various ways to do this, but I doubt
> > I'll get anything
> > substantial in time for U...
> > --
> > Mike Caron
> > Final Fantasy Q
> > http://finalfantasyq.com
> > _______________________________________________
> > ohrrpgce mailing list
> > [email protected]
> >
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
> >
>
>
>
> Ah, yes, I ran into that same problem when preparing
> .SAY textboxes for display on a phone (which has a
> tall, narrow screen.)
> My solution was to substitute all text strings, and
> then add in newlines at display-time. So, your example
> becomes:
> "Bob: Hello there, my friends and such!\nThis is a
> fine day, is it not?"
> and then:
> "Pedrovich: Hello there, my friends and\n such!\nThis
> is a fine day, is it not?"
>
> I'm sure you'll find your own method, suitable for the
> OHR, but here's my method, just for discussions' sake.
>
>
> (-> SR
>
> Basically, the algorithm goes:
> Add each character, tracking the length of that line
> so far.
> When you find a space:
> If the length is > the allowed length, search
> backwards until you find a space. Create a newline
> here.
> If you don't find a space, hyphenate. Create a
> newline.
How large is the screen on the phones you're using?
_______________________________________________
ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
