Support PC (WIN/LINUX)

[justvanrossum]

Support PC (WIN/LINUX)

[behdad]

@justvanrossum Well I just dislike having a mixed application that uses both Electron and Python 😶.

I dislike that as much as you do. Yet it sounds to me like the best option to move forward. I'd even forgo the Electron part and say just open a window in the browser.

Bonus: we can emscription cpython and run the whole thing as a client-side web app. No one wants to install apps anymore, unless they come from their default package manager, and even then...

@eliheuer’s suggestion (using PyQt) is good for this case.

For above reasons I prefer a web-based solution.

Would have been easier if we were using a JS stack and node.js. But we do what we have to do.

[davelab6]

Only just seeing this. Just and I discussed him doing something more cross platform, but before the tool existed, it was not totally clear what the tool would be, so I agreed with Just's proposal to do something mac only to start, as that was what he was most familiar with and could 'paint a blank canvas' with best.

Meanwhile Raph and friends are working on druid and runebender, and Simon is doing whatever he wants.

Having tried to do web based stuff with Metapolator, I am a bit shy of it, actually. I would recommend FG2 be done with Druid.

[colinmford]

It's easy to tell someone to climb a mountain, but harder to help them do it.

If your request is a serious one, maybe make a suggestion as to where to start, or make a pull request.

[justvanrossum]

How about a web front end using a local Python server, bundled together with something like Electron?

[justvanrossum]

Well, I think I know you don't like Python, so I'm not sure how fruitful a discussion between us will be.

Not that I'm opposed to a full rewrite of FG in JS (or whatever non-Python), it's just that I will not be closely involved in such an effort.

Also, you casually mention "you lost UFO/TTX support though" as if that's not a core feature of the app (together with designspace).

My suggestion comes from an attempt to leverage the existing codebase to the max. That could equally work with a Qt or Wx or GTK port.

I honestly don't think is productive to say "you must support PC" and at the same time "you must throw away all your existing code".

[behdad]

Not the same program by any means, but the most actively developed Linux alternative to this is probably Font Manager.

Except that it's not. Has completely different audience and different goals. The only overlap is that they both work on fonts.

My personal frustration with this effort being Mac-only is this:

For years I've been wanting a tool that takes a font file and produces a report showcasing the font. Think of it as an automatic specimen generator. Not just a glyph table or showing different Lorem ipsum or real text at different sizes. Something that makes you appreciate all aspects of the font, all the finesse. Because I realize that would empower every type designer by making it easy for them to showcase their effort & expertise.

To work towards that goal, I had to build a lot of infrastructure in HarfBuzz. While FontTools provides a lot of the foundation for that, as soon as you want to showcase shaping features, you would need infrastructure from HarfBuzz, because reimplementing all that complexity in FontTools would be a waste of resources and unjustified for the limited use-cases it will address. We just don't have anything like enough resources to do that. Like, we have less than 5%. That is also why I've always been opposed to JS efforts to implement shaping, to LuaTeX implementing shaping, and to any of the Rust shaping efforts that do not fully study and learn from HarfBuzz. This project has acknowledged that decision and uses uharfbuzz to call from Python into HarfBuzz. That is good. Just these past few days we have been building more of that infrastructure that is specifically aimed at this kind of application:

harfbuzz/harfbuzz#2468
harfbuzz/harfbuzz#673

So I've been building the infra, and waiting for someone competent to build the front. At Google I got someone to work on that, but they simply didn't have the font background to be able to pull off the job. Others took HarfBuzz and embedded it in their proprietary solutions. I kept waiting. I encouraged @davelab6 to fund such a project.

And now @davelab6 has managed to fund at least two competent developers. And they are doing the job. And it's Open Source. But the majority of people who cannot afford buying the proprietary solutions cannot use it either.

