FS#39681 - [fontforge] Unbreaking fontforge 20140101-1 by adding zeromq and libunicodenames

Attached to Project: Arch Linux
Opened by Vorbote (vorbote) - Saturday, 29 March 2014, 17:48 GMT
Last edited by Gaetan Bisson (vesath) - Monday, 31 March 2014, 07:34 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Gaetan Bisson (vesath)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No



Fontforge 2.0.20140101 as compiled in extra is broken. It needs both to link to a unicode names translation library and to a socket messaging system library (zeromq).

Steps to reproduce:

* Try to open fontforge using its f.d.o desktop file. It fails.

* Try to open a font file using fontforge's mimetype associations in a file manager. It fails.

* Open fontforge from a terminal emulator and see a bunch of arcane error messages.


* Compile fontforge with zeromq, It should be detected automatically but the release package has some misconfigurations. It needs to be set explicitly using internal environment variables supplied by the package at configuration time. Fixed in trunk AFAIK.

* Compile fontforge with a unicode codepoint to names mapping library. This will have to be moved from AUR to extra (but it is very small and stable). There are two libraries fontforge can use. The preferred one is libunicodenames, which is actively maintained.

Please find attached the changes proposed to the PKGBUILD.
This task depends upon

Closed by  Gaetan Bisson (vesath)
Monday, 31 March 2014, 07:34 GMT
Reason for closing:  Implemented
Additional comments about closing:  fontforge-20140101-2 in [extra]
Comment by zless (roentgen) - Saturday, 29 March 2014, 18:35 GMT
It works fine here.

I don't have libunicodenames (AUR package) and I just uninstalled zeromq to test.

Maybe it's best to post the error messages.
Comment by Vorbote (vorbote) - Saturday, 29 March 2014, 19:00 GMT
Some comments:

1. The ability to map unicode codepoint numbers to names is vital when you are working with fonts that are not in the Latin1 plane. I do.

As I guess I bear the onus of proof that I know my way around font editors, here is some of my past work: <http://ctan.org/pkg/oztex-fonts> I have other things floating around the net, such as Courier 15 CPI.

2. ZeroMQ is what makes fontforge behave correctly under a desktop environment, so I take it you don't use one?

3. I can't reproduce the error messages anymore so that might have been something spurious due to old configuration files in my home directory that I deleted while researching this.
Comment by Gaetan Bisson (vesath) - Saturday, 29 March 2014, 19:21 GMT
No problem regarding libunicodenames; I'll add it.

Regarding zeromq, however, I fail to understand how making it a dependency would fix the desktop file and mimetype association issues. Could you elaborate on that?
Comment by Vorbote (vorbote) - Saturday, 29 March 2014, 20:42 GMT
I'll be! It seems my problems were due to old preferences corruption. I've just recompiled without zeromq and it is working as it should. I'd certainly appreciate if you add libunicodenames; it is very useful.

The zeromq dependency is for collaborative development over the network, something attractive to people in a design or type shop. I thought at first that there was a bug in the source causing a hard dependency. See [1] and [2] for how this feature works.

[1] https://github.com/fontforge/fontforge/pull/379
[2] https://speakerdeck.com/davelab6/lgm-2013-zeromq-and-real-time-collaborative-font-design