Appearance (X resource) unification #4704

skef · 2021-04-14T07:42:35Z

Including:

Relative font specification
A bunch of appearance fixes and tweaks
Fixes for FAQ or FeatureReq: How to change the font size of the measure tool? #4454 Allow User to Set Font Color #4391 Support better selection of FontInfo font #4238 FontForge should use SF Pro as its UI font on macOS, instead of Helvetica #3844 Please correct font line height in GUI #3835 xResourceEditor: missing ListMark icon, duplicate colors, default font size #3443 (partial) Check boxes in layers palette reverting back to eye icon #3051 Use GNU Unifont at 16px #1031 Controlling the default UI fonts #863 Option to remove Ascent and Descent guides #4274

For historical reasons the UI knobs in FontForge are supplied in X Resource format. There may still be some minimal compatibility with that system but given that its mostly supplied via GDK now that's not very important.

At some point a handy resource editing dialog was added so that less technical users could customize the UI. There was some effort put into unifying the initialization and the editing at that time but mostly in the form of new APIs (mainly GResEditFind()). For the most part variables were still initialized via individual calls to GResourceFindColor(), GResourceFindString() and so on.

The bulk of this PR finishes the unification, so that initialization and editing are two uses of the same data structure. It is now easier to add new directives -- usually just a matter of declaring the static variable with an appropriate default value, adding one line to a struct resed initializer, and a corresponding line to the tango/resources.in file (if needed).

In addition to that it does the following:

Default font families for sans, serif, and mono are now defined in one place in BuildUtils.cmake and can be overridden by CMake flags. They are broken down by OS type (APPLE, WIN32 OR CYGWIN, and "other"). The current values are not final -- part of the reason I'm starting this PR as a draft is that we should discuss the best options.
Font directives can now be specified relative to other font directives as described in the included documentation changes. The supplied resource files now do this. Because most of the UI is sized in relation to fonts you can now adjust the whole UI scale by changing the (new) View.DefaultFont point size. Another result is that families are specified once in each resource file (as long as they are kept consistent with the supplied file) and therefore the UI is much more uniform in presentation.
I went through pretty much the whole UI to eliminate hard-coded colors, either by giving them new appearance directives or mapping them to either the GGadget FG or BG or the GDraw FG or BG. (GDrawGetDefaultForeground() and ...Background() now return a static value and ignore the display argument, as that generality wasn't used and mostly caused updating problems.) This allows a number of issues to be closed and means that true "dark" themes (and the like) are now possible.
Since the GDK backend already switched away from ScreenWidth directives in favor of ScreenResolution I did that on the X side for consistency.
The image cache has been restructured to minimize image path names relative to the ImagePath immediately, rather than having this happen "at the edges". The modified GResImage definition now stores the bucket instead of the file for additional flexibility.
I've changed (or occasionally de-emphasized) the "X Resource" terminology in favor of "Appearance".
The docs have been updated.

In addition to reviewing the changes this has a todo list:

Decide on font families for each OS appropriate for contemporary use
Decide what to do with the "Keyboard" resource (I think it should become a preference)

Ideally this work would be paired with a later PR that

Figures out how to pick among images (menu icons, pointers, palette icons) scaled at different sizes.
Come up with a full set of sources (probably in SVG) that can be attractively scaled that way
Modify the editing system so that tracks both a "theme" file and a user file, and only stores what is different in the latter.

Then FontForge would support proper themes, which I imagine being added through a python API hook and distributed as python packages, given that the plugin interface is already integrated.

Closes #4454
Closes #4391
Closes #4238
Closes #3844
Closes #3835
Closes #3051
Closes #1031
Closes #863
Closes #4274

ctrlcctrlv · 2021-04-14T08:24:08Z

Wow, amazing work. This took a ton of effort. Kudos.

lgtm-com · 2021-04-14T08:48:55Z

This pull request introduces 1 alert when merging e94c104 into a2f0e7d - view on LGTM.com

new alerts:

1 for Function declared in block

inc/fontforge-config.h.in

gdraw/gtextinfo.c

jtanx

On the added images, they're a fair way larger than the others, is this a colourspace difference and/or need to run through pngcrush/similar?

jtanx · 2021-04-14T09:18:55Z

gdraw/gtextinfo.c

 #define IC_SIZE	127
-static struct image_bucket *imagecache[IC_SIZE];
+static GImageCacheBucket *imagecache[IC_SIZE];


Geez, implementing our own hash table is rough.

fontforgeexe/contextchain.c

jtanx · 2021-04-14T09:34:38Z

gdraw/ggdkdraw.c

-    gdisp->twobmouse_win = tbf;
-    gdisp->macosx_cmd = mxc;
+    GDrawResourceFind();
+    gdisp->bs.double_time = _GDraw_res_multiclicktime;


I think I've expressed this elsewhere, but not really a fan of these random/externed variables for preferences (not saying though that that needs to change for this pr, just longer term goals for how preferences should be managed).

In that sense imo the old approach (or the interface at least) was cleaner/makes more sense to me.

Yeah, I suppose I added some more of that but it's still fairly modest.

In this case the "old approach" suffered from code duplication and a lack of an editing interface. It seemed strange to add the whole block to both back-ends.

It would certainly be easy enough to shove them all into a struct and give it a proper header if you think that would help.

skef · 2021-04-14T09:43:34Z

On the added images, they're a fair way larger than the others, is this a colourspace difference and/or need to run through pngcrush/similar?

I think the only image I added was downarrow_disabled.png. The rest were copied from tango into 2012 because I wasn't sure what else to do (unlike the menu and palette icons those don't have hard-coded defaults).

