On 21.04.2010, at 18:32, MacArthur, Ian (SELEX GALILEO, UK) wrote:
>
>>> I just tested this with my Ubuntu/firefox, too. After setting the
>>> default character set to UTF-8, everything in cp1252_utf-8.txt
>>> displays okay, except 0xAD (U+00AD), which is the "soft hyphen".
>>> I'd say that it's ok
> So, the question would be: should we display a soft hyphen or not?
> Currently we do, and mk_wcwidth() is consistent (width=1).
In my explorations of Fl_Text_{Buffer,Display} so far, I haven't been
looking at, or for, "advanced" features such as optional hyphenation.
[It would be interesting to
Duncan Gibson wrote:
>> So, the question would be: should we display a soft hyphen or not?
>> Currently we do, and mk_wcwidth() is consistent (width=1).
>
> In my explorations of Fl_Text_{Buffer,Display} so far, I haven't been
> looking at, or for, "advanced" features such as optional hyphenation.
> I also tried FLTK 2.0 with cp1252_utf-8.txt, and it works
> like a charm. Even
> 0x98 (U+02DC, SMALL TILDE) is displayed and handled correctly
> (WRT cursor
> movement). No line length problems as in FLTK 1.3 - maybe we
> should have a look
> at FLTK 2's implementation?
Well, there's a t
> I also tried FLTK 2.0 with cp1252_utf-8.txt, and it works like a
> charm. Even 0x98 (U+02DC, SMALL TILDE) is displayed and handled
> correctly (WRT cursor movement). No line length problems as in
> FLTK 1.3 - maybe we should have a look at FLTK 2's implementation?
Here at work I'm on a 64-bit C
On Apr 22, 2010, at 1:06 AM, Albrecht Schlosser wrote:
> On 21.04.2010, at 18:32, MacArthur, Ian (SELEX GALILEO, UK) wrote:
>>
I just tested this with my Ubuntu/firefox, too. After setting the
default character set to UTF-8, everything in cp1252_utf-8.txt
displays okay, except 0xAD
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2346
Version: 1.3-feature
fltk 1.3.x-r7513, in Fl_File_Chooser2.cxx, line 729, (in
Fl_File_Chooser::fileListCB), the callback for the file dialog is never
called *after* t
> If I kick off the both test/editor to read misc/cp1252*.txt I get:
>
> 1.3: cp1252.txt:
> missing columns 128 onward, ie no 8-bit chars,
> and missing the right wall of the table too
> [I've switched workspaces and it has hung too]
Just repeated this at home on a 32-bit Lunar Lin
On 22 Apr 2010, at 18:55, Duncan Gibson wrote:
>
>> If I kick off the both test/editor to read misc/cp1252*.txt I get:
>>
>> 1.3: cp1252.txt:
>> missing columns 128 onward, ie no 8-bit chars,
>> and missing the right wall of the table too
>> [I've switched workspaces and it has hun
