Introducing TruFont

Posted Apr 29, 2016 5:48 UTC (Fri) by liam (guest, #84133)
Parent article: Introducing TruFont

I'm glad this is finally happening. The FontForge situation doesn't seem amenable without a significant increase of resources.
Regarding Qt and Python, I've Read™ that combination can be difficult to wrangle, especially, but not exclusively, on Windows. Has this been encountered?

https://lists.fedoraproject.org/archives/list/desktop@lis...

Introducing TruFont

Posted Apr 29, 2016 7:52 UTC (Fri) by halla (subscriber, #14185) [Link] (5 responses)

If it were really difficult, it wouldn't be the toolset of choice for some really big, important cross-platform applications like Mari. Python + Qt has been a great combination for cross-platform development ever since I wrote the first book on the topic, in 2002.

Introducing TruFont

Posted Apr 29, 2016 21:59 UTC (Fri) by lsl (subscriber, #86508) [Link] (4 responses)

Not if you want to use a free toolchain. As it seems, you can't build upstream python for Windows using GCC/MinGW. That also rules out cross compilation.

Losing the ability to cross compile for Windows is pretty awful if you want to hand out Windows binaries. Especially when thinking of the awesome collection of MinGW-built open source libraries available in Fedora in nicely pre-packaged form.

Introducing TruFont

Posted Apr 29, 2016 22:00 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

You can compile MSVC-compatible binaries with CLang, including cross-compilation.

Introducing TruFont

Posted Apr 30, 2016 6:58 UTC (Sat) by halla (subscriber, #14185) [Link] (2 responses)

"seems"? Do you have a link somewhere that makes that a bit more certain?

In any case, making binaries on windows is perfectly possible, been there, done that. These days I use MXE to cross-compile almost all dependencies for Krita, and then cross-compile Krita, too, but that's only because one or two libraries we depend on cannot be built with msvc.

(And why did we start doing our Windows builds on Windows? Well, mostly to force myself to use Windows now and then: if you want to publish software for a platform, you'd better know how to use that platform.)

Introducing TruFont

Posted Apr 30, 2016 13:17 UTC (Sat) by lsl (subscriber, #86508) [Link] (1 responses)

CPython upstream only supports Windows builds with MSVC. There's a gigantic patch set on Github to make it work with MinGW[1].

It's all in the link given by liam (to which you replied, so I thought you've seen that). A more specific account of the problems involved can be gained from the FESCo meeting logs[2], starting at 18:13:07.

The inability to cross-compile python from source using a Free Software toolchain means that the next Fedora release won't come with an official Live Media Creator for Windows. Incorporating such huge patch sets with no chance of upstream acceptance is obviously not acceptable to Fedora.

[1] https://github.com/Alexpux/MINGW-packages/tree/master/min...
[2] https://meetbot.fedoraproject.org/fedora-meeting/2016-04-...

Introducing TruFont

Posted May 23, 2016 13:55 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

> CPython upstream only supports Windows builds with MSVC.

Even worse, the version of MSVC is dictated too. Importing into newer versions fail spectacularly. For example, Python2 is either MSVC 2008 or roll your own (there are CMake buildsystems out there to be able to build for other compilers, but no one has made them on feature parity with upstream AFAIK).

Introducing TruFont

Posted Apr 29, 2016 15:34 UTC (Fri) by davelab6 (guest, #86237) [Link] (1 responses)

Liam, I think you would be ASTONISHED to learn how much money I've poured into FontForge in the last 4 years. Increasing the resources won't make a difference.

Introducing TruFont

Posted Apr 30, 2016 2:49 UTC (Sat) by liam (guest, #84133) [Link]

I wasn't trying to bash the efforts of the developers, only expressing my assessment of the situation.
What I was expecting (perhaps wrongly but nevertheless) was that the font manipulation functions would be disentangled from the ad-hoc widget toolkit and turned into well factored libraries. This would then make it much easier to move it to another toolkit (which I thought was the long-term goal) and allow the font libraries to be developed by the community separately.
However, that this, or whatever the goal you had in mind, wasn't something that could be accomplished given the resources doesn't imply, to me, that MORE resources wouldn't have solved the problem (even if part of the problem includes a fork).
Of course, the amount of work that might've required might be better used to just rewrite the whole damn thing:)