| Age | Commit message (Collapse) | Author |
|
pairs whilst we were looking at STR #2622.
In summary, if you measured the string *before* the selected font had been used to actually fl_draw() anything, the measurement returned was invalid, as the new font was not "locked in" to the gc.
This change makes sure the selected font is set in the gc before making the measurement.
In tests, this appears to work correctly now...
More opinions welcomed!
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8644 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
This might not be correct (though I think it is) but should be no worse than the current mess I made...
Please test with as many different win32/64 compilers as possible and let me know!
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8643 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8642 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
selected
by the keyboard.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8641 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
Fl_Text_Buffer::tab_distance(int).
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8640 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
as authorized by the doc.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8639 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
Docs clarified.
Also, tree-simple example's callback handler brought up to date.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8632 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
that allowed to set the focus to an Fl_Window.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8631 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
FL_ROUND_DOWN_BOX) on Linux (STR #2615). This was done by
(a) setting the line width in the box drawing function (was undefined, maybe 0)
(b) taking care of zero and negative line width in X11 clipping functions.
Both solutions would have solved the particular problem individually.
Additionally made local helper function fl_arc_i() in src/fl_round_box.cxx
static to avoid name clashes.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8630 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8628 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8626 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8625 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8624 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
which events invisible and inactive widgets can get.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8623 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8621 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8620 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8619 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
The new code makes the STR #2598 changes unix-specific so it does not
interact with the WIN32 platform.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8618 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8616 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8612 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8611 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8608 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8607 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
Fl_Paged_Device::print_window() where the window didn't redraw well in some
cases after printing.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8606 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
The win32 text-extents stuff now seems to be handling surrogate pairs correctly,
at least in my testing harness, and with a variety of supplementary plane fonts.
I really will leave this alone now - unless anyone finds bugs of course!
I have tested for regressions and it seems to be fine AFAICT.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8605 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
menu title.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8604 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8603 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
if (winclass != kHelpWindowClass)
is now replaced in Fl_cocoa.mm by its exact equivalent:
if ( w->border() || (!w->modal() && !w->tooltip_window()) )
so that tooltip windows are handled as in carbon.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8601 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
workaround for text_extents being measured on glyphs from
supplementary Unicode planes.
It has no effect on glyphs from the Basic plane, so should not
be visible at all to most code.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8600 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
window opened.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8599 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
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
|
|
text.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8596 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8595 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8594 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
and frame.
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
|
|
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8592 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8591 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8590 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8589 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8586 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
|
|
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8584 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8583 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
on XP.
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
|
|
is here
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 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
|
|
"char by char" rendering, as advised by Bill and Manolo.
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
|
|
consistent in coding terms. Behaviour of output unchanged.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8578 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|
|
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8577 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
|