Re: [fltk.bugs] [LOW] STR #2947: Drawing Things in FLTK / minor fixes
and I no longer remember my subversion access password] FWIW, I believe there's a process for resetting your password at the right hand side of the login page: http://fltk.org/login.php Thanks for the pointer, Greg That's how I revitalized access from this, my work, address. However, I don't remember my subversion access password [from home] being the same as my mailing list / login account, but I could be wrong. I frequently am. But even if I did recover/reset the subversion access password, that still wouldn't free up any time to work on FLTK [or Lunar Linux] and first I would need that time to resurrect a dead computer... :-( D ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #2947: Drawing Things in FLTK / minor fixes
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2947 Version: 1.3.2 A couple of minor glitches in the 1.3.2 docs on the web site: On the Drawing Things in FLTK page Under the Colors section: there are two Todo markers where doxygen links used to fail, but now work Under the Drawing Fast Shapes: the second, currently duplicate, entry for fl_rectf should be the variant with the additional color parameter Cheers D. [Apart from the fact I have no time, my development box at home as died, and I no longer remember my subversion access password] Link: http://www.fltk.org/str.php?L2947 Version: 1.3.2 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] Permission to translate your page athttp://fltk.org/
2 weeks ago I have asked for your permision to translate your web page and I didn=92t hear any from you since. The problem is that the fltk.bugs forum/mailing list is not intended for direct input from users, but provides feedback from the software trouble reporting system. Therefore not many people read fltk.bugs. You might get a better response by posting in fltk.general instead. ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] button inside loop
this code
for(int i=0;i5;i++){
char u[10];
sprintf(u,%d,i);
new Fl_Button(25*i+20, 50, 25, 25,u);
}
shows all buttons with the same label and it should be incremental.
All of them with the last i, 4.
Because the buffer u goes out of scope at the end of the block,
and the memory is being re-used next time through the loop,
overwriting what the previous buttons were looking at.
You need to save the pointer to the button, temporarily at least,
and then use copy_label() so that the contents of u are copied
into the button itself.
Also, fltk.bugs is now intended for feedback and reporting from
the FLTK Software Trouble Report (STR) system. Few humans read
fltk.bugs directly. Please post user problems to fltk.general.
D.
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #1938: Clean up the downloads page
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1938 Version: Web Site I think this has been covered by Greg's recent update and could be closed. Link: http://www.fltk.org/str.php?L1938 Version: Web Site ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #1970: Unable to add comment to FAQ article
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1970 Version: Web Site This is probably also linked to STRs 2099, 2100 and 2213. I was able to add a comment to Article #366 but this was limited to a paragraph tag and the link to Article #825 which replaces it, so it may be that they type of tags influences behaviour. PS. This is the second attempt to post here - maybe I forgot to fill in one of the fields last time and didn't notice... Link: http://www.fltk.org/str.php?L1970 Version: Web Site ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: expected ‘;’ before string constant when in Fl.H
Hello, when i try to compile my program I get the following message: /usr/local/include/FL/Fl.H:247:28: error: expected unqualified-id before string constant /usr/local/include/FL/Fl.H:247:28: error: expected â;â before string constant I only inludes the fltk header file. There is no code using some fltk components so far. You have to be more specific about the version of FLTK, which platform, and which compiler you are trying to use. Please note that fltk.bugs is for the output from the automated STR system, for tracking problem reports with FLTK itself. Please post your response to fltk.general if you want further help. ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] 1.3.0 freezes in Fl_Menu_Item
Let me add that I am running Slackware 13.37 on a 686 with kernel 2.6.37.6 and gcc/g++ 4.5.2. the fltk.bugs forum/newsgroup/mailing list is used to provide feedback from the Software Trouble Report system into bugs in the fltk libraries If you want feedback on problems in your own code, you are probably better off re-posting to fltk.general as more real people read this than fltk.bugs ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2521: Large quantity of Linker Warnings Creating fltk_images in VisualC++ V6
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2521 Version: 1.3.0 Fix Version: 1.3-current (r8298) AS for fl_utf.c/mk_wcwidth.c: I believe that we don't use mk_wcwidth, because this was only a test, and Matt implemented it differently, but I didn't check. Maybe Duncan knows more about it. mk_wcwidth.c is Markus Kuhn's implementation of wcwidth giving the width of Unicode characters in columns which we thought we might need a year ago to allow Fl_Text_Display. Matt then rewrote Fl_Text_* without the concept of fixed width fonts because it wasn't clear whether this made sense for non-Latin characters. Unless someone experienced in CJK or Arabic or Indic scripts can make a case for having fixed width fonts we probably don't need this file. Unfortunately it's a chicken and egg situation: when we didn't support UTF-8 / Unicode, we were unlikely to have users with such experience. D. Link: http://www.fltk.org/str.php?L2521 Version: 1.3.0 Fix Version: 1.3-current (r8298) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2505: Xft backend doesn't filter bad UTF-8 characters
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2505 Version: 1.3-current Do you mean than instead of having a byte stream containing a series of valid UTF-8 sequences of header byte and correct number of trailing bytes, you have sequences that contain a header byte and the incorrect number of trailing bytes? Ie, a correct two byte sequence would be 110x 10xx but the stream contains 110x 110y 10yy so the first UTF-8 sequence has been truncated Link: http://www.fltk.org/str.php?L2505 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2504: HAVE_CAIRO macro in installed header
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2504 Version: 1.3-current Note that one of the STRs resolved recently involved the use of USE_CAIRO/HAVE_CAIRO in the CMake configuration files, and these are probably separate from the macros in the source code itself. Maybe. Link: http://www.fltk.org/str.php?L2504 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2348: test/editor fails to display misc/cp1252.txt and can hang
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 What I think is that all text should be stored in FLTK as UTF-8, with no exceptions. We've all seen how complicated the Fl_Text_* classes were before in order to store one thing [raw bytes] and display, select, and edit another [expanded ctrl representations]. Every place where text can enter the FLTK system needs to be able to convert from raw bytes to UTF-8, and raise a flag so that the user knows if that text has been converted. So from that point of view, and so that we can make progress towards the 1.3.0 release, I'm happy for you to apply your patch and we can close this STR. However, I think that we need to raise an STR/RFE against 1.4 to discuss how we can support not just the CP1252 superset of ISO-8859-1, but also all of the other ISO-8859-* character sets (which would give us all of the characters needed by European languages, and some Arabic and Hebrew too). I shall raise the question in fltk.development now... Link: http://www.fltk.org/str.php?L2348 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2348: test/editor fails to display misc/cp1252.txt and can hang
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 Manolo: 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. ... 2) The solution proposed in attached file Fl_Text_Buffer2.Patch: only correct UTF-8 data ever enter the Fl_Text_Buffer widget. ... Option 1 of keeping the original text but make the code jump through hoops in order to work round unknown characters seems wrong to me and will mean adding spaghetti code on top of other spaghetti code. I would favour option 2 *but* I think that the proposal as it stands is still too hard coded using static functions, and it would be much better if we could define a class interface that could be used so that we can add classes over time, and application developers can add or override character set translations if required, and we can also extend to handle multibyte character encodings. I'm just worried that an interim fix to get 1.3.0 out of the door becomes fixed in stone and even more difficult to replace/extend later. HOWEVER, as I have no time to contribute any code until mid-January and therefore after the 1.3.0 release, I shall go with the flow... Link: http://www.fltk.org/str.php?L2348 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2348: test/editor fails to display misc/cp1252.txt and can hang
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2348
Version: 1.3-current
Manolo wrote:
It seems difficult to support all 8-bit encodings because there were
so many, (this fact is the most compelling justification for UTF).
However, the case for supporting CP152 as input has been considered
valid in recent discussions here because a large number of legacy
files use this encoding.
...
proposal + read_options enum
Is there no way that we can provide character set readers via a plugin
that also encapsulates an identifier rather than hard-code these using
an enum? The default/base plugin provided by the FLTK core would be
pure UTF-8. We could also possible provide ISO-8859-1, CP-1252 and
MacRoman. User contributed plugins for other ISO-8859-* and Mac*
character sets could be provided via an additional library.
As I'm only thinking about 8-bit character sets at the moment, the
plugin would only need to provide a 256-entry lookup table from byte
to UTF-8 values. [Reverse mapping could be handled via Albrecht's
private range UTF-8 suggestion]. My initial idea was something like
the following, (typed off the top of my head, so likely to have errors)
class CharacterSet
{
public:
// return identifier string
virtual const char* identifier() const;
// returns ucs value for byte
virtual unsigned int byteToUcs(unsigned char byte);
// returns true if ucs can be mapped to single byte
virtual bool ucsMapsToByte(unsigned int ucs);
// returns byte value corresponding to ucs
virtual unsigned char ucsToByte(unsigned int ucs);
// returns true if input text required conversion
virtual bool convert(const char* input, char* output, int *len);
};
The plugin would add its identifier to a CharacterSet registry so that
if could be searched, and offered via preferences, combo box, etc.
Not sure about the convert() method, as it could involve an extra
layer of string copying (not very Fast and Light) and also raises
questions abut who allocates/frees the output buffer.
Or maybe there could be a fileRead method that is passed a FILE*
and does the conversion on the fly? Again the interface is not clear.
To handle 16-bit encodings would obviously need a different API.
Maybe we could pass char* and let the plugin decode as appropriate.
Whatever scheme we introduce to solve this STR for FLTK-1.3.0, I
think we will probably need to change the API once we have gained
experience in its use.
Link: http://www.fltk.org/str.php?L2348
Version: 1.3-current
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2348: test/editor fails to display misc/cp1252.txt and can hang
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 I love it! Everyone's been looking at different and complicated ways of doing the Right Thing (tm) and Matt just tweaks the fl_utf8len() error return to make it a non-error return. Lateral thinking :-) Plus the simple solution to partial UTF-8 sequences at the end of a read buffer - just read the whole file in one slurp! LOL. Seriously though, this change does mean that test/editor doesn't hang or crash or assert when reading misc/cp1252.txt so I suppose I have to admit that it's solved as far as getting fltk-1.3.0 out of the door. [It would have been useful to display ? of upside-down ? or something to show that there were actually characters there, because moving the cursor over the 0x80-0x9F characters with the cursor keys doesn't give much feedback that there's actually something happening, but that can now be a feature request for 1.3.1] So as far as I'm concerned, you can close this one. Link: http://www.fltk.org/str.php?L2348 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2348: test/editor fails to display misc/cp1252.txt and can hang
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 IMHO, it makes more sense in the long term to simply tell the user that the file text was converted during input and let them decide whether to save it at the end or not, rather then introduce kludges to cope with special or unsupported characters everywhere. The user should be warned, rather than the file silently modified. Link: http://www.fltk.org/str.php?L2348 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2348: test/editor fails to display misc/cp1252.txt and can hang
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2348 Version: 1.3-current From what I can see, and I haven't looked at the patch in detail, the conversion is hard-coded and this will prevent anyone from using Fl_Text_Editor with anything other than ascii + pure utf8, ISO-8859-1, or CP1252. All of the other ISO-8859 variations, and the Mac-* pages for Cyrillic, Arabic, Hebrewm etc will be excluded. What I had in mind was more of a plugin class that would convert any top-bit encoding... Link: http://www.fltk.org/str.php?L2348 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2348: test/editor fails to display misc/cp1252.txt and can hang
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2348
Version: 1.3-current
But if I change something and write the file, then the original
encoding is lost and converted to UTF-8 w/o a warning or anything
else.
Is there actually a dirty or modified flag set when changes are
made to the text in Fl_Text_{Buffer,Display,Editor} ? If there is,
it's not obvious.
Adding such a flag could be the first step here, as it would allow
the editor (or whatever called inserfile) to check whether the text
was modified and warn the user before real editing begins...
Link: http://www.fltk.org/str.php?L2348
Version: 1.3-current
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2348: test/editor fails to display misc/cp1252.txt and can hang
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2348 Version: 1.3-current Yes, there's a changed flag in test/editor.cxx, but there is no modified or dirty flag in the Fl_Text_* classes as far as I can see. Would it help to add one? I don't see any other way of solving this STR without one[*]. If we modify the input text to make it 100% UTF-8 then we have to be able to report this to the user. But unless we have complementary input2utf and utf2input plugins for each encoding we don't have a way of unchanging converted text, and even then we can't guarantee that we can unchange it back to the original. [*] or one flag for modified during conversion of input to UTF-8 and one for modified by the user during editing. Link: http://www.fltk.org/str.php?L2348 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2348: test/editor fails to display misc/cp1252.txt and can hang
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2348 Version: 1.3-current I have been considering, but have not had the time to experiment, to add member variable to Fl_Text_Buffer that is a pointer to a CharacterSet class (or some such name). The buffer read from file is filtered through the CharacterSet object, and all plain ascii is passed through, valid UTF8 sequences are passed through, but any other bytes with the top bit set, would need to be mapped to UTF-8 via a lookup table in the class and then passed through. Maybe with an append method like Roman suggested. I hadn't thought about incomplete sequences, but maybe if there is a ring-buffer involved somewhere, the next read statement would complete any trailing incomplete UTF-8 sequences and processing could continue at the start of the sequence rather than the middle. We could provide the base class (valid ascii and UTF-8 only), plus one for Latin1 (ISO-5589 or whatever it is) and another for CP1252. Users would be free to implement their own classes that mapped top-bit bytes to whatever UTF-8 they wanted. Unfortunately this is still just an idea as my time is limited :-( Link: http://www.fltk.org/str.php?L2348 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2317: modify cmake files for cross-compile
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2317
Version: 1.3-current
Fix Version: 1.3-current (r7452)
Well I'm no Cmake expert, but ...
I checked out r7914 but the cmake_consolidated_r7907.patch failed
so I went back to r7909 (by mistake) and the patch applied.
I used cmake -DCMAKE_INSTALL_PREFIX=/tmp/fltk to build and install.
I set PATH=/tmp/fltk/bin:$PATH
I copied test/keyboard* to a scratch directory, and created the
following CMakeLists.txt file:
cmake_minimum_required(VERSION 2.6)
project(demo)
find_package(FLTK REQUIRED NO_MODULE)
include(${FLTK_USE_FILE})
fltk_wrap_ui(demo keyboard_ui.fl)
add_executable(demo WIN32 keyboard.cxx ${demo_FLTK_UI_SRCS})
add_dependencies(demo ${FLTK_FLUID_EXECUTABLE})
target_link_libraries(demo fltk)
and was able to build the keyboard demo, as demo, on 64-bit Linux.
Not sure how that helps with the cross-compile part though :-(
Link: http://www.fltk.org/str.php?L2317
Version: 1.3-current
Fix Version: 1.3-current (r7452)
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #2458: Update copyright notices to 2010
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2458 Version: 1.3-current Most of the source code and documentation still has (C) 2009 or earlier. Those that don't already say 2010 should be updated before 1.3.0 release. Link: http://www.fltk.org/str.php?L2458 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2458: Update copyright notices to 2010
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2458 Version: 1.3-current Wow, I didn't mean a dedicated Copyright fix now this instant, as I could have done that over the next few days without taking the time of our core developer. Great job Matt. Thank you. Link: http://www.fltk.org/str.php?L2458 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2348: test/editor fails to display misc/cp1252.txt and can hang
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2348
Version: 1.3-current
Link: http://www.fltk.org/str.php?L2348
Version: 1.3-currentIndex: src/Fl_Text_Buffer.cxx
===
--- src/Fl_Text_Buffer.cxx (revision 7860)
+++ src/Fl_Text_Buffer.cxx (working copy)
@@ -1024,7 +1024,7 @@
*foundPos = startPos;
return 1;
}
-int l = fl_utf8len(c);
+int l = fl_utf8len(c); // TODO: replace?
if (memcmp(sp, address(bp), l))
break;
sp += l; bp += l;
@@ -1076,7 +1076,7 @@
*foundPos = startPos;
return 1;
}
-int l = fl_utf8len(c);
+int l = fl_utf8len(c); // TODO: replace?
if (memcmp(sp, address(bp), l))
break;
sp += l; bp += l;
@@ -1560,6 +1560,29 @@
/*
+ * temporary functions for debug purposes
+ */
+void printByte(const char byte) {
+ if (' ' = byte byte = '~')
+printf( %c, byte);
+ else
+printf(0x%02hhx, byte);
+}
+void printBytes(int pos, const char byte) {
+ printf(pos = %d byte = [, pos);
+ printByte(byte);
+ printf(]\n);
+}
+void printBytes(int pos, const char* bytes, int n) {
+ printf(pos = %d bytes = [, pos);
+ for (int i = 0; i n bytes[i] != '\0'; i++) {
+printByte(bytes[i]);
+printf(,);
+ }
+ printf(]\n);
+}
+
+/*
Return the previous character position.
Uncode safe.
*/
@@ -1570,6 +1593,15 @@
IS_UTF8_ALIGNED2(this, (pos))
+ char bytes[10]; memset(bytes, '\0', 10); // longest UTF-8 sequence is 6
bytes
+ int b = pos;
+ for (int i = 0; i 10 b 0; i++, b--)
+bytes[10-1-i] = byte_at(pos-i);
+ const char* p = bytes[10-1];
+ const char* q = fl_utf8back(p-1, bytes[b], p);
+ int d = p - q;
+ pos = pos - d;
+/*
char c;
do {
pos--;
@@ -1577,7 +1609,7 @@
return 0;
c = byte_at(pos);
} while ( (c0xc0) == 0x80);
-
+*/
IS_UTF8_ALIGNED2(this, (pos))
return pos;
}
@@ -1593,13 +1625,23 @@
return prev_char_clipped(pos);
}
-
/*
Return the next character position.
Returns length() if the end of the buffer is reached.
*/
int Fl_Text_Buffer::next_char(int pos) const
{
+ char bytes[10]; memset(bytes, '\0', 10); // longest UTF-8 sequence is 6
bytes
+ for (int i = 0; i 10 pos+i mLength; i++)
+bytes[i+0] = byte_at(pos+i);
+ const char *p = bytes[0];
+ const char *q = fl_utf8fwd(p+1, p, p+6);
+ int d = q - p;
+ pos += d;
+ if (pos = mLength)
+return mLength;
+ return pos;
+ /*
IS_UTF8_ALIGNED2(this, (pos))
int n = fl_utf8len(byte_at(pos));
pos += n;
@@ -1607,6 +1649,7 @@
return mLength;
IS_UTF8_ALIGNED2(this, (pos))
return pos;
+ */
}
@@ -1624,14 +1667,53 @@
*/
int Fl_Text_Buffer::utf8_align(int pos) const
{
+ char bytes[10]; memset(bytes, '\0', 10); // longest UTF-8 sequence is 6
bytes
+ int b = pos;
+ for (int i = 0; i 10 b 0; i++, b--)
+bytes[10-1-i] = byte_at(pos-i);
+ const char* p = bytes[10-1];
+ const char* q = fl_utf8back(p, bytes[b], p);
+ int d = p - q;
+ return (d == 0) ? pos : pos-d;
+/*
char c = byte_at(pos);
while ( (c0xc0) == 0x80) {
pos--;
c = byte_at(pos);
}
return pos;
+*/
}
+/*
+ * temporary routines for use in IS_UTF8_ALIGN macros
+ */
+int isUtf8Aligned(const char* s) {
+ if (s *s fl_utf8len(*s)=0) {
+const char* p = fl_utf8fwd(s, s, s+6);
+if (p == s)
+ return 1;
+return 0;
+ }
+ return 1;
+}
+int isUtf8Aligned(const Fl_Text_Buffer* tb, int pos) {
+ if (pos 0 || pos = tb-length())
+return 1;
+
+ char bytes[10]; memset(bytes, '\0', 10); // longest UTF-8 sequence is 6
bytes
+ int len = min(10-1, tb-length() - pos);
+ for (int i = 0; i len; i++)
+bytes[i] = tb-byte_at(pos+i);
+ const char* p = bytes[0];
+ const char* q = fl_utf8fwd(p, p, p+6);
+ if (p == q)
+return 1;
+ if (pos=0 postb-length() fl_utf8len(tb-byte_at(pos))=0)
+return 0;
+ return 1;
+}
+
//
// End of $Id$.
//
Index: src/Fl_Text_Display.cxx
===
--- src/Fl_Text_Display.cxx (revision 7860)
+++ src/Fl_Text_Display.cxx (working copy)
@@ -84,7 +84,35 @@
// CET - FIXME
#define TMPFONTWIDTH 6
+/* fl_utf8len(char b) replacement that handles CP1252 C1 control chars, etc.
+ * temporary name to aid finding and replacing the originals
+ * temporary location to minimize file changes
+ */
+int fl_drg8len(const char* s)
+{
+ int n = 0;
+ unsigned ucs = fl_utf8decode(s, 0, n);
+ ucs = ucs + 1; // keep g++ quiet
+ return n;
+}
+/* even more temporary version with added debug
+ */
+int fl_drg8len(const char* s, const char* f)
+{
+ int m = fl_utf8len(*s);
+ int n = fl_drg8len(s);
+ if (m != n) {
+// printf(%s: utf8len=%d drg8len=%d , f, m, n);
+// for (int i = 0; i max(m,n); i++) {
+//
Re: [fltk.bugs] [HIGH] STR #2348: test/editor fails to display misc/cp1252.txt and can hang
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2348 Version: 1.3-current I've just attached svn-diff-against-r7855.txt which I think solves this problem, but it's still very much a work in progress that needs to have someone else's expert eye casting over it. There are some functions that need renaming and relocating into the correct files. This patch addresses two different issues: 1. the use of fl_utf8len(char c) and other byte-by-byte walking through the Fl_Text_Buffer ring buffer which fails if the text contains CP1252 C1 control characters. I've introduced an almost equivalent fl_drg8len(char* s) function (to be renamed) that uses fl_utf8decode() to calculate the length of the byte sequence starting at s. I've updated next_char() and prev_char() to copy some bytes from the ring buffer into an array so that I can call fl_utf8fwd() and fl_utf8back() to determine how many bytes to move the pos value. Various other places where fl_utf8len(c) is called or byte values are examined have also been changed. There are a couple of uses left over that I'm not sure about. These changes allow the arrow keys to work on the lines for octal 200 and above without hanging the application or exiting with an assert message, but there is no obvious cursor movement until you reach the next line. Note the replacement of the body of the IS_UTF8_ALIGN macros with functions to enable better debug reporting, etc. 2. I've introduced a drgExpand() function in Fl_Text_Display.cxx that converts a CP1252 string into its full UTF-8 equivalent. This can then be passed to fl_width() and fl_draw() otherwise they don't work correctly because they only handle exclusively UTF-8 strings. The conversion is done to a temporary char array so that the current positions and location pointers into the text and style buffers don't need to be changed. Unfortunately this means that there is a lot of string rewriting every time that text is measured or drawn. Obviously this drgExpand() function should be renamed and relocated if we decide to continue with this solution. I think that just leaves one routine where fl_utf8len(c) is called with a UCS value rather than a byte, which is just plain wrong. I shall raise an RFC in fltk.development to discuss this further. Link: http://www.fltk.org/str.php?L2348 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2348: test/editor fails to display misc/cp1252.txt and can hang
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2348 Version: 1.3-current See the fltk.development thread RFC: Pure UTF-8 or Hybrid CP1252 ? at http://www.fltk.org/newsgroups.php?gfltk.development+v:10979 Link: http://www.fltk.org/str.php?L2348 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2317: modify cmake files for cross-compile
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2317 Version: 1.3-current Fix Version: 1.3-current (r7452) No problem. It was just difficult to see which of the patches had, and had not been applied. FWIW I subsequently performed a full Cmake install on a 64-bit Linux box and everything seems OK. Link: http://www.fltk.org/str.php?L2317 Version: 1.3-current Fix Version: 1.3-current (r7452) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2328: fltk-1.3.0-r7246 Build brokenon fedora 12 by fluid.destop
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2328 Version: 1.3.0 http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html states that the %D is deprecated, so the file should be reworked. Link: http://www.fltk.org/str.php?L2328 Version: 1.3.0 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2348: test/editor fails to display misc/cp1252.txt and can hang
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2348 Version: 1.3-current I've been wondering about this since Albrecht queried whether fl_utf8fwd() and fl_utf8back() would work in the Fl_Text_Buffer ring buffer, but since then I've been waiting to see what Matt had up his sleeve at the end of the mega-refactoring. I had wondered whether it would be possible to extend next_char() and prev_char() so that they copied the current and next/prev six bytes (max possible utf8 sequence) into a temporary buffer, and then called fl_utf8fwd/back() to determine how many byte positions to move forward/backward. Or to provide Fl_Text_* member function equivalents for fl_utf8fwd() and fl_utf8back() that were gap aware and use these exclusively. I have to admit that I haven't looked at the Fl_Text_* code in any detail since the refactoring, so don't know whether this trick could also be used in the other places where the code steps through and compares against 0x80 on a byte-by-byte basis. My own feeling is that although it would simplify life to convert the cp1252 0x80-0x9f C1 control characters to something else, users might not be so happy if their files were silently changed for them. Whether we display ? or [] or an equivalent character is a detail. Link: http://www.fltk.org/str.php?L2348 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2328: fltk-1.3.0-r7246 Build brokenon fedora 12 by fluid.destop
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2328 Version: 1.3.0 I'm no expert on .desktop files, but shouldn't they actually be installed in some standard location so that they can be found ? fluid.desktop and x-fluid.desktop don't seem to get installed. Found it! They aren't installed as part of a normal make install but are installed by make install-desktop. As these are *always* installed under /usr/share so that the desktop environments can find them, regardless of any --prefix setting, the make install-desktop has to be run as root. I'm adding notes to the README and README.Unix to explain this. Link: http://www.fltk.org/str.php?L2328 Version: 1.3.0 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2328: fltk-1.3.0-r7246 Build brokenon fedora 12 by fluid.destop
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2328 Version: 1.3.0 Fix Version: 1.3-current (r7830) Fixed in Subversion repository. fluid.desktop corrected (removing deprecated %D) README and README.Unix updated to describe install-desktop Link: http://www.fltk.org/str.php?L2328 Version: 1.3.0 Fix Version: 1.3-current (r7830) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2441: const correctness of strchr in fluid/Fl_Function_Type.cxx
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2441 Version: 1.3-current Fix Version: 1.3-current (r7824) Fixed in Subversion repository. Link: http://www.fltk.org/str.php?L2441 Version: 1.3-current Fix Version: 1.3-current (r7824) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2422: CMake-based builds lack libXinerama
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2422
Version: 1.3-current
I've just installed fltk-1.3.x-r7824 (from svn not snapshot) on Linux
and followed the basic instructions in README.Cmake_build except that
I installed into a temporary directory:
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/tmp/fltk ..
make
make install
I can compile the following program:
#include FL/Fl.H
#include stdio.h
int main(int argc, char* argv[])
{
int screens = Fl::screen_count();
printf(number of screens = %d\n, screens);
return 0;
}
using the command line:
g++ -I/tmp/fltk/include \
-DUSE_X11 -D_THREAD_SAFE -D_REENTRANT -D_FILE_OFFSET_BITS=64 \
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE \
-o 'testing' 'testing.cxx' \
/tmp/fltk/lib/libfltk.a -lX11 -lpthread -lXinerama -lXft -lXext
This links without problem and the program confirms I have one screen.
It works for me, so can you provide more information on your problem?
Link: http://www.fltk.org/str.php?L2422
Version: 1.3-current
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2443: Cmake install to non-standard prefix gives fltk-config problem
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2443 Version: 1.3-current I installed fltk-1.3.x-r7824 into a temporary directory, and then set the installation prefix to a non-standard location: mkdir build cd build cmake -DCMAKE_INSTALL_PREFIX=/tmp/fltk .. make make install If I then try to compile a program: fltk-config --compile testing.cxx then the compilation fails because the relevant -I is missing: g++ -I \ -DUSE_X11 -D_THREAD_SAFE -D_REENTRANT -D_FILE_OFFSET_BITS=64 \ -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE \ -o 'testing' 'testing.cxx' \ /tmp/fltk/lib/libfltk.a -lX11 -lpthread -lXinerama -lXft -lXext instead of: g++ -I/tmp/fltk/include \ -DUSE_X11 -D_THREAD_SAFE -D_REENTRANT -D_FILE_OFFSET_BITS=64 \ -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE \ -o 'testing' 'testing.cxx' \ /tmp/fltk/lib/libfltk.a -lX11 -lpthread -lXinerama -lXft -lXext Link: http://www.fltk.org/str.php?L2443 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2317: modify cmake files for cross-compile
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2317 Version: 1.3-current Fix Version: 1.3-current (r7452) Mike and Albrecht, how complete is your testing and incorporation of the patches above? I've just found that fltk-config provides an incomplete -I option if the cmake build is installed into a non-standard prefix, but rather than overload this STR further, I've opened a new one at: http://www.fltk.org/newsgroups.php?gfltk.bugs+v:9342 D. Link: http://www.fltk.org/str.php?L2317 Version: 1.3-current Fix Version: 1.3-current (r7452) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2376: Unicode rendering and navigation
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2376 Version: 1.3-feature Link: http://www.fltk.org/str.php?L2376 Version: 1.3-feature ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2432: UTF-8 characters output broken on ARM architecture
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2432 Version: 1.3-current Link: http://www.fltk.org/str.php?L2432 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2422: CMake-based builds lack libXinerama
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2422 Version: 1.3-current Link: http://www.fltk.org/str.php?L2422 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2423: CMake build on Mac does not define __APPLE_QUARTZ__
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2423 Version: 1.3-current Link: http://www.fltk.org/str.php?L2423 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #1973: autotools build badly broken on 64-bit Linux
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1973 Version: 1.4-feature Link: http://www.fltk.org/str.php?L1973 Version: 1.4-feature ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2443: Cmake install to non-standard prefix gives fltk-config problem
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2443 Version: 1.3-current Fix Version: 1.3-current (r7825) Fixed in Subversion repository. Link: http://www.fltk.org/str.php?L2443 Version: 1.3-current Fix Version: 1.3-current (r7825) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2317: modify cmake files for cross-compile
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2317 Version: 1.3-current Fix Version: 1.3-current (r7452) And closed it again in r7825 (fixed typo in fltk-config.cmake.in :-) Link: http://www.fltk.org/str.php?L2317 Version: 1.3-current Fix Version: 1.3-current (r7452) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #1604: Explicit reference to installed examples directory would be useful
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L1604 Version: 1.3-current Fix Version: 1.3-feature (r7731) Fixed in Subversion repository. Link: http://www.fltk.org/str.php?L1604 Version: 1.3-current Fix Version: 1.3-feature (r7731) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2408: fltk-config --libs produces newline
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2408 Version: 1.1.10 Good catch! I wasn't sure whether the fltk-config.cmake.in was even being used, and as I'm not using cmake either I didn't notice the failure, but as it was a direct cut'n'paste out of fltk-config.in I don't know how I managed to lose those lines :-( Link: http://www.fltk.org/str.php?L2408 Version: 1.1.10 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2381: Crash within Fl_Glut_Window::handle() after arising the mouse wheel event.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2381
Version: 1.1.10
Please note that this problem is unlikely to be fixed in the FLTK-1.1
series because FLTK-1.1.10 was the last planned release of the series.
However, here is a fix which I will commit to the FLTK-1.3.x branch,
and which you can apply manually to your local copy of 1.1.10.
case FL_MOUSEWHEEL:
button = Fl::event_dy();
while (button 0) {if (mouse) mouse(3,GLUT_DOWN,ex,ey); ++button;}
while (button 0) {if (mouse) mouse(4,GLUT_DOWN,ex,ey); --button;}
return 1;
Does that solve your problem or have I misunderstood what you meant?
Link: http://www.fltk.org/str.php?L2381
Version: 1.1.10
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2408: fltk-config --libs produces newline
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2408 Version: 1.1.10 Please note that this problem is unlikely to be fixed in the FLTK-1.1 series because FLTK-1.1.10 was the last planned release of the series. However, I attach a patch that I will commit to the FLTK-1.3.x branch that will solve this problem, which you can apply manually to your local copy of 1.1.10. Note that some combinations of options for fltk-config will still give multiline output because it is unlikely that you will use them together, e.g. fltk-config --cflags --cxxflags Link: http://www.fltk.org/str.php?L2408 Version: 1.1.10 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2408: fltk-config --libs produces newline
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2408 Version: 1.1.10 Link: http://www.fltk.org/str.php?L2408 Version: 1.1.10Index: fltk-config.in === --- fltk-config.in (revision 7812) +++ fltk-config.in (working copy) @@ -358,29 +358,31 @@ fi if test $echo_libs = yes; then -echo $libdir/libfltk.a +USELIBS=$libdir/libfltk.a if test x$use_forms = xyes; then -echo $libdir/libfltk_forms.a +USELIBS=$libdir/libfltk_forms.a $USELIBS fi if test x$use_gl = xyes; then -echo $libdir/libfltk_gl.a +USELIBS=$libdir/libfltk_gl.a $USELIBS fi if test x$use_cairo = xyes; then -echo $libdir/libfltk_cairo.a +USELIBS=$libdir/libfltk_cairo.a $USELIBS fi if test x$use_images = xyes; then -echo $libdir/libfltk_images.a +USELIBS=$libdir/libfltk_images.a $USELIBS for lib in fltk_jpeg fltk_png fltk_z; do if test -f $libdir/lib$lib.a; then -echo $libdir/lib$lib.a +USELIBS=$libdir/lib$lib.a $USELIBS fi done fi + +echo $USELIBS fi # ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2408: fltk-config --libs produces newline
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2408 Version: 1.1.10 This is now fixed in FLTK-1.3.x-r7813 (but remains unfixed in 1.1.10) Link: http://www.fltk.org/str.php?L2408 Version: 1.1.10 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2373: Enhanced color docummentation
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2373 Version: 1.1.10 Fix Version: 1.3-current (r7762) Fixed in Subversion repository. Link: http://www.fltk.org/str.php?L2373 Version: 1.1.10 Fix Version: 1.3-current (r7762) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2158: In Fl_Text_Display, word wrapping do not work when mixing with unicode ata .
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current Fix Version: 1.3.0 (r7812) Fixed in Subversion repository. Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current Fix Version: 1.3.0 (r7812) Great work Matt, the code looks a lot cleaner than before, but this STR ended up raising more issues that just wrap_mode. Are you sure this also addresses the 2 column per CJK character issue raised by Sparkaround? The previous commit didn't and I can't see anything in the diff beyond colNum++. Shouldn't there also be a call to fl_wcwidth()? And what about line breaking on other characters, and given in fl_is_linebreak() in Timothy Lee's patch in another STR? Or do you intend to re-raise these as new STRs? Cheers Duncan. ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2376: Unicode rendering and navigation
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2376 Version: 1.3-feature That's a very good question! Unless the underlying Fl_Text_Buffer guarantees that the whole UTF-8 sequence is inserted before or after the gap, but not spanning the gap, then probably not. But these changes are moot anyway, because Matt has just committed some mega-changes to the Fl_Text_* classes, which include updates to Fl_Text_Display::move_left() and move_right() to use improved member functions from Fl_Text_Buffer. Link: http://www.fltk.org/str.php?L2376 Version: 1.3-feature ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2376: Unicode rendering and navigation
Me: But these changes are moot anyway, because Matt has just committed some mega-changes to the Fl_Text_* classes, which include updates to Fl_Text_Display::move_left() and move_right() to use improved member functions from Fl_Text_Buffer. Albrecht: Yep, I've seen Matt's commit _after_ my post to the STR. I didn't see the commit until after I'd added to the STR either. Will need to take the new version for a proper test run tonight. ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2376: Unicode rendering and navigation
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2376
Version: 1.3-feature
For the left/right arrow key navigation I've got the following
in my sandbox, and obviously they require further cleaning, but
I think these do what you require:
pre
/** Moves the current insert position right one character.*/
int Fl_Text_Display::move_right() {
int ok = 0;
while (!ok) {
if ( mCursorPos = mBuffer-length() )
return 0;
const char *here = buffer()-address( mCursorPos );
const char *there = fl_utf8fwd(here+1, here, here+6);
int bytes = there - here;
insert_position( mCursorPos + bytes );
int pos = insert_position();
// FIXME: character is ucs-4
char c = buffer()-character( pos );
if (!((c 0x80) !(c 0x40))) ok = 1;
}
return 1;
}
/** Moves the current insert position left one character.*/
int Fl_Text_Display::move_left() {
int ok = 0;
while (!ok) {
if ( mCursorPos = 0 )
return 0;
const char *here = buffer()-address( mCursorPos );
const char *there = fl_utf8back(here-1, here-6, here);
int bytes = here - there;
insert_position( mCursorPos - bytes );
int pos = insert_position();
// FIXME: character is ucs-4
char c = buffer()-character( pos );
if (!((c 0x80) !(c 0x40))) ok = 1;
}
return 1;
}
/pre
If the pointer already points to a valid ASCII or UTF8 header byte,
then fl_utf8fwd simply returns the same pointer, so you have to
increment it before/as you pass it, hence the here+1. The here+6 is
because the longest possible UTF-8 sequence allowed is six bytes,
although in practice it's four. Similarly for move_left/fl_utf8back.
I'm also looking at your patch but I haven't yet seen any before
and after changes in behaviour during my testing, so still looking.
Not sure how UTF-8 sequences affect the parallel style buffer...
Any feedback welcome.
Link: http://www.fltk.org/str.php?L2376
Version: 1.3-feature
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2226: Misc doc modifications
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2226 Version: 1.3-current Fix Version: 1.3-current Summary update: (FIX:r6889) Docs for Fl_XXX_Multiline.. (FIX:r7770) Docs for Fl_Widget::color().. (duncan) (FIX:r6836) Docs for delete_widget().. (albrecht) (FIX:r6856) Fl_Menu_add.cxx: docs for add() need clarification (erco) (FIX:r6890) Docs for Fl::event_key().. (FIX:r6890) Docs for Fl::event_text().. (FIX:r7770) Docs for fl_show_colormap().. (duncan) Someone needs to check fl_show_colormap() image size in LaTeX... Link: http://www.fltk.org/str.php?L2226 Version: 1.3-current Fix Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2410: WIN32 COMCTL32.lib library incorrectly named in documentation
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2410 Version: 1.1.10 Looks like Albrecht already fixed this for fltk-1.3.x-r6792 Should we move this to 1.3 and close it, or mark it Won't fix here? Link: http://www.fltk.org/str.php?L2410 Version: 1.1.10 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] fltk 2.0.x r7704 build problem on Fedora 13
I had several problems building r7704 on Fedora 13: Linking fluid2 required adding -lXrender -lfontconfig to LDLIBS in makeinclude. Linking various test progs required adding -lXrender -lfontconfig -lfreetype to GLDLIBS. After that the build completed fine. If you could go to http://www.fltk.org/str.php and Submit to file a bug report, and then attach the 'svn diff' against r7704, that would (a) mean the problem is tracked in the system and will not be forgotten, and (b) you save the developer(s) having to redo all of your detective work, bearing in mind that FLTK-2 development is rather dormant. Note that fltk.bugs is not intended for direct human mailings, but is supposed to be a sort of read-only feedback channel for the bug tracking system, and not many real users actually read it. If you want to discuss other problems, raise them in fltk.general, as there are more people there who are likely to answer. Cheers D ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2376: Unicode rendering and navigation
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2376
Version: 1.3-feature
cope with some kind of extended ASCII *and* UTF8 at the same time?
We have had several discussions about whether this is desirable, or
whether we should aim for strict UTF8, and the answer is unclear.
This looks plain wrong to me:
char c = buffer()-character( pos );
if (!((c 0x80) !(c 0x40))) ok = 1;
[and the nested for loop code]
The original FLTK-1.1 code was completely unaware of UTF-8, and all
handling is based on byte indexing and comparison. Most of the code
is fairly simple to convert to use UTF-8 because it doesn't do any
character processing as such. The Fl_Text_{Buffer,Display,Editor}
code was derived from NEdit, and handles lots of complicated things
that don't play well with aspects of UTF-8/Unicode that nobody had
thought about before, and doesn't handle other things required for
certain UTF-8/Unicode character sets, e.g. proportional fonts, and
columns per character.
The code is in an interim state. We know that some methods such as
character() are not strictly correct, but are just steps in the
gradual refactoring of the code. The Fl_Text_* widgets are code
monsters, so progress to refactor them completely has been slow.
Link: http://www.fltk.org/str.php?L2376
Version: 1.3-feature
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2158: In Fl_Text_Display, word wrapping do not work when mixing with unicode ata .
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2158
Version: 1.3-current
Link: http://www.fltk.org/str.php?L2158
Version: 1.3-current#include FL/Fl.H
#include FL/Fl_Double_Window.H
#include FL/Fl_Group.H
#include FL/Fl_Int_Input.H
#include FL/Fl_Output.H
#include FL/fl_ask.H
#include FL/fl_utf8.h
#include FL/Fl_Box.H
#include FL/fl_draw.H
#include FL/Fl_Text_Buffer.H
#include FL/Fl_Text_Display.H
#include FL/Fl_Text_Editor.H
#include assert.h
#include stdio.h
#include wchar.h
Fl_Double_Window* mainWindow = 0;
Fl_Group* controlGroup = 0;
Fl_Int_Input* unicodeInput = 0;
Fl_Output* encodedOutput = 0;
Fl_Group* encodedGroup = 0;
Fl_Box* encodedBitBox[32]; /* program only handles up to 4-byte encoding */
Fl_Output* wcwidthOutput = 0;
Fl_Output* mkwidthOutput = 0;
Fl_Output* flwidthOutput = 0;
Fl_Output* pxwidthOutput = 0;
Fl_Group* displayGroup = 0;
Fl_Text_Display* lastGlyphTD = 0;
Fl_Text_Display* wrapMode15TD = 0;
Fl_Text_Display* wrapMode10TD = 0;
Fl_Text_Buffer* lastGlyphTB = 0;
Fl_Text_Buffer* wrapMode15TB = 0;
Fl_Text_Buffer* wrapMode10TB = 0;
/* provide explicit explanation of Unicode to UTF-8 encodings for clarity,
* and also as an easy way of colour coding the bits from each UCS byte.
* Note that FLTK only handles U+0 to U+10 to be RFC 3629 compliant,
* [partially anyway, because it doesn't handle known illegal characters]
* so the 5- and 6-byte encodings are only included for completeness.
*/
const char* unicodeToUtf8bytes[7] = {
U+ - U+007F : , /* dummy entry for offset calculations
*/
U+ - U+007F : 0aaa,
U+0080 - U+07FF : 110bbbaa 10aa,
U+0800 - U+ : 1110 10aa 10aa,
U+0001 - U+001F : 0ccc 10cc 10aa 10aa,
U+0020 - U+03FF : 10dd 10cc 10cc 10aa 10aa,
U+0400 - U+7FFF : 110d 10dd 10cc 10cc 10aa
10aa
};
void setBitBoxColour(int utf8len, int byte, int bit) {
assert(1 = utf8len utf8len = 6);
assert(0 = byte byte 6);
assert(0 = bit bit 8);
int b = 8*byte + bit;
/* this demo designed to show 4-byte UTF-8, before U+10 limit found */
if (b = 32)
return;
/* calculate offset into string by using dummy zero entry as template */
int offset = strlen(unicodeToUtf8bytes[0]);
/* calculate index into byte groups - use 9 to allow for spaces */
int i = offset + 9*byte + bit;
char c = unicodeToUtf8bytes[utf8len][i];
Fl_Box* box = encodedBitBox[b];
switch(c) {
case '0': box-labelcolor(FL_BLACK);break;
case '1': box-labelcolor(FL_BLACK);break;
case 'a': box-labelcolor(FL_BLUE); break;
case 'b': box-labelcolor(FL_DARK_GREEN); break;
case 'c': box-labelcolor(FL_CYAN); break;
case 'd': box-labelcolor(FL_DARK_BLUE);break;
default: box-labelcolor(FL_RED); break;
}
}
void setEncodeOutput(unsigned int ucs, const char* utf8, int utf8len) {
char output[32], buffer[32]; /* big enough for 6 * 5 chars for \0xFF */
output[0] = buffer[0] = '\0';
for (int i = 0; i utf8len; i++) {
char c = utf8[i];
if (' ' c c '~') {
sprintf(buffer, %c, c);
strcat(output, buffer);
} else {
sprintf(buffer, \\0x%02hhX, c);
strcat(output, buffer);
}
}
encodedOutput-value(output);
}
void clearBitBoxes() {
for (int i = 0; i 32; i++)
encodedBitBox[i]-label();
}
void clearFields() {
encodedOutput-value();
clearBitBoxes();
wcwidthOutput-value();
mkwidthOutput-value();
flwidthOutput-value();
pxwidthOutput-value();
}
void setBitBoxText(unsigned int ucs, const char* utf8, int utf8len) {
clearBitBoxes();
/* this demo designed to show 4-byte UTF-8, before U+10 limit found */
if (1 utf8len || utf8len 4)
return;
for (int i = 0; i utf8len; i++) {
char c = utf8[i];
for (int j = 0; j 8; j++) {
int b = 8*i + j;
int v = (c 0xFF) (0x01 (8-1-j));
setBitBoxColour(utf8len, i, j);
encodedBitBox[b]-label((v == 0) ? 0 : 1);
}
}
}
void setWidths(unsigned int ucs, const char* utf8, int utf8len) {
int width;
char buffer[32];
width = wcwidth((wchar_t)ucs);
sprintf(buffer, %d, width);
wcwidthOutput-value(buffer);
width = fl_wcwidth_(ucs);
sprintf(buffer, %d, width);
mkwidthOutput-value(buffer);
width = fl_wcwidth(utf8);
sprintf(buffer, %d, width);
flwidthOutput-value(buffer);
double pixels = fl_width(utf8);
sprintf(buffer, %.2f, pixels);
pxwidthOutput-value(buffer);
}
void toDisplays(unsigned int ucs, const char* utf8, int utf8len) {
lastGlyphTB-text(utf8);
wrapMode15TD-insert(utf8);
wrapMode10TD-insert(utf8);
}
void unicodeCallback(Fl_Widget* w, void* userData) {
assert(w == unicodeInput);
clearFields();
unsigned int ucs = 0;
if (sscanf(unicodeInput-value(), %x, ucs) == 1) {
if (ucs 0x10U)
Re: [fltk.bugs] [LOW] STR #2349: U+10FFFF - to decode or not to decode?
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2349 Version: 1.3-current Fix Version: 1.3-current (r7609) Fixed in Subversion repository. Link: http://www.fltk.org/str.php?L2349 Version: 1.3-current Fix Version: 1.3-current (r7609) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2367: Hello World, with extra Console window
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2367 Version: 1.1.10 I'm not a Windows user, but I don't think this is an FLTK bug. Check out the 'Operating System Issues' chapter of the FLTK Programming Manual as http://www.fltk.org/doc-1.3/index.html and go to the section 'How to Not Get a MSDOS Console Window'. I think that this will help you to resolve your problem. Link: http://www.fltk.org/str.php?L2367 Version: 1.1.10 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2348: test/editor fails to display misc/cp1252.txt and can hang
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2348 Version: 1.3-current They should all be listed and documented already in unicode.dox. However, unless you are already experienced with Unicode, wide chars and UTF-* in general, the descriptions are pretty confusing. Plus the fact that there's some FLTK-1.2 and FLTK-2 overlap in functions which makes it difficult for a newcomer to know which are the preferred ones and which are the deprecated ones. Link: http://www.fltk.org/str.php?L2348 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2348: test/editor fails to display misc/cp1252.txt and can hang
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2348 Version: 1.3-current I've created an fl_drg8len(const char* src) function which uses fl_utf8decode() internally so it handles CP1252 0x80-0x9f characters. I've replaced some of the calls to fl_utf8len() with this, and tidied up the character_width() and expand_character() functions. The editor demo no longer hangs, but there is still more to do. See the attached patch. Link: http://www.fltk.org/str.php?L2348 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2348: test/editor fails to display misc/cp1252.txt and can hang
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2348
Version: 1.3-current
The problem, as discussed in the Unicode character display page
thread on fltk.development, is that Fl_Text_{Buffer,Display,Editor}
all use ad hoc testing of bytes against 0x80 and 0x40 masks to
determine whether to call fl_utf8len(char c) to give the number of
bytes in the current utf-8 character sequence. But fl_utf8len(char c)
does not have enough context to know whether bytes 0x80-0x9f are
utf-8 continuation bytes or single byte characters from CP1252 that
should be mapped. fl_utf8len() returns -1 for utf-8 continuation bytes,
which means that instead of stepping forward through the byte array,
Fl_Text_Display::expand_character() takes a step back and gets stuck
in an endless loop, processing the same characters over and over.
The solution appears to be to switch over to use fl_utf8fwd() and
fl_utf8back() to step forward and backward through the byte array.
These consider adjacent bytes to provide the full context, and call
fl_utf8decode() to determine the number of bytes in a character.
fl_utf8decode() also knows how to map CP1252 0x80-0x9f characters to
equivalent UCS values and hence utf-8 sequences. See utf8_fwbk_test.cxx
fl_utf8len() should be not be used for stepping through byte arrays.
Link: http://www.fltk.org/str.php?L2348
Version: 1.3-current
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2348: test/editor fails to display misc/cp1252.txt and can hang
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2348
Version: 1.3-current
Link: http://www.fltk.org/str.php?L2348
Version: 1.3-current#include FL/Fl.H
#include FL/fl_utf8.h
char example1[] = {'a','b','c','\xc2','\x99','\x80','x','y','z', '\0'};
char example2[] = {'a','b','c','\x80','\x80','\x80','\x80','y','z', '\0'};
void output(const char* s, const char* p) {
for (int i = 0; i = strlen(s); i++) {
char c = s[i];
if (p == s+i) printf(|);
if (c != '\0') printf(\\x%02hhx,, c);
}
printf(\n);
}
int main(int argc, char* argv[]) {
const char* start = example1;
const char* end = example1 + strlen(example1);
const char* p = 0;
printf(Test 1: fl_utf8fwd() loop : aaa12Xaaa\n);
p = start;
while (p end) {
output(start, p);
p++;
p = fl_utf8fwd(p, start, end);
}
printf(Test 2: fl_utf8back() loop : aaa12Xaaa\n);
p = end;
while (p start) {
output(start, p);
p--;
p = fl_utf8back(p, start, end);
}
start = example2;
end = example2 + strlen(example2);
printf(Test 3: fl_utf8fwd() loop : aaaaa\n);
p = start;
while (p end) {
output(start, p);
p++;
p = fl_utf8fwd(p, start, end);
}
printf(Test 2: fl_utf8back() loop : aaaaa\n);
p = end;
while (p start) {
output(start, p);
p--;
p = fl_utf8back(p, start, end);
}
return 0;
}
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2349: U+10FFFF - to decode or not to decode?
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2349 Version: 1.3-current I assumed that the error is just down to the symmetry of the code, and just follows on from all of the other if (ucs value) checks. I plan to correct this, and update the unicode.dox page. But later. Link: http://www.fltk.org/str.php?L2349 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #2349: U+10FFFF - to decode or not to decode?
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2349 Version: 1.3-current Comments in src/fl_utf.c for fl_utf8encode() and fl_utf8decode() indicate that they only work for Unicode characters in the range U+0 - U+10 inclusive, because is what RFC 3629 defines in order to handle all UTF16 characters. However, there are lots of places in the code where there are tests for ucs 0x10U rather than ucs = 0x10U, so FLTK does not in fact handle U+10. Clearly nobody has tried to use it yet. Link: http://www.fltk.org/str.php?L2349 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2348: test/editor fails to display misc/cp1252.txt and can hang
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2348 Version: 1.3-current Link: http://www.fltk.org/str.php?L2348 Version: 1.3-currentattachment: cp1252-error.png___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2158: In Fl_Text_Display, word wrapping do not work when mixing with unicode ata .
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current As far as I remember from the code, the Unicode U+00A4 Currency Sign should not require any special handling. As far as the CJK wrapping is concerned, there are 3 reasons I can see: 1. the wcwidth() inplementation has rules for certain characters, such as Hangul Jamo medial vowels and final consonants (U+1160-U+11FF) and returns 0 for the column width instead of 2. For more details. see: http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c 2. the Fl_Text_* line-breaking algorithm is too simple, and looks only at latin space characters as a line-break, and hence wrapping point. Are you expecting the lines to wrap at a particular point based on your knowledge of CJK? Unfortunately, the FL_Text_* line breaking and wrapping is based on a limited number of ascii whitespace characters. FLTK does not handle text formatting and layout for non-ascii characters, and it is unlikely to be added in the near future. 3. It is a bug. One final observation: until now I have only looked at Fl_Text_Buffer and Fl_Text_Display. If you are running in Fl_Text_Editor, it may be that there are extra things to take into account that I have not yet looked at. Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2317: modify cmake files for cross-compile
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2317 Version: 1.3-current Fix Version: 1.3-current (r7452) I'm no CMake expert, but saw the following go by in a recent patch: +# On unix create backward compatibility symlinks +if(NOT EXISTS @PREFIX_INCLUDE@/Fl) + EXECUTE_PROCESS(COMMAND ln -s FL Fl + WORKING_DIRECTORY @PREFIX_INCLUDE@ + ) +endif(NOT EXISTS @PREFIX_INCLUDE@/Fl) My question relates to all places where links could be created, not just this specific example. What happens if a link name already exists, but is not a link to the desired target? Eg. the user has made a brute-force copy of a target to the directory, or there is some debris from a previous build where the link pointed to a different target. Is there, or should there be, some sanity checking that stops and warns the user to clean up before continuing? D. Link: http://www.fltk.org/str.php?L2317 Version: 1.3-current Fix Version: 1.3-current (r7452) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2158: In Fl_Text_Display, word wrapping do not work when mixing with unicode ata .
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current In the Unicode character display page thread on fltk.development http://www.fltk.org/newsgroups.php?gfltk.development+v:10221 Albrecht points out that Fl_Text_Editor still has problems on Windows. Are you also running on Windows? [It's not written in this STR] Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2158: In Fl_Text_Display, word wrapping do not work when mixing with unicode ata .
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current I don't have the fonts installed to display wrap_mode10_cjk_v2.cxx properly, but I viewed characters U+6653 and above using the site: http://www.decodeunicode.org/en/u+6653/properties It doesn't report any obvious differences in character properties, so they should all be handled in the same way. But if I compile and run your example, I see [] for the characters, and there are a couple of line-breaks that remain in force, even as the window is enlarged or shrunk. More investigation required... Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2158: In Fl_Text_Display, word wrapping do not work when mixing with unicode ata .
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2158
Version: 1.3-current
The small test program below [runs on Linux, don't know about Win/Mac]
gives the results that I expected, namely the system wcwidth() returns
-1 because I don't have a CJK-aware locale, and both the fl_wcwidth_()
and fl_wcwidth() return 2. So it looks like there's another display bug
triggered by wrap_mode(1,0) for at least some CJK characters.
pre
#include stdio.h
#include wchar.h
#include FL/Fl.H
#include FL/fl_utf8.h
int main(int argc, char* argv[]) {
char utf8[10];
for (unsigned int ucs = 0x6653; ucs 0x66a3; ucs++) {
int len = fl_utf8encode(ucs, utf8);
printf(ucs: \\x%x, ucs);
printf( );
printf(utf-8: );
for (int i = 0; i len; i++)
printf(\\x%hhx, utf8[i]);
printf( );
printf(wcwidth: %2d, wcwidth((wchar_t)ucs));
printf( );
printf(mkwidth: %2d, fl_wcwidth_(ucs));
printf( );
printf(flwidth: %2d, fl_wcwidth(utf8));
printf( );
printf(\n);
}
return 0;
}
/pre
Link: http://www.fltk.org/str.php?L2158
Version: 1.3-current
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2158: In Fl_Text_Display, word wrapping do not work when mixing with unicode ata .
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current I've just committed revision 7551 which adds the call to fl_wcwidth() to the Fl_Text_Buffer::character_width() routine. I believe that all changes are in place to address the three issues: - incorrect count of multi-byte UTF-8 characters, affecting margins; - incorrect column widths for CJK characters - incorrect wrap_mode(1,0) handling of UTF-8 pixel wrapping Could you please verify that r7551 solves your issues, and confirm? Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2158: In Fl_Text_Display, word wrapping do not work when mixing with unicode ata .
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current wrap_mode(1,N) N0 works well just as before except for ¤. Is that one specific character? or a series of characters that display like that. Can you give the(ir) UCS value(s)? Are these non-spacing, compose or combining characters? Or just single CJK characters? Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2158: In Fl_Text_Display, word wrapping do not work when mixing with unicode ata .
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current Although progress has been made in identifying the causes of the first two issues raised (number and width of UTF-8 glyphs when wrapping), the FL_Text_Buffer and FL_Text_Display code is currently being refactored to remove some old code, and to verify that the UTF-8 code is consistent and correct. These issues will be considered during the refactoring. For the wrap_mode(1,0) problem, see http://www.fltk.org/str.php?L2343 D. Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2343: XIM broken for wrap_mode(1,N)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2343 Version: 1.3-current See also http://www.fltk.org/str.php?L2158 Link: http://www.fltk.org/str.php?L2343 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2158: In Fl_Text_Display, word wrapping do not work when mixing with unicode ata .
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current Attachment: http://www.fltk.org/strfiles/2158/str2158b.zip ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2158: In Fl_Text_Display, word wrapping do not work when mixing with unicode ata .
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current I've just attached str2158b.zip, which is another hacked exploration, this time based on Matt's partially refactored code in r7479. Unpack in a temporary directory so you don't zap current state. This appears to work for the wrap_text, textdisplay and wrap_mode10 text programs posted earlier, with the proviso that I have no CJK fonts on my box, so can't see the real output. There's still a lot of FIXME markers in the code. I also identified expandTabs() as one area that will never work with UTF-8. Possibly. Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2158: In Fl_Text_Display, word wrapping do not work when mixing with unicode ata .
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2158
Version: 1.3-current
I started to look at the wrap_mode(1,0) problem, and I think it will
entail a lot more changes along the lines of what I did before. I see
from the FLTK2 code that they work through the buffer one byte at a
time, handle that byte, and then adjust the offset if that byte is the
start of a UTF-8 sequence. On the one hand that's cleaner, but on the
other it still doesn't address the column width problem because that
requires knowing which UCS character we are dealing with.
Therefore I either need to provide a whole series of additional routines
that take a char* rather than a char, as I did above, and let each level
extract the full UTF-8 byte sequence as needed, or I check for the UTF-8
sequence at the top level and then pass the UCS value rather than char
to a series of new routines. Still haven't made up my mind on this one.
On a related note, let's go back to wcwidth() and mk_wcwidth().
The Linux man page for wcwidth() says that it returns 0 for U+,
the number of columns needed for printable wide characters, and -1
for non-printable characters. The behaviour also depends on LC_CTYPE.
Markus Kuhn's implementation returns 0 for U+, only standard(?)
control characters and DEL return -1, and all other return 0, 1, 2.
There is no reference to locale specifics like LC_CTYPE in the code.
If I build Markus Kuhn's implementation into FLTK-1.3.x xutf8 code
and run the following:
#include wchar.h
#include FL/Fl.H
#include FL/fl_utf8.h
int main(int argc, char *argv[]) {
for (wchar_t ucs = 0; ucs 0x; ucs++) {
int w1 = wcwidth(ucs);
int w2 = mk_wcwidth(ucs);
if (w1 != w2)
printf(U+%04x: wcwidth()=%2d, mk_wcwidth()=%2d\n, ucs, w1, w2);
}
return 0;
}
I can see that there are a lot of characters that return -1 for the
standard wcwidth(), but do return 0, 1, and 2 for mk_wcwidth(). I don't
know whether the first is due to the limited number of locales that I
have installed on this box or not.
Although I have the feeling that providing a platform and locale(?)
neutral implementation has its advantages, I wonder whether it might
cause problems where wcwidth() is already being used elsewhere in the
system. For example, where a system editor and the FLTK app show two
different views of the same file. Should we be worried?
And finally, as far as I can see, there's no reason why we can't just
add Markus Kuhn's wcwidth.c to the xutf8 directory provided we keep
the copyright etc. I don't think there's even a need to edit the file.
Therefore, I have it all ready to be committed in the next few days.
Any comments?
Link: http://www.fltk.org/str.php?L2158
Version: 1.3-current
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2158: In Fl_Text_Display, word wrapping do not work when mixing with unicode ata .
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current can you tell me what you think that wrap_mode(1,0) does, or should do? the comment above the routine is not clear, nor in step with the code, so it could be that what you want it to do is not what it really does. Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2317: modify cmake files for cross-compile
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2317 Version: 1.3-current They look pretty comprehensive as far as I can see. Well done! Link: http://www.fltk.org/str.php?L2317 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2158: In Fl_Text_Display, word wrapping do not work when mixing with unicode ata .
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2158
Version: 1.3-current
Link: http://www.fltk.org/str.php?L2158
Version: 1.3-current#include FL/Fl.H
#include FL/Fl_Double_Window.H
#include FL/Fl_Text_Display.H
#include FL/Fl_Value_Slider.H
#include FL/Fl_Light_Button.H
#include stdio.h
#include stdlib.h
#include string.h
Fl_Double_Window* mainWindow = 0;
Fl_Text_Display* courierTD = 0;
Fl_Text_Buffer* courierTB = 0;
Fl_Text_Display* helveticaTD = 0;
Fl_Text_Buffer* helveticaTB = 0;
void addToBuffer(char* buffer)
{
char utf8[10];// more than big enough
for (unsigned int ucs = 33; ucs 73; ucs++) {
int len = fl_utf8encode(ucs, utf8);
strncat(buffer, utf8, len);
}
strcat(buffer, \n);
for (unsigned int ucs = 161; ucs 201; ucs++) {
int len = fl_utf8encode(ucs, utf8);
strncat(buffer, utf8, len);
}
strcat(buffer, \n);
}
int main(int argc, char* argv[])
{
mainWindow = new Fl_Double_Window(300, 300, wrap_mode(1, 0) test);
courierTD = new Fl_Text_Display(10, 10, 280, 120, 0);
courierTB = new Fl_Text_Buffer();
courierTD-buffer(courierTB);
courierTD-wrap_mode(1, 0);
courierTD-textfont(FL_COURIER);
char* courier = (char*)malloc(1024 * sizeof(char));
strcpy(courier, FL_COURIER:\n);
addToBuffer(courier);
courierTD-insert(courier);
helveticaTD = new Fl_Text_Display(10, 140, 280, 120, 0);
helveticaTB = new Fl_Text_Buffer();
helveticaTD-buffer(helveticaTB);
helveticaTD-wrap_mode(1, 0);
helveticaTD-textfont(FL_HELVETICA);
char* helvetica = (char*)malloc(1024 * sizeof(char));
strcpy(helvetica, FL_HELVETICA:\n);
addToBuffer(helvetica);
helveticaTD-insert(helvetica);
mainWindow-resizable(mainWindow);
mainWindow-show(argc, argv);
return Fl::run();
}
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2158: In Fl_Text_Display, word wrapping do not work when mixing with unicode ata .
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current Added wrap_mode10.cxx so that the problem is easily reproducible, and wrap_mode10.png showing result. Standard ascii chars wrap, but UTF-8 encoded chars do not. I hope you see the same effect as you resize the window. I shall start looking at this tomorrow... Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2317: modify cmake files for cross-compile
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2317 Version: 1.3-current I poked around with CMake back in 2008 and wrote the following: Article #834: Using CMake to build an FLTK application http://www.fltk.org/articles.php?L834+I0+Q which also contains a link to a more complete article on the CMake site. Does this help? I was not, and am not, a CMake aficionado. I was just experimenting. What I did may be useful, but it may also be a complete load of rubbish. I can update this article if someone has any comments, but it might make more sense for someone who really knows what s/he is doing to write a new howto article from scratch... Link: http://www.fltk.org/str.php?L2317 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2158: In Fl_Text_Display, word wrapping do not work when mixing with unicode ata .
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2158
Version: 1.3-current
Link: http://www.fltk.org/str.php?L2158
Version: 1.3-current#include FL/Fl.H
#include FL/Fl_Double_Window.H
#include FL/Fl_Text_Display.H
#include FL/Fl_Value_Slider.H
#include FL/Fl_Light_Button.H
#include stdio.h
#include stdlib.h
#include string.h
Fl_Double_Window* mainWindow = 0;
Fl_Text_Display* textDisplay = 0;
Fl_Text_Buffer* textBuffer = 0;
Fl_Value_Slider* valueSlider = 0;
Fl_Light_Button* helveticaButton = 0;
Fl_Light_Button* courierButton = 0;
void addToBuffer(char* buffer, const char* title, char* text)
{
strcat(buffer, title);
strcat(buffer, \n);
for (int i = 0; i 10; i++)
strcat(buffer, text);
strcat(buffer, \n);
strcat(buffer, \n);
}
void sliderCallback(Fl_Widget* w, void* data)
{
Fl_Value_Slider* slider = (Fl_Value_Slider*)w;
textDisplay-wrap_mode(1, (int)slider-value());
}
void buttonCallback(Fl_Widget* w, void* data)
{
Fl_Light_Button* button = (Fl_Light_Button*)w;
if (button == helveticaButton) {
helveticaButton-set();
courierButton-clear();
textDisplay-textfont(FL_HELVETICA);
} else {
helveticaButton-clear();
courierButton-set();
textDisplay-textfont(FL_COURIER);
}
textDisplay-redraw();
}
char ascii[]= $ ; // dollar
char utfOneByte[] = \x24 ; // U+0024 (dollar)
char utfTwoByte[] = \xc2\xa9 ; // U+00A9 (copyright sign)
char utfThreeByte[] = \xe2\x82\xac ; // U+20AC (euro currency sign)
int main(int argc, char* argv[])
{
printf(sizeof(unsigned int) = %d\n, sizeof(unsigned int));
printf(strlen(%s) = %d\n, ascii, strlen(ascii));
printf(strlen(%s) = %d\n, utfOneByte, strlen(utfOneByte));
printf(strlen(%s) = %d\n, utfTwoByte, strlen(utfTwoByte));
printf(strlen(%s) = %d\n, utfThreeByte, strlen(utfThreeByte));
mainWindow = new Fl_Double_Window(500, 300, Wrap Text);
textDisplay = new Fl_Text_Display(10,10,480,190, 0);
textBuffer = new Fl_Text_Buffer;
textDisplay-buffer(textBuffer);
textDisplay-wrap_mode(1, 120);
textDisplay-textfont(FL_HELVETICA);
valueSlider = new Fl_Value_Slider(20, 220, 460, 20, Wrap position);
valueSlider-type(FL_HORIZONTAL);
valueSlider-minimum( 50.0);
valueSlider-maximum(150.0);
valueSlider-value(120.0);
valueSlider-step(1.0);
valueSlider-callback(sliderCallback, 0);
helveticaButton = new Fl_Light_Button(20, 260, 100, 20, Helvetica);
helveticaButton-set();
helveticaButton-callback(buttonCallback, 0);
courierButton = new Fl_Light_Button(380, 260, 100, 20, Courier);
courierButton-clear();
courierButton-callback(buttonCallback, 0);
char* buffer = (char*)malloc(1000 * sizeof(char));
strcpy(buffer, );
addToBuffer(buffer, ascii:, ascii);
addToBuffer(buffer, utf8 one byte:, utfOneByte);
addToBuffer(buffer, utf8 two byte:, utfTwoByte);
addToBuffer(buffer, utf8 three byte:, utfThreeByte);
textDisplay-insert(buffer);
mainWindow-show(argc, argv);
return Fl::run();
}
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2158: In Fl_Text_Display, word wrapping do not work when mixing with unicode ata .
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current If you poke around on the NEdit web pages, there's the comment somewhere, and I paraphrase here, that proportional fonts are not handled well because nedit is really a programmers' editor, designed for use with source code, with fixed width fonts and columns of characters. I think, therefore, that we might be trying to shoe-horn something into this code that is never going to fit properly. The code is not exactly clear and easily maintainable now, never mind adding special case code. But then, as the latest release of NEdit was 5.5 in 2004, so it looks unlikely that there will be new releases. So we don't need to remain compatible. Unless we provide a completely new widget, written from the ground up, we should probably be looking at making some clear statements in the documentation (for wrap_mode() perhaps?) that explain that: - wrapping is based on glyph pixel width only (no columns) - wrapping is based on 1 column per character for fixed width LGC fonts - wrapping is based on 2 column per character for fixed width CJK fonts - mixing the last two may produce unexpected results. Maybe we could extend wrap_mode() to have an additional parameter that specifies the number of columns per character, with 0 for mixed fonts. Just thinking aloud... Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2158: In Fl_Text_Display, word wrapping do not work when mixing with unicode ata .
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current OK, been looking at this a bit further... If we add Markus Kuhn's wcwidth.c into src/xutf8 for testing, we still need to have a wrapper function that takes a char* pointing to the start of the UTF-8 sequence, converts it to UCS, and then calls mk_wcwidth(). Plus, we will need to rejig FL_Text_Buffer because at the moment we have int Fl_Text_Buffer::expand_character(char c, ...) and int Fl_Text_Buffer::character_width(char c, ...) If we overload these to have versions that take a char* we might be able to do it, but more investigation required. Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2158: In Fl_Text_Display, word wrapping do not work when mixing with unicode ata .
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current Sorry guys, bit of brain-fade there earlier. I only needed the extra character_width() implementation, not the expand_character(). That gives me two rows of 10 'a' and 4 rows of 5 '[]' because I don't have the correct chinese locale and fonts. It still might not work correctly as part of Fl_Text_Editor with the reverse character to column mapping though. I haven't tested it beyond the 'textdisplay.cxx' at the moment, and I will need to tidy up the source before I paste it here for testing in sparkaround's real environment... Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2158: In Fl_Text_Display, word wrapping do not work when mixing with unicode ata .
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current I've just started to look at the code again, and I could be wrong, but it seems that the different code paths for proportional and fixed width fonts has more to do with calculating maximum display width for use with scrollbars. Everywhere else seems to look at wrapping at a given column number, so it could be that your second problem is just a feature of how the code works and not a bug. But there's still a lot of code to check yet... Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2334: Compiling fltk 1.0.11 with mingw (version 1.0.11, not 1.1.10)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2334 Version: 1.1.10 FLTK-1.0.11 was released in October 2001, and after all these years, there won't be a FLTK-1.0.12 bug fix version, especially as you say that this bug was fixed in the FLTK-1.1 series. There have been 10 releases in the FLTK-1.1 series since then, with the final release of FLTK-1.1.10 in December 2009. There will be no more FLTK-1.1.x releases. Is there some reason why you can't convert your code to FLTK-1.1.10? D. Link: http://www.fltk.org/str.php?L2334 Version: 1.1.10 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2158: In Fl_Text_Display, word wrapping do not work when mixing with unicode ata .
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current I proposed a solution on the 6th December, which is a one-line fix, but I don't think that this has been changed in svn. Can you please modify Fl_Text_Buffer::character_width() in your local sources as described above [if looking at the STR view, not fltk.bugs] and confirm whether this solves your problem or not? Cheers D. Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2158: In Fl_Text_Display, word wrapping do not work when mixing with unicode ata .
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current It's 4 months since I looked at the code, and I didn't really understand it properly then because it's all recursive and poorly refactored, but if I remember correctly, there are different paths through the code for constant width fonts and for proportional width fonts. So it looks like my fix catches the problem with calculating the correct number of characters (rather than bytes) for rendering in a fixed width font. Now we need to look at handling the pixel width of the characters when rendered in a proportional font. I'm afraid there won't be a quick fix because: - I don't have any spare time at the moment to look into it; - I don't have the same locale and Chinese(?) fonts as you; - I've forgotten how the code works; - most important of all, this is probably the most obscure and poorly structured code that I've ever worked with... D. Link: http://www.fltk.org/str.php?L2158 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] startin' to get it..
Please don't post directly to fltk.bugs because it is intended for the automated output from the Software Trouble Report system and few humans actually read it. If you have discovered a bug in the fltk software itself, please submit a bug report using the form at http://www.fltk.org/str.php If you are having problems getting fltk to work in your own code, please post to fltk.general, where you have more chance of getting a response. ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] fltk-2.0.x-r6970/images/fl_png.cxx uses deprecated functions
Just to let you know that fltk.bugs is for the automated bug-tracking system and not for direct posting as such. If you want to report this as a bug, open a Software Trouble Report (STR) by using the Submit Bug link at http://www.fltk.org/str.php Having said that, this very issue was raised last week for fltk-1.3.x and has been discussed in fltk.development. See the thread starting at: http://www.fltk.org/newsgroups.php?gfltk.development+v:9301 Cheers D. ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2322: Fluid Menu/Edit/Ungroup F8 isn't showing properly
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2322 Version: 1.3-current Here's what I see with fltk-1.3.x (revision 7145) on CentOS 5.2: pre _UndoCtrl+Z _Redo Shift+Ctrl+Z C_ut Ctrl+X _CopyCtrl+C _Paste Ctrl+V Dup_licate Ctrl+U DeleteDelete Select _All Ctrl+A Select _None Shift+Ctrl+A Properties... F1 _Sort _Earlier F2 _LaterF3 _GroupF7 Un_group F8 Hide O_verlays Shift+Ctrl+O Hide Widget _Bin Alt+B Show Source Code... Alt+Shift+S Project Settings... Alt+P GU_I Settings...Alt+Shift+P /pre Underscores appear before the letter that is underlined on the menu. Link: http://www.fltk.org/str.php?L2322 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2318: problems with non-English keyboard layout
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2318 Version: 2.0-current Link: http://www.fltk.org/str.php?L2318 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2158: In Fl_Text_Display, word wrapping do not work when mixing with unicode ata .
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2158
Version: 1.3-current
I think that I might have isolated the problem in this particular
case, but I'm not sure whether any issues might pop up elsewhere
in Fl_Text_Display and Fl_Text_Buffer handling.
pre
int Fl_Text_Buffer::character_width(char c, int indent, int tabDist, char
nullSubsChar) {
/* Note, this code must parallel that in Fl_Text_Buffer::ExpandCharacter
*/
if (c == '\t')
return tabDist - (indent % tabDist);
else if (((unsigned char) c) = 31)
return strlen(ControlCodeTable[ (unsigned char) c ]) + 2;
else if (c == 127)
return 5;
else if (c == nullSubsChar)
return 5;
else if ((c 0x80) !(c 0x40))
return 0;
else if (c 0x80) {
return fl_utf8len(c);
}
return 1;
}
/pre
I think that the final call to fl_utf8len() is wrong in this case.
A Unicode character represented as a UTF-8 byte sequence consists
of a header byte that indicates how many bytes are in the sequence,
and one or more non-header bytes. fl_utf8len() returns the number
of bytes in the sequence if passed the header byte, and zero for
the non-header bytes.
The code above appears to correctly handle tabs, ASCII control and
nul characters, and the UTF-8 non-header byte. However, instead
of treating the UTF-8 header byte as indicating that the UTF-8 byte
sequence expands to ONE character, it expands it to the number of
bytes in the sequence.
Changing fl_utf8len(c) to 1 in the above solves this problem.
The Fl_Text_Display and FL_Text_Buffer code is hard to understand,
and it may be that there are other areas where similar logic needs
to be investigated.
D.
Link: http://www.fltk.org/str.php?L2158
Version: 1.3-current
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] VC6 to compile the latest weekly fltk-2.0.x-r6879 error!
I use VC6 to compile the latest weekly fltk-2.0.x-r6879,... fltk.bugs is intended for output from the automated STR system. could you please re-send this report to fltk.general, where someone might be able to guide youy further. please include details of which version of fltk you are using, and on which platform. ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] problem in Fl_Output::value(..)
I am seeing a real problem in a quite simple (about 1.5K lines) C++ app. If you re-post your question in fltk.general, you are more likely to find someone who might be able to help you. Fltk.bugs is intended for the output from the automated STR system dealing with bug reports in the fltk code itself, not user code. Good luck D. ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] Fluid (1.1.9) generated code not displaying all tabs
I restarted an old project now using fluid under FLTK-1.1.9, and only my first tabbed group (MAP_GROUP) appears. I use 1.1.7 fluid (I never built FLTK-1.1.8) and all the windows appear normally. Sorry don't have more detail. Not sure if this is a known bug or not. If needed, I can send the fluid file in question (fl_main.fl). Please re-submit this using the form on the Bugs Features page at http://www.fltk.org/str.php rather than post directly here, and also indicate which platform you are using and include the fl_main.fl file. Is the diff you posted the only difference in the generated code? D. ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
