Why not base psfbuildcomp on GlyphConstruction?

[madig]

More a question than an issue, but why did you build psfbuildcomp separately from https://github.com/typemytype/GlyphConstruction?

[jvgaultney]

When we were discussing a new composite building tool back in 2014-2015, GlyphConstruction had some severe limitations, wasn't evolving, wasn't really documented, and was so Robofont-focused at the time that we couldn't reasonably extend the syntax without also rewriting the one and only interpreter (the RF extension). We also wanted to write other interpreters and had no need to support a few GC syntax elements (or thought they were poorly designed in GC).

However we did want to adopt a syntax that shared most of the elements of GC/Robofont so that most basic definition files would work in either, but was also extensible and easy to learn for those familiar with GC. We also wanted any unsupported GC syntax (that was in that spec at the time) to be elegantly ignored. So we wrote a more formal, documented syntax and tool for our internal use, which eventually made it into pysilfont (psfbuildcomp).

I haven't kept up to date with GC in the last 2 years, but I think the core syntax of both tools remains the same, with differences being our [key=value] extensions, things we still do not support, things added to GC since 2015. The most important extension to us is [with=AP].

We'd be very interested in discussing how we could unify the two syntaxes, esp. now that we have migrated to a UFO (but not Robofont) workflow. Proposals welcome!

[madig]

The main reason I ask is because FL5's alias.dat file is severely limited and Glyph's construction/alignment automatisms have tripped us up a few times when we wanted to use different applications with the generated UFOs. FL6 is supposed to have better construction syntax for stuff but it has no real UI yet.

I'm not sure if my store-this-in-UFOs-question over at unified-font-object/ufo-spec#71 goes anywhere, so I'm toying with the idea of generating and checking stuff with something like psfbuildcomp. The checking stuff is important, because only Glyphs really enforces that components snap to anchors, unless like in our case, you turn that off... and designers often complain how tedious it is to ensure that they didn't accidentally move some component somewhere or the cross-hair was off by 1 font unit and stuff like that.

@typemytype thoughts on a kind of "glyphConstructionLib"?
@twardoch maybe even something FL6 could use?

[jvgaultney]

If there was a glyphConstructionLib that would work directly on a UFO, and also supported our extensions or something equally capable, then we'd strongly consider switching our workflow to use it. We would very much welcome an enhanced GC and love to see it integrated everywhere, but it does need to do things GC can't do, as in explicitly naming anchors to use that may not follow the anchor,_anchor traditional pairing.

[gferreira]

GlyphConstruction is already available as a lib – see glyphConstruction.py

from fontParts.world import RFont
from glyphConstruction import ParseGlyphConstructionListFromString, GlyphConstructionBuilder

txt = '''\
agrave = a + grave@center,top
aacute = a + acute@center,top
'''
constructions = ParseGlyphConstructionListFromString(txt)

ufoPath = '/Users/gferreira/Desktop/test.ufo'
font = RFont(ufoPath)

for construction in constructions:
    constructionGlyph = GlyphConstructionBuilder(construction, font)
    glyph = font.newGlyph(constructionGlyph.name)
    constructionGlyph.draw(glyph.getPen())
    glyph.name = constructionGlyph.name
    glyph.unicode = constructionGlyph.unicode
    glyph.note = constructionGlyph.note
    glyph.markColor = constructionGlyph.mark
    glyph.width = constructionGlyph.width

font.save()

[madig]

It would need to be rewritten to use defcon or ufoLib2 instead of Robofab.

[typemytype]

what parts needs to be rewritten?

Gustavo's example shows GlyphConstruction with a fontParts objects, and it can easily be replace with defcon objects as GlyphConstruction only uses a shallow glyph like object and pens to draw.

and ... RoboFab does not exists anymore.

and what is ufoLib2?

[madig]

Oops! Sorry, I overlooked fontParts and just saw RFont.

fonttools/fonttools#1270

[jvgaultney]

Very glad to see that it now uses fontParts, and that certainly makes it more attractive to us. The main philosophical difference is that we always use explicit anchors, as calculated values like 'center' are pretty useless even in the Latin script (acute?). The GC syntax seems to support named anchors, but I can't find any examples of that use, and we need to also occasionally match up pairs of anchors that are not named with the AP,_AP convention.

[typemytype]

the fontTools ufoLib2 implementation is still heavy work in process and not compatible with the current implementation, wrong api and lots of things missing, unable to read and write ufo1/2 not really faster, no validation...

@jvgaultney what do you mean by 'it'
GlyphConstruction uses pens/pointPens to create and draw. This is totally independent to fontParts or defcon. It just needs an pen protocol like object to be able to work, could be anything, could also be a drawBot BezierPath.

[jvgaultney]

Sorry - initially thought that a running script such as the example by @gferreira was included in GC. So it seems that we'd need to write something similar, as there is no command line option to take a .glyphConstruction file and apply it to a UFO.

[andyclymer]

@jvgaultney The nice thing is that adding an anchor or a guide named "center" overrides the measured center. Some glyphs you can get by with the actual measured center, but in other cases you would place the optical center (your example of the acute) by adding an anchor and it just works. It's pretty nice!

[jvgaultney]

Ah - that is very nice - didn't know that, and it isn't clear in the docs. Thanks!