Fonts not working properly

288 views
Skip to first unread message

RT Mistler

unread,
Sep 2, 2014, 2:57:48 PM9/2/14
to fltkg...@googlegroups.com
I've been trying a few options to get just font sizes and styles like bold working; using the standard fonts.  I see absolutely no changes even when specifying things like 36 or 48 point font size.

I have a Fl_Window, Fl_Group, some Fl_Box'es, and a Fl_Button.

The Fl_Boxes are really my way of displaying text on the screen.  I can do something else, in my reckoning, this is the equivalent of an Fl_Label; or rather that the Fl_Label is included with the Fl_Widgets.  Perhaps I'm incorrect on this.

Window is created, I create a few boxes with text and my button, also with text.  I add them to the group and I see this all.  I also can control text color via the labelcolor() function.

Therefore I was assuming it was a natural progression to be able to use labelsize() and labelfont(), thereupon using numbers like labelsize(24), labelsize(36), and so forth.  No changes.  labelfont(FL_HELVETICA_BOLD), labelfont(FL_TIMES_BOLD).  No changes.

I encountered a conversation here (Getting started) where someone brought up the fact that Truetype fonts were not working.  Well I'm not asking for TT fonts, just controllability of what I do have.  The recommendation was to install libxft-dev and reconfigure FLTK (I have 1.3.2) using the --enable-xft flag.  These changes worked, I cleaned my directory, ran configure, make, and install; and was able to remake my application.  The result was that my application crashed immediately.  So I cleaned my FLTK make out again, reconfigured normally, remade FLTK and reinstalled it, then recompiled my application.  Back to working.  I had no problems installing the libxft-dev package, I did also remove that after my failed experiment.

There are some other references, none of which work.

I'm using a BeagleBone Black running the Angstrom 3.8 kernel.

Just not understanding how I cannot control font size, choice of standard font, as well as whether or not it can be bold, or italic.  Fact is I may not require bold at all if I can increase the font size and just look at how it appears on the screen (LCD3 CAPE).

I also happen to be running my FLTK application through the XServer, but with no display manager.

Any suggestions?  I'm thinking that this should just work.  The only thing I can think of is that my Angstrom doesn't have fonts installed, therefore I have to wonder what package I would install which would give me the proper fonts.

Best Regards,

- RT

Ian MacArthur

unread,
Sep 2, 2014, 5:29:18 PM9/2/14
to fltkg...@googlegroups.com
On Tue Sep 02 2014 19:57:48, RT Mistler wrote:
> I'm using a BeagleBone Black running the Angstrom 3.8 kernel.
>
> Just not understanding how I cannot control font size, choice of standard font, as well as whether or not it can be bold, or italic. Fact is I may not require bold at all if I can increase the font size and just look at how it appears on the screen (LCD3 CAPE).
>
> I also happen to be running my FLTK application through the XServer, but with no display manager.
>
> Any suggestions? I'm thinking that this should just work. The only thing I can think of is that my Angstrom doesn't have fonts installed, therefore I have to wonder what package I would install which would give me the proper fonts.


I’ve never had a BeagleBone Black; used to have some early v1/v2 BeagleBoards though - they worked OK, but the Angstrom distro was “quirky” to say the least... took a fair bit of tweaking to get it working they way I liked.

Recently I’ve mainly been using R.Pi’s, and they are much more “normal” in that the distro they have is pretty much stock debian, and Just Works.

I’d suggest your easiest option might be to build and test some examples on a regular machine and get a feel for what works and what doesn’t, see how it all hands together, then once you have some sample code that does what you need, try it on the BBB and see what happens there. (Shouldn’t matter what you test on, at the fltk code level Linux, WIN32 and OSX pretty much work The Same...)

I’m guessing it’s just missing a few packages from the BBB, though I’ve no idea what to try!

Do the fltk test and example programs work? What do they do when run - do the two font tests display useful font faces and sizes, or...?



RT Mistler

unread,
Sep 3, 2014, 8:57:38 AM9/3/14
to fltkg...@googlegroups.com
Hi,

Thanks for your post.  The suggestion is well received and embarrassingly acknowledged, because I've been programming long enough to have known better to try it on a more full featured system.

However, this does not alleviate any of these problems.

My app behaves the same.

In the FLTK examples, there is one called textdisplay-with-colors.cpp.  It compiles and runs.  I had already managed colors before, and that continues to work.

