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
This now correctly measures glyphs whose codepoint requires a surrogate pair to represent it in UTF16.
NOTE 1: This code makes any UCS point > 0xFFFF a "special case" and measures it explicitly, rather than using the lookup table. This "explicit measure" may be slow, but actually seems OK in my tests, so far.
The lookup table still covers the basic multilingual plane and is used for any glyph <= 0xFFFF as before, so the behaviour for most existing bodies of text is unchanged.
This code also retains the historical behaviour under Win32 whereby strings are measured char-by-char rather than as a whole string - again this is intended to retain compatability with existing implementations.
It is proposed that we should move towards measuring entire strings in the future as this is conceivably more efficient and certainly more consistent - rendering is now largely done "string as a whole" so we ought to measure in that way too; though to date the differences seem tiny, as evdienced by the text rendering page of the unittest example.
NOTE 2: This does not fix the *rendering* of surrogate pairs under XP, which still seems to be broken. I suspect that TextOutW() may genuinely broken under XP, as it works fine on Vista, and it is not just my code that seems broken, other non-fltk programs exhibit the same aberrant behaviour. Measuring of surrogate pairs appears to work correctly though...
Maybe we are using TextOutW() wrongly?
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8580 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
This makes string handling much more consistent across variants.
Doh!. I am such an idiot...
NOTE: This still does not fix aberrant handling of surrogate pairs under WinXP, and I still haven't resolved the issues with the win32 ::width() functions not handling surrogate pairs at all...
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8575 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
However... It does not cause the "high" Unicode code points to render correctly on XP, even though they do work on Vista (and I assume later variants like Win7...)
So there's still something I am missing here. Maybe XP is just broken? That'll be a problem...
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8570 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
class to prepare for the future definition of graphics drivers that fully deal with text measurement.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8442 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
put before making sure we have a valid gc, which was wrong.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8365 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
with Fl_Widget::type(). Added a setter function Fl_Device::class_name(const char *).
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8190 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
This new algorithm is not coherent with fl_width() but allows minimal usage of fl_rtl_draw().
The utf8 demo shows the effect of this change.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8134 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
(1) adding Fl_Device class (and more) for device abstraction
(2) adding Fl_Pinter class (and more) for printing support.
Todo: Code cleanup, update dependencies, remove/replace test print window.
I'm looking into converting the test window popup in a global shortcut
that would pop up the print dialog now...
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@7263 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
STR#1840 closed, STR#207 not closed because non-xft functions not implemented
drawing of N Utf8 characters need correction for rotated and not rotated fl_draw functions not solved!
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@6779 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
This one was really tough to track, understand:
In fact,
the problem was comming from the misplacement of the menu window,
which itself came from invalid measurement,
which itself came from invalid fl_witdh() measurement,
but only when fl_gc is not valid because fl_width() relies on Win32 on the call
of GetTextExtentPoint32W which can't succeed if the HDC(here fl_gc) is not valid !
Now the fix:
A best-effort algorithm has been furthered to supply a valid fltk hdc if we can have one or a screen hdc if no fltk window is found by fl::first_window().
Note that when fl_gc is NULL inside fl_width() call, it can happen that Fl_Window::current() is not null but invalid (already deleted).
Finally, in the case of the buggy menu window observed here, this fl_gc was set to NULL just after an Fl_Menu_Window deletion and re-creation in Fl_Menu_Item::pulldown().
Also added a comment to describe the new fl_width() behavior.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@6540 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
"The problem is line 237, the "unsigned len" declaration is potentially
crossed by the preceeding goto (line 234) so some compilers don't like
that..."
Tested okay on cygwin with gcc 3.4.4.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@6535 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
- removed all #warning statemnets and explained caveats with regular
// warning lines
- made GL text rendering work again (may use wrong fonts since agl doesn't
really support ATS)
- removed horizontal jittering in Fl_Input_ caused by fractional text
positions. Unfortunatly, this does not work for Fl_Text_Display, which
not only jitters, but also became horendously slow due to the complex
font rendering in Quartz)
I will fix some of the speed issues in fl_measure this afternoon, and
also improve on the 'innards' for rgb data rendering. After that, I will
have to leave the Quartz port alone for a while due to lack of time.
I suggest we make another rc in the next days.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.1@3812 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
The old source file "fl_set_gray.cxx" is not needed (STR #516)
Fl_Text_Display still called delete[] instead of free() in one
place (STR #503)
Fl_File_Chooser didn't correctly call isprint() and isspace()
when checking to see if the current file was text that can be
previewed (STR #517)
FLUID didn't compile with Borland C++ due to a compiler bug (STR
#496)
Fl_Positioner did not handle reversed min and max values (STR
#510)
fl_descent(), fl_height(), and fl_width() would crash a program
if you didn't call fl_font() first; they now return -1 if no
font is set (STR #500)
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.1@3805 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
TODO: Fl::set_fonts() should add all of the fonts returned by Xft;
right now it is a no-op.
BUG: Getting X messages like "XRequest.155: 202 0x260002b" for some
reason on my system.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.1@1987 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
