Phil Stracchino

Never mind, I just got it to stick, I think.

Upon further investigation, I'm not seeing USE_XFT being passed as a compile argument. I modified my Gentoo ebuild for xnedit to make sure that both USE_XFT=1 and the correct processor CFLAGS were being explicitly passed, then recompiled and tried again, even duplicating nedit* to XNEdit* just in case, and I still cannot specify the interface font, or even increase its size. My current Xresource stanza is: nedit*defaultRT.fontList: -misc-univers-regular-r-normal-*-*-16-*-*-p-*-*-1 nedit*defaultRT.fontName:...

Upon further investigation, I'm not seeing USE_XFT being passed as a compile argument. I modified my Gentoo ebuild for xnedit to make sure that both USE_XFT=1 and the correct processor CFLAGS were being explicitly passed, then recompiled and tried again, even duplicating nedit* to XNEdit* just in case, and I still cannot specify the interface font, or even increase its size. My current Xresource stanza is: nedit*defaultRT.fontList: -misc-univers-regular-r-normal-*-*-16-*-*-p-*-*-1 nedit*defaultRT.fontName:...

I haven't changed fontType from FONT_IS_XFT. No matter how I specify it, though, whether in .Xresources, on the command line using -xrm, or by directly moficying nedit.c, XNedit appears to ignore my interface font specification and gives me an almost-unreadably tiny font. I can't even override the font size with a simple -xrm '*fontSize: 18'. I'm not quite sure what to try next.

I haven't changed fontType from FONT_IS_XFT. No matter how I specify it, though, whether in .Xresources, on the command line using -xrm, or by directly moficying nedit.c, XNedit appears to ignore my interface font specification and gives me an almost-unreadably tiny font. I can't even override the font size with a simple -xrm *fontSize: 18. I'm not quite sure what to try next.

To add to this question: Is there any way to configure Xnedit to use a SCALABLE font for its menus? I'm trying to eliminate bitmapped fonts from my system. (It's not font purism; the problem I'm trying to solve is that while Gimp 2 didn't do it, Gimp 3 cannot be told not to enumerate every individual size of every bitmap font on the system in its text tool's font pull-down.)

That could probably best be achieved by a naïve file-size check before even TRYING to load the file. "Directory listing says this file is 2.8GB in size. It is too large to be loaded into xnedit."

Honestly it doesn't seem like a limitation one would hit very often, but I suppose the ticket indicates the use case does actually exist. My short-term workaround would be to split the log file into managable-size chunks using a cli tool. 'split -l 10000000 $FILE' seems a good first step.