So to me, this effort is lost, wasted, a distraction. Before people point out that whoever does the work gets to choose what to do. I hear you. I'm not criticizing @justvanrossum personally. Although I wish he would see the world closer to how I see and would prioritize accessibility over other aspects. He can learn and do differently if that is something he chose to do. Let me aim my criticism at @davelab6 and @rsheeter however, for not requiring a cross-platform app with the money they are putting towards what I know is otherwise a great cause.

There is a silver-lining however, and that is why I continue and am very excited (harfbuzz/harfbuzz#2468 (comment)) to finish the HarfBuzz part in collaboration with @simoncozens and others: that the hard part of this project, the tricky logic that needs deep font expertise, is portable in nature. So yes, hire someone to do the frontend, it doesn't have to be @justvanrossum; let @justvanrossum focus on the parts he's best at doing.

[justvanrossum]

Regarding a platform-neutral future for (something like) FontGoggles: yes, a client-side JS app is the best way forward, and yes, it does not have to be me to build that.

It makes sense to see the pure OT viewer separate from the ufo/designspace previewer. I suspect they have quite different (if overlapping) audiences. In other words: ufo/designspace being difficult to support in a JS app should not be a blocker for anyone who wants to start on a JS-based FG-like app.

To me, the primary features of FontGoggles are:

• multiple fonts
• hb text shaping
• view input string as a table of unicode values with properties
• view layout information as a table of glyphs with positioning info (for one selected font only)
• UI for OT variations
• UI for OT features
• UI for script/language

Secondary:

• quick ufo/designspace previewing using partial compile to OT

[eliheuer]

I want to work on a Linux port. @be5invis or anyone else let me know if you want to collaborate on on this. :-)

Using PyQT5 would probably be the easiest way to do this, but I'm open to GTK or whatever.
https://pypi.org/project/PyQt5/

[be5invis]

@justvanrossum I do not like the idea that having a Python server on the backend. If you go Electron you can have Harfbuzz and Freetype compiled to WebAssembly to do the render job — you lost UFO/TTX support though.

[be5invis]

@justvanrossum Well I just dislike having a mixed application that uses both Electron and Python 😶. @eliheuer’s suggestion (using PyQt) is good for this case.

[alerque]

Not the same program by any means, but the most actively developed Linux alternative to this is probably Font Manager.

[behdad]

Type design should not be a Mac-only business.

Same. Sighz...

[behdad]

It's easy to tell someone to climb a mountain, but harder to help them do it.

If your request is a serious one, maybe make a suggestion as to where to start, or make a pull request.

Yet the right words shall not be condemned.

[behdad]

Because it can, but doesn't, push towards leveling the field.

[simoncozens]

Would have been easier if we were using a JS stack and node.js. But we do what we have to do.

Hmmm. Do we have do? We could enscripten Harfbuzz and use opentype.js and ufo.js.

I think the problem here is that there are conflicting desires, based on conflicting use cases. The part of FontGoggles which views/shapes/examines OpenType fonts is actually pretty easy. You could whip that up as a client-side web app pretty quickly. (In fact, I might just do that... - if someone can help me with enscripten and Harfbuzz @khaledhosny?)

The more complex work is the part that compiles designspaces and UFOs on-the-fly. But not everyone needs that. I suspect the people asking for ports are not the people who are looking at that part of the feature set.

So I see two ways forward:

• A web-based OpenType introspection tool, because that's just handy to have anyway.
• A native (Rust UI / Py GTK / whatever) port which handles the more advanced features.

[simoncozens]

I'm not finished, but have a look at this: http://www.corvelsoftware.co.uk/crowbar/

[justvanrossum]

I'm not finished, but have a look at this: http://www.corvelsoftware.co.uk/crowbar/

That's really great! I love it.

[justvanrossum]

What Crowbar also shows to me, is that a small specialized app may be much better than to try to tack such functionality onto FontGoggles. Even in this early stage, what I see in Crowbar makes me happier than what I was fantasizing about for FG. One reason for this is probably the multi-font feature of FG. That makes less sense (if any) for this purpose, and would only get in the way.