working on a picwin script, I have an area I've designated to text. This needs to fit a certain Width and Height.

In order to achieve what you'd expect from a common non-picture window, you have to use $wrap(text,font,size,width,N) where N = 0 is total number of wraps to achieve fitting the string within those bounds. if N is non-zero, it returns the Nth segment of text that will fit within the specified width.

This does work perfect, however, there is no control code backlog, so something like "[k]4really long line" will return lines with N > 1 without prefixing it with whatever control codes remained activated during the previous break calculation.

This results in broken output, when trying to duplicate how /echo behaves.

this is an example of
what would happen if
this is where lines
were broken.

Here is a very simplistic example to create a relatively small window and illustrate this.

Just enter whatever you want as a test into the editbox (ensuring it would force a wrap) include control codes, and notice that new wrap positions aren't given old control code states to keep the line going as expected.

If this isn't a bug, then it'd be a nice feature suggestion to add a .prop for this feature let's say $wrap().cc for instance smile

Code:
alias WrapBug { window -dpfe @WrapBug -1 -1 320 240 }
on *:input:@WrapBug: {
  var %a = @WrapBug , %w = $window(@WrapBug).dw , %h = $window(@WrapBug).dh
  var %x = 0 , %y = $wrap($1-,$window(%a).font,$window(%a).fontsize,%w,0) , %height = $height($1-,$window(%a).font,$window(%a).fontsize)
  while (%x < %y) {
    inc %x
    drawscroll -n %a 0 $calc(%height * -1) 0 0 %w %h
    drawrect -nf %a $color(background) 1 0 $calc(%h - %height) %w %height
    drawtext -np %a $color(normal) 0 $calc(%h - %height) $wrap($1-,$window(%a).font,$window(%a).fontsize,%w,%x)
  }
  drawdot %a
}