Re: font dialog error

[email protected] Thu, 04 Sep 2025 12:29:01 -0500
Newsgroups gmane.comp.lib.fox-toolkit.user
Message-ID <[email protected]>
On 2025-09-04 11:00, John Selverian wrote:
> v1.7.50
> 
> It is a custom widget derived form the standard font dialog.

So, some background about the problem:

1) On Linux, we use Xft [XLFD still works, but looks really ugly].  
Fonts
    in Xft can be measured a character at a time, so we can avoid 
overflowing.

    Measuring character at a time was necessary because 
XftTextExtentsUtf8() was
    using a 16-bit short, which overflows too quickly.

2) Due to fixes in FXTextField, we no longer draw invisible text, just 
visible
    text.  Buffer limits or client-server transfer limits less likely to 
be a
    problem.  Of course this should also be faster.

3) On Windows, I've split text measurement and drawing into two 
branches; the fixed-
    buffer version, which lives on the stack, is used for short strings.

    In the rare case we have a large string, we allocate variable size 
buffer and
    use it for the utf8->utf16 conversion, then free it immediately.

    Alloc/free overhead can  be a lot, so we prefer to do it only when 
needed.


Either way, for drawing purposes, strings are transferred between your 
FOX program
and the drawing system [X11 or GDI] and if you have a large string, 
trouble MAY
still ensue.  FOX widgets which may have very long strings [FXText and 
FXTextField]
are now safe against this, since drawing has been limited to the part of 
the text
that's visible, which by definition is much less than the whole screen.
Most other widgets won't have very long strings and should be OK.

I recommend custom widgets that deal with really long strings should be 
looked at
and potentially updated to draw only the visible fragments; this would 
avoid
these problems, and at the same time, significantly speed up drawing.


              -- JVZ