nanogui: Thread: Re: FLTK font question

: I do not get this font.alias file to work with fltk. This is my font.alias
: in the dejavu directory:
:
: !fixed "-misc-dejavu sans-medium-r-normal--0-0-0-0-p-0-ascii-0"
: fixed DejaVuSans.ttf
: System DejaVuSans.ttf
: system DejaVuSans.ttf
: helvetica DejaVuSans.ttf
: courier DejaVuSans.ttf
: times DejaVuSans.ttf

This should all work now.


: But it does not work for fltk as you can see below. I also do not know how
: to put the pattern -*-helvetica-medium-r-normal--* into the alias file. 
Does
: NXlib also support quotation marks in font.alias files? These should be 
used
: if there is a blank in the file description.

We still don't support quote marks in alias files, but the filenames
can now include spaces.

Regards,

Greg

Hi Greg,

thank you very much! The fonts.alias file works now with the helvetica 
request from FLTK and with the fixed pattern as well. Also it accepts spaces 
in the XLFD string.

Do you know why I have problems to get the characters above 127 to be 
displayed correctly? It does not show U-Umlaut, A-Umlaut etc. Also the fonts 
example of FLTK shows question marks for these characters.

Regards

Georg 

: Do you know why I have problems to get the characters above 127 to be
: displayed correctly? It does not show U-Umlaut, A-Umlaut etc. Also the 
fonts
: example of FLTK shows question marks for these characters.

What does it show for these characters?

You've got a list of all sorts of things that don't work, huh? LOL ;)

I don't know FLTK very well and there are several versions out
there, some using UTF-8 encoding, others not.  I suggest you
modify a demo microwindows program first, using the GrText()
routine and a scaleable unicode font.  Then, the GR_TFUTF8
or GR_TFUC16 flags can be used in the last parameter
to specify the text encoding.  This will then be translated
internally to the font's unicode index and displayed.  If
the loaded font isn't unicode or doesn't have the translated
character index, then of course, it won't work.  A
special character, usually a box, will be displayed instead.

You will need to look into NXLIB XDrawString16 as
well as the calls made in FLTK to XDrawString* to determine
how they're encoding text for output.  Looking at NXLIB,
it uses the X11 character encoding, rather than UTF8 or UC16,
for XDrawString16.

Regards,

Greg 

Hi Greg,

I only have a short list of things that do not work. ;-)

I followed your suggestions and found that both nano-x and NXlib do print 
Umlauts to the screen. What I had to do was to implement an IBM code page 
850 to iso8859-1translation table in my keyboard driver. Then the Umlaut 
keys were displayed.

Then I found that FLTK 1.1.10 does display the fonts with Umlauts while FLTK 
1.3.0 does not. The reason is apparently that FLTK 1.1.10 loads an iso8895-1 
font while FLTK 1.3.0 loads an iso10646-1 font. FLTK 1.3.0 is using UTF-8 
now.

I think I have to make a change to this function in nxlib\text.c:

int XDrawString(Display *dpy, Drawable d, GC gc, int x, int y,_Xconst char 
*string, int length)
{  if (length > 0)
GrText(d, gc->gid, x, y, (char *)string, length, GR_TFASCII|GR_TFBASELINE);
return 0; }

How would you recommend to set the GrText flags here? Or what could I do?

Georg 

: I followed your suggestions and found that both nano-x and NXlib do print
: Umlauts to the screen. What I had to do was to implement an IBM code page
: 850 to iso8859-1translation table in my keyboard driver. Then the Umlaut
: keys were displayed.

Good.  Please send me your keyboard driver when finished, I've
added the initial DJGPP version already.



: Then I found that FLTK 1.1.10 does display the fonts with Umlauts while 
FLTK
: 1.3.0 does not. The reason is apparently that FLTK 1.1.10 loads an 
iso8895-1
: font while FLTK 1.3.0 loads an iso10646-1 font. FLTK 1.3.0 is using UTF-8
: now.

Well now you know how all the font stuff is loaded, the first issue
is determining exactly which font is loaded (differently?) between
the two FLTK versions.  As you'll recall, the font list is specified
in X11 XLFD format in fltk/src/fl_font_x.cxx.  Check that these font
tables are in fact the same or not, and then use the debug output
from the XLoadFont/XListFonts in NXLIB to determine whether
either is aliased and then exactly which font is loaded.

Once you know which font is loaded, then you'll know how it's
encoded.  If FLTK 1.3.0 is using UTF-8, then you'll have to
have a Unicode font loaded and pass GR_TFUTF8 instead
of GR_TFASCII below for it to display properly.  Otherwise,
you'll have to re-encode or convert the text string before calling
GrText.  (Yes, we could add another decoding method to
microwindow's engine/devfont.c::GdConvertEncoding(), which
may be another way to solve the problem).

Finally, you'll want to compare the differences between FLTK
versions and see whether XDrawString16 is called, instead of
or in addition to XDrawString.  The X11 spec says that only
ASCII is supposed to be passed to XDrawString.  There are
also some UTF-8 additions to X11 that may be in use, you
will have to check the FLTK 1.3.0 source for that.

Regards,

Greg



:
: I think I have to make a change to this function in nxlib\text.c:
:
: int XDrawString(Display *dpy, Drawable d, GC gc, int x, int y,_Xconst char
: *string, int length)
: {  if (length > 0)
: GrText(d, gc->gid, x, y, (char *)string, length, 
GR_TFASCII|GR_TFBASELINE);
: return 0; }
:
: How would you recommend to set the GrText flags here? Or what could I do?
:
: Georg
:
: 

: Then I found that FLTK 1.1.10 does display the fonts with Umlauts while 
FLTK
: 1.3.0 does not. The reason is apparently that FLTK 1.1.10 loads an 
iso8895-1
: font while FLTK 1.3.0 loads an iso10646-1 font. FLTK 1.3.0 is using UTF-8
: now.

In looking at this a little deeper, I can see that FLTK 1.1.11 uses 
XDrawString,
while FLTK 1.3.0 uses a combination of either 
fl_font_x.cxx::XUtf8DrawString(),
or is configurable to use the Xft library for X11 antialiased fonts, in 
which
case fl_font_xft.cxx::XftDrawString32() is used (along with what looks
like a new and different font list).

I would suggest configuring 1.3.0 without Xft for now, and working
on adding XUtf8DrawString() to nxlib/Text.c, having the same
implementation as XDrawString except passing the GR_TFUTF8
flag as discussed in the previous email.  I'm not sure which library
XUtf8DrawString is coming from now, you might check in to it,
and look at it as a basis for other mods to nxlib.

Regards,

Greg