That example uses COURIER size 18.  It looks suspiciously like a font, which could be courier, but not size 18.

I edited the source, they use a table of 4 text type specifications.  I set two of the table entries for Helvetica and changed all the sizes to be different, like 18, 24, 36, 48, and optionally made two of them bold.  I ended up seeing nothing more than the original result, which is colorized text all of the same size.

I also did try to use the --enable-xft flag by reconfiguring and rebuilding my FLTK.  Therefore I have tried it both as the default and also with that option.

The development system I tested it on was Ubuntu 12.04 with added packages for gcc development as well as the libx11-dev package; probably many other added packages.  The system clearly does have fonts though.

Bummer.  Thanks for the great suggestion, actually staging my screens may be a bit faster this way without having to get them onto the target first.  Either case, I'm still unable to specify or control fonts in any manner.

Best Regards,

- RT

MacArthur, Ian (Selex ES, UK)

unread,
Sep 3, 2014, 10:43:22 AM9/3/14
to fltkg...@googlegroups.com
> In the FLTK examples, there is one called textdisplay-with-colors.cpp.
> It compiles and runs. I had already managed colors before, and that
> continues to work.

> That example uses COURIER size 18. It looks suspiciously like a font,
> which could be courier, but not size 18.

> I edited the source, they use a table of 4 text type specifications. I
> set two of the table entries for Helvetica and changed all the sizes to
> be different, like 18, 24, 36, 48, and optionally made two of them bold.
> I ended up seeing nothing more than the original result, which is
> colorized text all of the same size.

You need to try the samples test/fonts and test/utf8, as these are directly concerned with font manipulation.

In particular, if running test/utf8, you can select the "Self" checkbox, and the font list should try and render each font name in its own face, providing a "quick and easy" check that rendering of alternate faces is working. These tools should let you check different faces and sizes directly in the GUI as a test.

Though note that the "quick" part of "quick and easy" may be misleading, at least the first time, since if you have *a lot* of font faces installed (I have) then actually enumerating them all that first time can take a while...

Try that and let us know what it shows; on all my extant systems, including the R.Pi's, it Just Works and correctly shows a wide range of faces, sizes and styles...



> I also did try to use the --enable-xft flag by reconfiguring and
> rebuilding my FLTK. Therefore I have tried it both as the default and
> also with that option.

What did configure actually report? Is it finding XFT / Fontconfig when it runs on your reference system?


> The development system I tested it on was Ubuntu 12.04 with added
> packages for gcc development as well as the libx11-dev package; probably
> many other added packages. The system clearly does have fonts though.

It also needs the dev headers for XFT and fontconfig too, of course. Which you may well have. That said Ubuntu is a bit weird about the defaults for dev stuff; they leave out an awful lot of stuff that you need to add by hand!


> Bummer. Thanks for the great suggestion, actually staging my screens
> may be a bit faster this way without having to get them onto the target
> first.

Yes; always develop on the PC first, then bounce it onto the target once it is basically working!



Selex ES Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

Artie Mistler

unread,
Sep 3, 2014, 11:25:18 AM9/3/14
to fltkg...@googlegroups.com
Yes, I see what you mean now.  Those on my dev station do work and work well.  It also highlights that ones like Helvetica do not work actually.  The things I have to do now are to perform some of these actions on my target.  The target has a very small screen and I'm not running XServer so I see the fonts app, but can't play with any of the choices, further I can't see that whole screen.  For some reason the utf8 doesn't run on my target.  Either case, I can draw upon the text manipulation methods used in those and then just make myself a screen sized dump of some choices and see what fonts I am able to use on the target and also manipulate.

Thanks for the suggestions, I should also write an update once I fully get a conclusion, so I will do that.

- RT



--
You received this message because you are subscribed to a topic in the Google Groups "fltk.general" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fltkgeneral/QjshesKQFLM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fltkgeneral...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Greg Ercolano

unread,
Sep 3, 2014, 11:41:48 AM9/3/14
to fltkg...@googlegroups.com
Sure sounds weird to me.

I've been using linux as a desktop since the 90's, and have commercial
software using FLTK that has to support most of the popular linux distros
and have not seen the behavior you're describing.

You mentioned running the X server without a display manager (window manager).
Is this the case in all your tests, or are you getting this lack of font size control
on a regular system with one of the stock window managers?

