badly formed UTF8 strings.
This probably is not the best solution, but it
does work.
Note that the problem actually seems to be in
setting the window title, and indeed if you try to
label ANY window with a badly formed UTF8 string
(not just a tooltip) you get the same exception
thrown.
NOTE: I'm not even sure why we try to set the
window title in tooltips, as it is never used
and the tooltip label itlsef still works fine.
Anyway, we can do something better, but this will
work for now.
Aside: If you close an app on OSX whilst a tooltip
is visible, the app will not exit, as there is still
a window open (the tooltip) but no way to cancel
the tooltip.
Don't know if this is OSX specific or not though
but it is certainly a bug.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8598 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
I found some kind of weird interaction with some symbol fonts that
covered the supplementary planes that meant we could not measure
the width correctly (although we did measure the text extents correctly.)
This mod mirrors what we do for non-surrogate-pair glyphs more
closely and appears to do the Righ Thing now, at least for the test fonts that I have, and which were exhibiting the aberrant behaviour before.
I don't think I have broken anything else in the meantime!
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8597 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
Added Fl_Window::decorated_w() and Fl_Window::decorated_h() that return the size
of a window with its title bar and frame.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8593 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
In particular, I have added a new function to src/fl_utf.c called fl_ucs_to_Utf16() which
converts a single 32-bit Unicode value into one (or more) UTF16 cells.
This is needed in the win32 char-by-char text width() logic, and I suspect may also be useful in the OSX code in some places.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8585 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
The problem seems to be in GetGlyphIndicesW() which is returning invalid indices for the surrogate pairs.
This causes subsequent measurements of the glyphs to fail, of course.
This patch does not fix the problem, it only makes sure it fails cleanly, causing a fallback to the default fl_measure like behaviour.
This is not nice, nor what I want, but at least it is consistent for now...
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8582 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
made consistent with other platforms, that is, the 4th byte of each pixel is ignored
instead of treated as transparency data.
In the future, the fl_draw_image() signature may be extended with another argument
that would describe if and how transparency information is available.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8581 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
This seems to be good so far, though does not resolve the XP surrogate pairs issues.
If this fix is bad, we need to revert to r8577, which is good...
And I still haven't fixed the handling of width in win32 code, so it is still inconsistent with draw for high Ubicode points.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8579 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
Fixes to the various ::width() methods for win32 and OSX still TBD.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8568 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
This change works, but is incomplete, other sections of the win32 code (and possibly OSX code) are making the same invalid assumptions about UTF16 chars.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8567 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
Also, don't rebuild the application menu if one is already there.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8549 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
Ian MacArthur
Manolo Gouy
Greg Ercolano
Albrecht Schlosser