DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending] Link: http://www.fltk.org/str.php?L2348 Version: 1.3-current Now the CR/LF issue has been solved, we have to decide between the two proposed solutions to this STR. 1) Matt's solution: just transfer the file data to the Fl_Text_Buffer widget even if it's not UTF-8 encoded and arrange for the FLTK code to accept these data. Advantage: the input data can be saved and one will recover the original data, whatever its encoding. Drawbacks: - no compatibility with CP1252 under X11 - if the text is modified, the data will become a mixture of UTF-8 and other encodings. 2) The solution proposed in attached file Fl_Text_Buffer2.Patch: only correct UTF-8 data ever enter the Fl_Text_Buffer widget. Thus, the file content differs from the text data when the file is not UTF-8. A warning message informs the user when it happens. I have also prepared the code for future reading of other 8-bit encodings. This will just require to write a function unsigned transcoding(char c); that returns the UCS equivalent of the byte c. Advantages: - compatibility with CP1252 - can be extended to support other encodings in the future - the data in the widget will be homogeneously encoded Drawbacks: - file reading requires more cpu resources - the original file encoding is lost if it's anything but UTF-8 Please, decide what solution is best for 1.3, so this STR can be closed. Link: http://www.fltk.org/str.php?L2348 Version: 1.3-current _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
