Is there a true mono-spaced font for the text display widget?

[david allen]

I have tried the default and the "screen font" but the numbers don't line up. See attached screenshot.

[Greg Ercolano]

On 10/30/17 11:29, david allen wrote:
> I have tried the default and the "screen font" but the numbers don't line up. See attached screenshot.

I typically use FL_COURIER for fixed width fonts.

[david allen]

Thanks --- looks much much better

[Greg Ercolano]

On 10/30/17 12:46, david allen wrote:
> Thanks --- looks much much better

Yes; I'm not sure though why 'screen' isn't showing up monospace.

On my machine it's the same way; if I run FLTK's test/fonts app
and click on 'screen', I get a variable width font that looks exactly
like "sans".

My machine has no font named 'screen' or "lucida", so I imagine
FLTK is falling back to helvetica for FL_SCREEN.

If I click on "mono" in the test/fonts app, I get a monospaced font
that would probably be a good font for FL_SCREEN.

You can reassign e.g. FL_SCREEN to a different font on your system
if you know the font's name using Fl::set_font(). e.g.

_____________________________________________________________________________
#include <FL/Fl.H>
#include <FL/Fl_Window.H>
#include <FL/Fl_Box.H>
int main(int argc, char **argv) {
// ASSIGN 'FL_SCREEN' A MONOSPACED FONT (LINUX)
Fl::set_font(FL_SCREEN, " mono"); // I can't remember what the leading space is for
Fl_Window *win = new Fl_Window(720, 486, "Simple font test");
Fl_Box *box = new Fl_Box(0,0,win->w(),win->h());
box->labelfont(FL_SCREEN); // use the screen font we re-assigned above
box->label("This is XXX---WWWMMMiiilll a test\n01234567890123456789"); // string to test for monospacing
win->end();
win->show();
return(Fl::run());
}
_____________________________________________________________________________

[Evan Laforge]

On Mon, Oct 30, 2017 at 1:06 PM, Greg Ercolano <erco@> wrote:
> Fl::set_font(FL_SCREEN, " mono"); // I can't remember what the leading space is for

Sorry to seize on this one thing, but FLTK on X does this strange
thing where it turns the various bold italic etc. variants into a
letter code prefix. Space means no special formatting.

I tripped over this a while back when it made porting between OS X and
X awkward, since only the X backend does this. Also it seems to be
undocumented. At least I only found out from looking in the source.

I'd advocate for removing that feature, but of course it will break a
bunch of people's hard coded font names that only work on X so there
would probably have to be some compatibility thing where they're still
available under the old names and etc. etc. Since I personally can
fix it just by sticking a "if platform==X prepend ' '" in a low level
routine, I wasn't hugely motivated to go through the hassle.

But I do think it's an awkward wart and in an ideal world we could fix
up things like that so other people don't have to trip over it.

[Greg Ercolano]

Feel free to suggest a patch, or some code solution + docs,
or if there's an STR about this, feel free to lobby for it here.
I've never fully understood all the ins/outs of the cross platform
font stuff, esp. when it comes to other languages.

Linux has historically been the harder one for my app to support
in e.g. Japanese. I never know what font will be available for
correct display of Japanese text, as it seems to vary for different
distros. I recall this got a little better recently, but can't
remember the details.

[Evan Laforge]

> Feel free to suggest a patch, or some code solution + docs,
> or if there's an STR about this, feel free to lobby for it here.
> I've never fully understood all the ins/outs of the cross platform
> font stuff, esp. when it comes to other languages.

Sure, it would be good to document it somewhere at least, so it's a
"known issue." I think the "solution" is just stop munging the font
names, but keep the old names around for a couple of versions along
with some kind of warning about "if you want italic Z, then ask for
font("Z", FL_ITALIC) instead of font("iZ") or however it winds up
looking. The problem is always that no one likes getting warnings and
messing about with old code that worked just fine before the library
had to go change things :)

> Linux has historically been the harder one for my app to support
> in e.g. Japanese. I never know what font will be available for
> correct display of Japanese text, as it seems to vary for different
> distros. I recall this got a little better recently, but can't
> remember the details.

Probably some of that is the fault of the general font mess on X.
It's not just the two completely different systems, but the new
fontconfig system "fixes" the ridiculous baroque old fashioned X
system with its own ridiculous baroque XML fuzzy matching whatever,
that always seems to put in random backslashes or always match the
same font no matter what you request, or be still chaotically
documented after however many decades.

Why yes, I have struggled with this and have a bit of a pet peeve, how
did you know?

[Greg Ercolano]

On 10/30/17 14:47, Evan Laforge wrote:
> Why yes, I have struggled with this and have a bit of a pet peeve, how
> did you know?

Yeah, linux.. the parts they took from unix work well, but a lot
of the stuff developed on their own.. not so much. Fonts, X11 configs,
boot scripts, desktop environments, audio, device trees, libc versions,
too many daemons.. all a mess.

And don't even get me started on systemd, damn.

But yum is pretty great; I'm no longer worried about installing
new tools by being dragged through dependency hell. It always seems
to automagically handle things pretty well.