skef · 2021-04-14T09:58:34Z

@jtanx by the way when switching between 2012 and tango (I know .. why?) the install process isn't very good at identifying what files need to be replaced in (the equivalent of) /usr/share/fontforge/pixmaps. Not a huge deal but a little annoying.

jtanx · 2021-04-14T10:01:39Z

As in ninja install skips copying sometimes? I didn't think the install process did any dependency tracking for that.

skef · 2021-04-14T10:14:58Z

As in ninja install skips copying sometimes? I didn't think the install process did any dependency tracking for that.

Yeah, that's all I mean.

skef · 2021-04-14T11:48:54Z

One thing I didn't put much thought into is whether more of the existing or added color parameters should have an alpha channel. (Having said that, it does seem that most of the colors don't overlap with others besides the pertinent background so there's no need for it.)

If folks have opinions on this let me know and I can make the changes.

skef · 2021-04-15T03:20:23Z

I just played around with fonts a tiny bit on Arch to see how the support looks.

Arch has a mainstream package with the original bdf unifont files (https://archlinux.org/packages/extra/any/bdf-unifont/) and a user-supplied package with the ttf adaptation: https://aur.archlinux.org/packages/ttf-unifont/ . As far as I can tell the bdf fonts don't work with FontForge, at least with typical compilation flags. That's consistent with this note about about Arch pango support.

Arch is bleeding-edge so other distros may still work.

The ttf-unifont versions work pretty well as a backstop (although I guess there's little or nothing to be done past the BMP).

This may put us in a bit of a tricky situation as I'm not sure there's a mainstream outline font addressing the problem that bdf-unifont was intended to solve.

This leads me to the following initial thoughts:

Presumably the Sans family list should start with one to several fonts with reasonably good coverage and that we know work well WRT lineheight and other metrics. DejaVu Sans seems to do well on that front, although to go beyond LCG it seems like you'll need a mass of font names. Maybe we should leave CJK to the users?
After that we could put what we think is the best font that ships with the OS.
Then behind that "unifont,sans".
The burden on Serif and Mono is lower, as those just relate to the user's language rather than all code points. So skip "unifont". Otherwise the requirements are similar.
On the Mac and Windows we should have some documentation somewhere suggesting fonts to install that match our choices, and how to make other choices.
On *nix we can point to the same document but there's also more that the distro can do to help things out. We should explain the need and the relevant cmake flags and maybe encourage mainstream adoption of the ttf unifont so it can be a proper dependency.

skef · 2021-04-15T03:27:56Z

Ah, there's also https://aur.archlinux.org/packages/otb-unifont/ , which repackages the BDF as OTB (using ... FontForge!) That could be another direction we encourage.

There are some unifont line height issues we may or may not want to think about (in FontView).

ctrlcctrlv · 2021-04-18T06:49:03Z

The ttf-unifont versions work pretty well as a backstop (although I guess there's little or nothing to be done past the BMP).

@skef I'm writing to make you aware of Unifont Upper, if you are not already.

Unifont Upper supports a lot of SMP glyphs. See the codechart: http://unifoundry.com/pub/unifont/unifont-13.0.06/unifont_plane1-13.0.06.bmp

You can confirm it by comparing glyph shapes to https://en.wikipedia.org/wiki/Linear_B_Syllabary, the first encoded script in the SMP.

Unifont Upper's SMP support isn't perfect, but it encodes a lot of emoji, maths glyphs, and some rare scripts. I guess it's up to me to contribute Deseret, as I note that's missing, but for FontForge's users, I think it's not a problem for us to specify:

Unifont, Unifont Upper

ctrlcctrlv · 2021-05-30T15:00:03Z

[…]

Unifont, Unifont Upper

@skef Did you see the above?

skef · 2021-05-30T16:29:04Z

Yes, I did. It seems like all of these PRs are on indefinite hold for lack of review resources. I guess stuff will happen when it happens.

ctrlcctrlv · 2021-05-30T19:19:05Z

Unfortunately. I'd trust Jeremy or Frank to merge this, but I haven't worked on the project recently enough or at this deep of a level to really do a thorough review.

ghost · 2021-09-28T18:17:54Z

It seems like all of these PRs are on indefinite hold for lack of review resources. I guess stuff will happen when it happens.

I'd trust Jeremy or Frank to merge this.

Any progress on this pull review?

jtanx · 2021-10-05T02:07:58Z

(pure rebase to master to fix conflicts)

jtanx · 2021-10-09T00:58:43Z

fontforgeexe/statemachine.c

@@ -79,6 +80,9 @@
 #define SMDE_WIDTH	200
 #define SMDE_HEIGHT	(SMD_DIRDROP+200)

+GResFont statemachine_font = GRESFONT_INIT("400 12pt " MONO_UI_FAMILIES);
+extern Color kernclass_classfgcol; // Yes this is cheating


Cheating - meaning it doesn't have its own?

Yeah - I reused a few colors for more obscure cases when I was fairly confident no one would mind them being the same.

gdraw/gresource.c

jtanx · 2021-10-09T02:38:43Z

gdraw/gresource.c

@@ -788,7 +784,7 @@ static void _GResourceFindImage(const char *fname, GResImage *img) {
    if ( fname!=NULL ) {
 	t = _GGadgetImageCache(fname, false);
 	if ( t==NULL || t->image==NULL ) {
-	    GDrawError("Could not find image corresponding to '%s', using default", fname);


This was pretty noisy when I was running, I think it makes sense to move these to traces

I'm fine with that. Want me to do it?

Ah yeah, I've already moved them to traces

jtanx · 2021-10-09T02:43:42Z

Given the size of the pr it's hard to give too in-depth of a review but I did go over all of it and I don't spot anything obviously wrong, so I'll just mostly trust that it's doing the right thing.

In terms of outstanding actions:

Decide on font families for each OS appropriate for contemporary use

Is this just wrt what gets set in CMakeLists.txT?

Decide what to do with the "Keyboard" resource (I think it should become a preference)

Is this wrt GResourceFindString("Keyboard") - or what in particular?

iterumllc · 2021-10-09T05:02:55Z

Is this just wrt what gets set in CMakeLists.txT?

I think it's in BuildUtils.cmake but yes.

I guess this is pretty simple; it seems like there are three levels: We might think there's a font that makes FontForge look nice and/or go with the project's "branding", which would presumably go up front. Next we probably want a font with reasonably good Unicode coverage that ships with the system, and is therefore likely different for Mac, Windows, and Linux. That's the research part of the problem. Then we might want to add some flavor of unifont and encourage its installation. (Probably either an outline version or OpenType-wrapped bitmaps, as those seem to be the only bitmap format working reliably now).

It's also possible that the project would prefer a different font for menus and dialogs and such compared with glyph labels. That would be easy enough to change in the standard theme.

Is this wrt GResourceFindString("Keyboard") - or what in particular?

Yeah, it doesn't really fit in with "appearance" and (in my view) the reasons it got lumped in with the X Resource framework don't apply anymore. (There's no reason that a theme you choose for FontForge should set it, for example). It should become a preference.

skef · 2021-10-09T05:07:35Z

Font-wise I suppose we can also punt the decision and add a version of the old choices as defaults. However, some of those choices just don't seem to make sense now, so even a few hours of research or asking for input on fontforge-users seems preferable.

ascender and descender

skef · 2022-01-20T09:20:28Z

I think even if there are holes in my approach it's on the way to a better solution, so yeah, I'm not inclined to pursue further fixes for now but also not inclined to revert that work (assuming that's permissible).

I've worked through the rebase problems without squashing and am currently trying to test the askmulti dialog in the rebased version. Once I've done that I'll force-push.

skef · 2022-01-20T09:44:57Z

Ok, I think I have everything put back together post-rebase. Akwardly, with the rebase process most of the changes to gflowbox.c and gsdroll1box.c got rolled in to the initial commit, so you'll have to look at them there if you want to.

lastmi is initialised after GMenuBarFit is called

jtanx · 2022-01-20T10:16:36Z

Alright, I've pushed my changes. I looked further into the menu patches you made and yeah they're fine, I fixed that issue I talked about with 2fb3480.

With that I think we're good to merge.

ghost · 2022-01-20T15:04:30Z

@jtanx @skef, thanks!

The only suggestion here — there should be one more change in "About" dialog:

"About" dialog (canvas) BG color should follow "View > Bakground" color;
"About" dialog (text, version number, etc.) FG color should follow "Font View > Glyph FG Color".

Here is screenshot of FontForge-2022-01-20-0be7ca8-x86_64.AppImage with myself modified @ASIDEdesignlab's "zDarkTheme":

skef · 2022-01-20T18:26:57Z

@Symbian9 Unfortunately I doubt there is going to be a sophisticated hierarchy of color settings analogous to what has been added for UI fonts. Theme designers are just going to have to go through and change the settings themselves. That said, those colors should be settable with Fontforge.Splash.Foreground and Fontforge.Splash.Background or in the Splash Screen tab of the Appearance dialog. If one of those doesn't work let me know and I'll take a look.

skef · 2022-01-20T18:35:58Z

If you or any theme designer wants help tracking down settings open a "Discussion" in this repo and I'll try to help you.

Finii · 2022-01-21T07:33:10Z

This breaks fontforge if not used with dark theme:

Already the first commit does it:

$ cd build
$ git checkout 22e86b7e7c
$ git cherry-pick 78915690b35
$ rm -Rf * && cmake -GNinja ..
$ ninja
$ bin/fontforge ~/Downloads/ttf-iosevka-11.2.3/iosevka-bold.ttf

jtanx · 2022-01-21T07:48:53Z

Running straight from the bin folder in the build directory doesn't have the theme files in the right place unless if you manually copy them into the right place.

If you ran ninja install and ran that, everything would work ok. So that is more of a dev inconvenience, but I guess for that alone it might be nice choosing a less-inconvenient default

Finii · 2022-01-21T07:51:05Z

The default defaults seem to be wrong...

Did

mv ~.config/fontforge{,_}

And get still the same black background with black text/glyphs.

It does work after I changed the global background color

But changing it there does not change the background for already open windows ;-)

Trying the install step now, thank you 👍

jtanx · 2022-01-21T07:54:40Z

From your screenshot alone I can tell it's not loading any theme.

The default preferences expect the theme to be in the share folder. For local dev where I want it to load the default theme, I normally do something like this:

DESTDIR=a ninja install
cp -rP a/<prefix>/share .

Finii · 2022-01-21T08:01:37Z

Your hint with installing into a fake DESTDIR and copying into the build dir works fine!

Thank you!!

Might be worth mentioning in the INSTALL.md.

Finii · 2022-01-21T08:13:34Z

And/or here in the cmake for fontforge quickstart.

Appearance (X resource) unification

u2fly · 2024-08-23T19:33:02Z

@ASIDEdesignlab's "zDarkTheme"

This dark theme is unavailable now, but here is a backup:
zDarkTheme-main@ASIDEdesignlab.zip

Archived project page: http://web.archive.org/web/20220309004744/https://github.com/ASIDEdesignlab/zDarkTheme

Author's post on Dribbble: https://dribbble.com/shots/15935800-zDarkTheme-FontForge-Theme

jtanx reviewed Apr 14, 2021

View reviewed changes

inc/fontforge-config.h.in Outdated Show resolved Hide resolved

jtanx reviewed Apr 14, 2021

View reviewed changes

gdraw/gtextinfo.c Outdated Show resolved Hide resolved

jtanx reviewed Apr 14, 2021

View reviewed changes

skef mentioned this pull request Apr 19, 2021

Make sure FontForge can cleanly convert bitmap fonts to OT Bitmap format #4711

Open

skef mentioned this pull request Apr 28, 2021

Question about fontforge GUI icons #4715

Closed

skef mentioned this pull request Sep 8, 2021

Fontforge windows version display UI font doesn't have all unicode characters. #4804

Closed

skef mentioned this pull request Sep 25, 2021

Can not change FG color of non-selected characters in main view #4819

Closed

8 tasks

jtanx force-pushed the res3 branch from db2ed20 to 3c0d2da Compare October 5, 2021 02:07

jtanx reviewed Oct 9, 2021

View reviewed changes

gdraw/gresource.c Show resolved Hide resolved

jtanx reviewed Oct 9, 2021

View reviewed changes

jtanx self-assigned this Oct 9, 2021

skef added 5 commits January 20, 2022 00:58

Even out menu bar text

f97f63b

Calculate menubar height in more appropriate place, store

323b632

ascender and descender

Fix menu lines

7c8b5c1

Revert top-level Mac OS X UI font to system-ui

a9b29fa

Fix mis-lranslated initialization parameters

b698e10

Fix some rebasing errors

7891569

skef force-pushed the res3 branch from 641da06 to 7891569 Compare January 20, 2022 09:39

jtanx added 2 commits January 20, 2022 17:45

Iterate over all menu items, not last visible

2fb3480

lastmi is initialised after GMenuBarFit is called

gdraw: fix computation of text bounds ascent/descent

f8bff5f

jtanx merged commit 0be7ca8 into fontforge:master Jan 20, 2022

ctrlcctrlv mentioned this pull request Jan 27, 2022

2021–2022 release #4840

Closed

This was referenced Feb 5, 2022

Choose a better default background color when no theme is present #4909

Merged

Segfault opening bitmap view #4910

Closed

Omnikron13 pushed a commit to Omnikron13/fontforge that referenced this pull request May 31, 2022

Merge pull request fontforge#4704 from skef/res3

ede2461

Appearance (X resource) unification

skef mentioned this pull request Jan 2, 2024

Windows build needs verification #5336

Closed

4 tasks

This was referenced Apr 13, 2025

Use default resource for Windows build fontforge/fontforgebuilds#3

Closed

Use default resource for Windows build jtanx/fontforgebuilds#25

Merged

Appearance (X resource) unification #4704

Appearance (X resource) unification #4704

Uh oh!

Conversation

skef commented Apr 14, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ctrlcctrlv commented Apr 14, 2021

Uh oh!

lgtm-com bot commented Apr 14, 2021

Uh oh!

Uh oh!

Uh oh!

jtanx left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

skef commented Apr 14, 2021

Uh oh!

skef commented Apr 14, 2021

Uh oh!

jtanx commented Apr 14, 2021

Uh oh!

skef commented Apr 14, 2021

Uh oh!

skef commented Apr 14, 2021

Uh oh!

skef commented Apr 15, 2021

Uh oh!

skef commented Apr 15, 2021

Uh oh!

ctrlcctrlv commented Apr 18, 2021

Uh oh!

ctrlcctrlv commented May 30, 2021

Uh oh!

skef commented May 30, 2021

Uh oh!

ctrlcctrlv commented May 30, 2021

Uh oh!

ghost commented Sep 28, 2021

Uh oh!

jtanx commented Oct 5, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jtanx commented Oct 9, 2021

Uh oh!

iterumllc commented Oct 9, 2021

Uh oh!

skef commented Oct 9, 2021

Uh oh!

skef commented Jan 20, 2022

Uh oh!

skef commented Jan 20, 2022

Uh oh!

jtanx commented Jan 20, 2022

Uh oh!

ghost commented Jan 20, 2022 • edited by ghost Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

skef commented Jan 20, 2022

Uh oh!

skef commented Jan 20, 2022

Uh oh!

Finii commented Jan 21, 2022

skef commented Apr 14, 2021 •

edited

Loading

ghost commented Jan 20, 2022 •

edited by ghost

Loading