Another major change is to scrap the "@" language used in fltk2 (and not really existing in fltk1.3 at all) and instead go with a more html-like language.
The primary reason is so that users familiar with other systems can type in attributed text to fltk. Also this is what Pango takes as input (though it is much too strict). I would NOT copy Qt's or Pango's strict interpretation, but instead support a html-light subset: * Newlines act like <br> and not whitespace. * missing close tags do not produce errors, it acts like they are all at the end of the text. * All unrecognized commands, and syntax errors, just print literally. So printing "1 < 2" and "dick & jane" and "<a href=blah" print plain. * UTF-8 errors also just produce error blocks and continue with the next valid UTF-8 character. The last two points are vital: this function NEVER NEVER NEVER does not print something. If the text ends with an 'x' it ALWAYS prints an 'x' at the end, no matter what horrible garbage is before it. This is vital so that we don't have to have an "unformatted" flag on every widget to get around this. It is reasonably easy to write a parser that turns the input string into a "strict" one if we want to implement this by passing to a backend that barfs if passed incorrect strings. I currently do this for Qt programs. It would certainly be nice if the idiots writing these would fix them to do what we need, but it can be worked around. For Pango it may make sense to take the source code for their html converter and rewrite it, thus translating the string to a lower-level Pango structure. This may also be needed to feed the Windows and OS/X font layout apis. The '@' prefix on Browser items in fltk 1.3 could be preserved if wanted, but perhaps should be scrapped as well. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