Have you tried running tools like xfontsel to see what pxlsz values are available
for the various fonts (e.g. with fmly set to helvetica, courier, times, etc) and gimp's
font selector to see what's available?
--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.

MacArthur, Ian (Selex ES, UK)

unread,
Sep 3, 2014, 12:09:50 PM9/3/14
to fltkg...@googlegroups.com
> Yes, I see what you mean now. Those on my dev station do work and work
> well.

Well, that's a relief!

> It also highlights that ones like Helvetica do not work actually.

OK, that's interesting; though it implies that your fonts.alias is maybe not quite right then.

It seems like few distros actually ship a "real" Helvetica face any more (I don't know why not, maybe licensing or something?) but loads of applications expect to find it, so the alias ought to be returning a credible substitute if ever Helvetica is requested...

Sounds like that may not be working on your system?


> The things I have to do now are to perform some of these actions on my
> target. The target has a very small screen and I'm not running XServer
> so I see the fonts app, but can't play with any of the choices, further
> I can't see that whole screen.

OK, if xinput and such is working, can you click on widgets and have them respond at all?


> For some reason the utf8 doesn't run on
> my target.

Hmm, that's curious; do you get anything interesting in the console when you try to run it?

> Either case, I can draw upon the text manipulation methods
> used in those and then just make myself a screen sized dump of some
> choices and see what fonts I am able to use on the target and also
> manipulate.

If you write a bit of code that enumerates all the fonts when it starts (both fonts and utf8 do, so just copy that code!) you can then get a count of how many faces were found, and then have a loop that starts at 1 and displays some sample text for every font index for (say) 10 seconds each in a loop, that way you can see every face on the box in one "easy" test...

(Fl::add_timeout() is you friend here!)

MacArthur, Ian (Selex ES, UK)

unread,
Sep 3, 2014, 12:34:32 PM9/3/14
to fltkg...@googlegroups.com
> If you write a bit of code that enumerates all the fonts when it starts
> (both fonts and utf8 do, so just copy that code!) you can then get a
> count of how many faces were found, and then have a loop that starts at
> 1 and displays some sample text for every font index for (say) 10
> seconds each in a loop, that way you can see every face on the box in
> one "easy" test...

Here's what I meant; build with
fltk-config --compile font-test.cxx

----

#include <FL/Fl.H>
#include <FL/Fl_Double_Window.H>
#include <FL/Fl_Button.H>
#include <FL/Fl_Box.H>

static Fl_Double_Window *main_win=(Fl_Double_Window *)0;
static Fl_Button *quit_bt=(Fl_Button *)0;
static Fl_Box *text_win=(Fl_Box *)0;

static int font_count = 0;

#define DELAY_PER 0.5
#define BASE_SIZE 12

static void cb_quit_bt(Fl_Button*, void*) {
main_win->hide();
}

static void update_text(void *) {
static int count = 0;
static int sz = BASE_SIZE;
count ++;
if (count >= font_count) {
count = 1;
++sz;
if (sz > 36) sz = BASE_SIZE;
}
text_win->labelsize(sz);
text_win->labelfont((Fl_Font)count);
text_win->redraw();
Fl::repeat_timeout(DELAY_PER, update_text);
}

int main(int argc, char **argv) {

const char *test_txt = "The Quick Brown Fox Jumped etc.";

font_count = Fl::set_fonts("*");

main_win = new Fl_Double_Window(537, 160, "Font Faces");
main_win->begin();

quit_bt = new Fl_Button(7, 5, 75, 40, "Quit");
quit_bt->callback((Fl_Callback*)cb_quit_bt);

text_win = new Fl_Box(7, 58, 445, 74, test_txt);
text_win->box(FL_FLAT_BOX);
text_win->labelsize(BASE_SIZE);
text_win->align(Fl_Align(FL_ALIGN_LEFT|FL_ALIGN_INSIDE));

main_win->end();
main_win->show(argc, argv);

Fl::add_timeout(DELAY_PER, update_text);

return Fl::run();
}

/* end of file */

Artie Mistler

unread,
Sep 3, 2014, 1:12:02 PM9/3/14
to fltkg...@googlegroups.com
Yep, I plan to copy that example into my app and run some tests.

To cover some details that you've brought up as well as the Q's from Greg Ercolano.

I'm not installing anything special.  GNOME or any other display manager is not installed or disabled.

I'd would actually prefer to run off of the frame buffer; however FLTK wasn't quite there yet and not sure if development is proceeding for a variation that does go to the frame buffer, it was stated to be planned for one of the future releases.  Not going to complain, right now it works pretty good.

I run XServer, but no display manager and use the xf86-video-fbdev package.  This just means that if you run something like xterm, that you will have zero window decorations, no borders, no scrollbars, no styles no menus.

We're running our FLTK app right out of xinitrc, and nothing else, it is a full screen app.

My xorg.conf is very limited, in fact more of it is tuned to disable all the power saving and screen blank features.  The other important change is that the screen is rotated 1/4 turn because the native mode is landscape and we use the display in portrait orientation.  This also means that we don't have to rotate the graphics, and just specify stuff like the window is at (0,0) and sized (240x320) for QVGA screen size.

Formerly I used an ATOM CPU with Qt 4.6.  I actually got Qt 4.8 running on this Beagle; however it ate almost all the resources; I could only get it working compiled as static.  Since I got a rudimentary FLTK test app up, I'm now expanding it.

The fonts are some plain vanilla variation.  Maybe the screen rotation is interfering, I may yet learn that.

The demo that I did is fine, but pretty much everyone said "that font is a poor choice .... looks a bit too small and very low graphics"  Right now it is readable, just not ideal and not too pretty.

So I'm writing the core of the app and meanwhile I have a very limited main screen version of that app which just has a text field and a button.  I'll use that limited version to experiment with the fonts by taking from the cited examples.  It'll probably take me a few days to get to that.  I may find that what I have is missing installed fonts.  I did a minor bit of searching for stuff like "Angstrom fonts" and such.  Nothing obvious.  I started with the 3.8 Angstrom kernel for the Beaglebone Black and the default RFS that they have; however I trim the features down by way of not starting things, the first example being GNOME.  And also have to install some stuff to get things working properly for my actual app.  My guess is I may have one or two more crappy fonts actually on the system and may have to install some more to make this work properly.


I've used Pi systems too, but we attach a normal monitor to those.  The Beagles can IMHO more readily take a small touch display.

Thanks again.  I will update with some findings once I get there.



--
You received this message because you are subscribed to a topic in the Google Groups "fltk.general" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fltkgeneral/QjshesKQFLM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fltkgeneral...@googlegroups.com.

MacArthur, Ian (Selex ES, UK)

unread,
Sep 4, 2014, 6:09:16 AM9/4/14
to fltkg...@googlegroups.com
> Yep, I plan to copy that example into my app and run some tests.

Interested to hear how that comes out...


> I'm not installing anything special. GNOME or any other display manager
> is not installed or disabled.

There are some *very* light-weight X window managers around, that might be worth a look, as they do make managing the windows easier. Including flwm, now I think of it!

That said, we've done a few "kiosk" things running a full screen window with no WM and that's a good option; that sounds like what you are doing, too, I guess?

> I'd would actually prefer to run off of the frame buffer; however FLTK
> wasn't quite there yet and not sure if development is proceeding for a
> variation that does go to the frame buffer, it was stated to be planned
> for one of the future releases. Not going to complain, right now it
> works pretty good.

I wouldn't hold out for a framebuffer variant, it doubt it will happen.

I confess I don't really understand why folks are so worried about X that they think FB is a better option; we used to run X on 50MHz 486's back in the day, and still have enough compute resource left to do useful work, so running it on a modern embedded CPU is a non-issue these days; what's the BBB got? It's 1GHz or something CPU, plus a pretty decent GPU stack...

Also, if you are running a lightweight X (I'm thinking tiny-X/ K-drive stuff here) the resource footprint is lower again.

If you really want to try FB, then a possible option might be to build nano-X for your FB, then use fltk on nano-X; current fltk-1.3.x works pretty well on nano-X, Georg has some pertinent notes on his site, and I posted a howto about it not so long ago, too.
If you want to go that way, I have some patches to nano-X and to fltk to improve font handling under nano-X that might be useful (supports text rotation and stuff, that the "stock" fltk-on-nano-X doesn’t do, for example.)



> My xorg.conf is very limited, in fact more of it is tuned to disable all
> the power saving and screen blank features. The other important change
> is that the screen is rotated 1/4 turn because the native mode is
> landscape and we use the display in portrait orientation. This also
> means that we don't have to rotate the graphics, and just specify stuff
> like the window is at (0,0) and sized (240x320) for QVGA screen size.

Yup, sounds about right; though you do need to be sure that something will serve fonts, usually fontconfig and so forth these days...


> Formerly I used an ATOM CPU with Qt 4.6. I actually got Qt 4.8 running
> on this Beagle; however it ate almost all the resources; I could only
> get it working compiled as static. Since I got a rudimentary FLTK test
> app up, I'm now expanding it.
> The fonts are some plain vanilla variation. Maybe the screen rotation
> is interfering, I may yet learn that.

I suspect that you are getting the fallback built-ins, because no font server is available?
Is that possible?


> The demo that I did is fine, but pretty much everyone said "that font is
> a poor choice .... looks a bit too small and very low graphics" Right
> now it is readable, just not ideal and not too pretty.
> So I'm writing the core of the app and meanwhile I have a very limited
> main screen version of that app which just has a text field and a
> button. I'll use that limited version to experiment with the fonts by
> taking from the cited examples. It'll probably take me a few days to
> get to that. I may find that what I have is missing installed fonts. I
> did a minor bit of searching for stuff like "Angstrom fonts" and such.
> Nothing obvious. I started with the 3.8 Angstrom kernel for the
> Beaglebone Black and the default RFS that they have; however I trim the
> features down by way of not starting things, the first example being
> GNOME. And also have to install some stuff to get things working
> properly for my actual app. My guess is I may have one or two more
> crappy fonts actually on the system and may have to install some more to
> make this work properly.

Is there no debian for the BBB these days? I had thought there was... I'd certainly go with debian over Angstrom, based on my experiences with each.


> I've used Pi systems too, but we attach a normal monitor to those. The
> Beagles can IMHO more readily take a small touch display.

OK; though I've seen some pretty neat stuff done with the R.Pi and a touchscreen. The BBB has a more capable CPU, but the GPU stack in the R.Pi is "better", so it kinda depends...

Artie Mistler

unread,
Sep 9, 2014, 3:05:28 PM9/9/14
to fltkg...@googlegroups.com
I've finally tried to progress on this and I'd like to ask if there's any simple example recommendations.  I'm also wondering if I need to use the UTF8 functions.

The UTF8 test application works on my dev desktop, it compiles and works on my target too, but I can't do much with it.  I've made something small on my dev machine and my target which gets the list of fonts and prints them out.  Turns out my target has about 36 entries, including Helvetica, Times, and Courier, along with bold and italic.  That's all fine.  I try to put them in a buffer and show them and I'm having little success.  Same thing for my dev machine.  I know they work at least on that dev machine because they work when I run the utf8 example.

The UTF8 example is pretty large; I am reading it, but hoping that there are some shorter recommendations.  I've tried to build something small from scratch.

My issue is that the screen size on the Beagle is 1/4 VGA, I don't have a mouse or cursor, or keyboard, adding them brings two or more complications first they're really not included, the display loads with no cursor nor mouse driver, and the display is also very small.  Therefore my attempts are just to create a small buffer, specify a font, a size, a style and see the results.  I at least got my list of fonts using the following program, which is an edit of the fonts.cxx example:

[code]
Fl_Window *window;
Fl_Box *output_box;
#define FL_Light_Grey 0xE0E0E000


int main(int argc, char **argv)
{
    int font_count;
    int font_idx;
    int first_free = 0;
    int font_type;
    char tmp_str[256];
    char out_str[4096];

    font_count = Fl::set_fonts("-*-*-*-*-*-*-*-*-*-*-*-*-iso10646-1");

    memset(out_str, 0, sizeof(out_str));

    sprintf(out_str, "Font Count = %d\n", font_count);

    for(font_idx = first_free; font_idx < font_count; font_idx++) {
        const char *name = Fl::get_font_name((Fl_Font)font_idx, &font_type);
        sprintf(tmp_str, "Index: %d Name: %s\n", font_idx, name);
        strcat(out_str, tmp_str);
    }

    window = new Fl_Window(1024,768);
    window->color(FL_WHITE);

    output_box = new Fl_Box(10, 10, 1004, 740, "Output Box");
    output_box->labelcolor(FL_BLUE);
    output_box->box(FL_THIN_DOWN_BOX);
    output_box->color(FL_Light_Grey);
    output_box->align(FL_ALIGN_INSIDE | FL_ALIGN_LEFT_BOTTOM);

    window->end();

    output_box->label(out_str);

    window->show(argc, argv);

    window->redraw();

    return Fl::run();
}
[/code]

Any attempts on my part fo change the font via labelfont() or labelsize() does not work.

Next if I take another simple text example, but using Fl_Text_Display and Fl_Text_Buffer (me figuring maybe an Fl_Box won't take these fonts), this example also pretty much ignores my attempts to change the size or font:

[code]
#include <FL/Fl.H>
#include <FL/Fl_Window.H>
#include <FL/Fl_Text_Display.H>
int main() {
     // Style table
     Fl_Text_Display::Style_Table_Entry stable[] = {
         // FONT COLOR      FONT FACE   FONT SIZE
         // --------------- ----------- --------------
         {  FL_RED,         FL_COURIER, 18 }, // A - Red
         {  FL_DARK_YELLOW, FL_COURIER, 18 }, // B - Yellow
         {  FL_DARK_GREEN,  FL_COURIER, 18 }, // C - Green
         {  FL_BLUE,        FL_COURIER, 18 }, // D - Blue
     };
     Fl_Window *win = new Fl_Window(640, 480);
     Fl_Text_Display *disp = new Fl_Text_Display(20, 20, 640-40, 480-40, "Display");
     Fl_Text_Buffer *tbuff = new Fl_Text_Buffer();      // text buffer
     Fl_Text_Buffer *sbuff = new Fl_Text_Buffer();      // style buffer
     disp->buffer(tbuff);
     int stable_size = sizeof(stable)/sizeof(stable[0]);
     disp->highlight_data(sbuff, stable, stable_size, 'A', 0, 0);
     // Text
     disp->textsize(48);
     disp->textfont(FL_HELVETICA_BOLD);
     tbuff->text("Red Line 1\nYel Line 2\nGrn Line 3\nBlu Line 4\n"
                 "Red Line 5\nYel Line 6\nGrn Line 7\nBlu Line 8\n");
     // Style for text
     sbuff->text("AAAAAAAAAA\nBBBBBBBBBB\nCCCCCCCCCC\nDDDDDDDDDD\n"
                 "AAAAAAAAAA\nBBBBBBBBBB\nCCCCCCCCCC\nDDDDDDDDDD\n");
     win->resizable(*disp);
     win->show();
     return(Fl::run());
}
[/code]

So these are raising a red flag to me, telling me that I'm missing something fundamental.  And then I see a UTF8 function being used in the UTF8 example, but ... the example I'm looking at does it character by character.  Gee ... I have to do THAT?  That's my next attempt.  I guess not to bad if it works and then I'll create helper functions to write strings out.  Just seems weird.

Either case, if someone has a like .... 50 or so line example.  One field, one string.  You change "here" and "here" to change font and size; sort of example, that would be way better than the UTF8 one that they give you.

Once again the easiest thing for me to do is to make "a" buffer/box/displayfield and write one short string to it like hello world and be able to control that properly.  Right now the system at least tells me I have 3 usable fonts in bold and italic; there are more but those three are fine; so just trying to be as simple as I can to use them.  Actually I'm kind of aghast that this isn't easy, even with my dev station.  I know that the UTF8 example works on my dev station, it compiles and works on my target, just with small screen and no mouse I can't do anything with that native example.  So it stands to reason that I should be able to create some very small example showing fonts on my dev station and then move that to my target and prove that I can do the same.  Right now I can't accomplish that feat as yet.


Ian MacArthur

unread,
Sep 9, 2014, 4:37:47 PM9/9/14
to fltkg...@googlegroups.com
On Tue Sep 09 2014 20:05:27, Artie Mistler wrote:
> I've finally tried to progress on this and I'd like to ask if there's any simple example recommendations.


You probably need to spend some time playing with the samples in the test and examples folders, and maybe have a wander around Greg’s cheat sheet too, just to get a grasp:

http://seriss.com/people/erco/fltk/

That said, I think you are maybe overthinking this, thinking it is harder than it is...


> I'm also wondering if I need to use the UTF8 functions.

No, you don’t.

Also, did the little demo I posted earlier in this thread not work for you? At least on the desktop it should Just Work.


> The UTF8 example is pretty large; I am reading it, but hoping that there are some shorter recommendations. I've tried to build something small from scratch.

Don’t do what it does to manipulate fonts: both utf8 and the font browser example are doing “unusual” things to allow them to list and display all the different faces. You don’t need nor want to do that.


> Any attempts on my part fo change the font via labelfont() or labelsize() does not work.

They are the way to go; I’m guessing you are not poking them quite right though!


> Next if I take another simple text example, but using Fl_Text_Display and Fl_Text_Buffer (me figuring maybe an Fl_Box won't take these fonts), this example also pretty much ignores my attempts to change the size or font:

An Fl_Box, or indeed any widget with a label, should be fine - don’t get into Fl_Text_display et al unless you really need those features...

Here’s the basic example; creates a window of 240x320, and displays some text in 18 size, with the face set to Baskerville (which I chose at random because it exists on this test box - pick a name that works for your systems!)

------------
#include <FL/Fl.H>
#include <FL/Fl_Double_Window.H>
#include <FL/Fl_Button.H>
#include <FL/Fl_Box.H>

static Fl_Double_Window *main_win=(Fl_Double_Window *)0;
static Fl_Button *quit_bt=(Fl_Button *)0;
static Fl_Box *text_win=(Fl_Box *)0;

static void cb_quit_bt(Fl_Button*, void*) {
main_win->hide();
}

int main(int argc, char **argv) {
const char *test_txt = "The Quick Brown Fox Jumped etc.";

main_win = new Fl_Double_Window(240, 320, "Font Test");
main_win->begin();

quit_bt = new Fl_Button(7, 5, 75, 40, "Quit");
quit_bt->callback((Fl_Callback*)cb_quit_bt);

text_win = new Fl_Box(7, 58, 225, 200, test_txt);
text_win->box(FL_FLAT_BOX);
text_win->align(Fl_Align(FL_ALIGN_LEFT | FL_ALIGN_INSIDE | FL_ALIGN_WRAP));

Fl_Font my_font = FL_FREE_FONT + 1;
Fl::set_font(my_font, "Baskerville");

text_win->labelsize(18);
text_win->labelfont(my_font);

main_win->end();
main_win->show(argc, argv);
return Fl::run();
}

/* end of file */

------------------

Artie Mistler

unread,
Sep 10, 2014, 9:03:19 AM9/10/14
to fltkg...@googlegroups.com
Thanks for the reply, and sorry you did recommend an example such as that earlier.  I am also familiar with Erco's page and find it very helpful.  Basically with this test, I can see the font I have been seeing and some symbol font and that's about it. There are no bold or italic changes, at one point the font disappears briefly, implying that there is a face, but not visible and then I see the symbol one also briefly.  So ... I have to install fonts; something I was searching for a bit yesterday and will continue.

It's relieving to know that really the simple actions "should" work, and the test clearly does work well on my dev station, so it's Angstrom that's really my problem here.  I may progress to use Debian as we go further with this project.


Ian MacArthur

unread,
Sep 10, 2014, 3:16:47 PM9/10/14
to fltkg...@googlegroups.com
On Wed Sep 10 2014 14:03:17, Artie Mistler wrote:
> Thanks for the reply, and sorry you did recommend an example such as that earlier. I am also familiar with Erco's page and find it very helpful. Basically with this test, I can see the font I have been seeing and some symbol font and that's about it. There are no bold or italic changes, at one point the font disappears briefly, implying that there is a face, but not visible and then I see the symbol one also briefly. So ... I have to install fonts; something I was searching for a bit yesterday and will continue.
>
> It's relieving to know that really the simple actions "should" work, and the test clearly does work well on my dev station,

Yes; I’d strongly advocate for doing testing and dev on the desktop box, and only move onto the target once the code is “working"; then it *should* be easier to identify the things that are target specific... Hopefully!


> so it's Angstrom that's really my problem here. I may progress to use Debian as we go further with this project.

It’s a long time since I tried Angstrom, so I can’t really comment, but I will say I’ve had fewer issues with the debian stuff than I recall having with Angstrom, so it may be a better base to build from.

Is there a detain package for the BBB? I *think* I heard there was, but I don’t have a BBB so don’t know for sure...




Artie Mistler

unread,
Sep 10, 2014, 3:25:01 PM9/10/14
to fltkg...@googlegroups.com
You can run Debian and Ubuntu on BBB I believe.  I did try Debian at one point, the attempt failed with my first minor attempts.  Meanwhile Angstrom always loaded and worked, with some minor quirks.  Sad to say but I embarked using Angstrom and am tied to it until I devote a few days or so to experiment with another distribution.  One of those situations where you never have time, but you ought to find the time...


Reply all
Reply to author
Forward
0 new messages