Robofab, UFO3, python3

[Erik van Blokland]

Folks,

in light of the recent work of porting the current robofab trunk to Python3, this might be a good time to discuss some of our plans for the next version of robofab.

- a new implementation of the "NoneLab" robofab objects
- based on the ufo3 branch of defcon and the ufoLib module from the ufo3k branch of robofab.
- ufoLib should perhaps become its own repository on github (so independent of robofab)
- this new robofab would be able to read, write and work with ufo2 and ufo3 data.
- keep all existing scripts running, but add (ufo3) functionality.
- maybe also patch in Frederik's boolean modules.

FontLab6 will have its own, native, robofab-like objects, so that relieves robofab of providing that service. That means we can move away from a some old implementation problems.

Big note: none of us have budgeted any time (or money) for this project yet, and we have other libraries, apps, fonts and lessons to work on. So this is not a promise. However, I think this would be the right direction.

Please discuss.

Thanks for your continuing support,

Erik, Frederik, Tal

[Adam Twardoch (List)]

Erik,

I know that there's still a large user community and many projects sticking with Python 2.7 or trying to provide Py 2.7 + 3 compatibility. I myself haven't moved to Py 3, though perhaps it is time.

I have no opinion myself, so what's your (& others') view:

1. Will RFab be Python 3-only? (I.e. dropping 2.7?)
2. Is Supol and RFont moving to Python 3?

I would appreciate your insight and advice. For FontLab VI, we still can make a choice.

A.

Sent from my mobile phone.

> --
> --
> You received this message because you are subscribed to the Google Groups "RoboFab" group.
> To post to this group, send email to rob...@googlegroups.com
> To unsubscribe from this group, send email to robofab-u...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/robofab?hl=en
>
> Messages from newly joined members are subject to moderation.
> Download RoboFab and documentation at http://robofab.com
> ---
> You received this message because you are subscribed to the Google Groups "RoboFab" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to robofab+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Erik van Blokland]

Adam,

we're absolutely not dropping support for 2.7, I'm sorry if the post gave you this impression. I don't know of any font apps that have made the jump to py3.

My point was that if someone wants to make an effort to port robofab to py3 (even if not many apps use it, someone might need it), it might be a better investment of time to port a new ufo3 ready project, not the old one.

On 28 sep. 2014, at 16:16, Adam Twardoch (List) <list...@twardoch.com> wrote:

> I know that there's still a large user community and many projects sticking with Python 2.7 or trying to provide Py 2.7 + 3 compatibility. I myself haven't moved to Py 3, though perhaps it is time.
>
> I have no opinion myself, so what's your (& others') view:
>
> 1. Will RFab be Python 3-only? (I.e. dropping 2.7?)

No.

> 2. Is Supol and RFont moving to Python 3?

No.

> I would appreciate your insight and advice. For FontLab VI, we still can make a choice.

I think it is great the language developers want to clean things up and I will not second guess Guido's decisions. But at the same time, these changes cause so much code to break (and not just ours, but *all* scripts and systems *everyone* has built with robofab). Given the way python is used in the type community the long term advantages of py3 appear very distant and far removed from the very practical reasons why we need python in our tools in the first place.

"Why is my code broken?"
"Someone at Python central thinks it is better this way"
"Oh."

I think we probably have to start this discussion at some point (maybe Robothon?), but I am not at all sure about the outcome.

Superpol and RoboFont will move to UFO3 soon. Not Python3. Also 3, but a different 3.

Erik

[Adam Twardoch (List)]

Ah, thanks! :)

Sent from my mobile phone.

[Tal Leming]

Hi Everyone,

A quick follow up and elaboration...

I started a UFO 3 version of the existing RoboFab before the last Robothon. I got pretty deep into it but it was overwhelming. The idea of RoboFab is as relevant as ever, if not more so, but the code is…old. Most of it is over ten years old. The parts that I wrote, especially the early stuff that I wrote wrapping the FontLab Python API into the RoboFab API is extremely brittle. Consequently, we have been slow to fix minor issues because we’re afraid that the minor fixes will cause major problems. Plus there is ten years of cruft, legacy support, etc. It is not a fun thing to work on. We need to make a change if we are going to be able to maintain it without going crazy.

I broke the ufoLib code into a separate subpackage when I started the UFO 3 work. That handles UFO 1-3 and the code is independent, clean, well-tested, documented and as modern as it can be. Thus, Erik’s suggestion to move it away from RoboFab is a good one.

As for implementing UFO 3 in the RoboFab objects, I’m in agreement with Erik. defcon can handle UFO 3, as can fontMath and other things that would be needed for RoboFab support. There are a few ways that we can approach this, but I think the best may be for RoboFab to explicitly define an API. It is already doing this implicitly but it isn’t documented very well. This API could then be implemented by the various editors and RoboFab itself wouldn’t be responsible for maintaining those implementations. All RoboFab would implement for UFO 3 and forward would be NoneLab. The API would be exactly as it is now with additions and modifications to support UFO 3. Your existing scripts would continue to work.

I’m confident that this approach would be significantly easier than trying to bend the existing RoboFab to fit UFO 3. The real issue for us is time. It’s a non-trivial amount of work and we have other responsibilities. It’s on our to do lists, but no promises.

Tal

[Adrien Tétar]

So how does Robofab play out with ufo3? Can the ufo3 branch be used readily by external software?

Staying on ufo2 branch means no support for things like multi-layer in ufos right? I was under the impression that some tools incl. fdk seem to use ufo2 with multilayer. How would you do this with robofab ufo2 assuming the ufo3 branch isn't polished for general use in the first place?

Adrien Tétar