Handling production names based workflow

[bobh0303]

The process() function modifies a file, in effect, "in place" (though presumably by copying the file off and then executing the cmd on that copy). While this is clever in many situations, it can also cause problems.

Perhaps there is a different way to program what I'm trying to do -- in which case please let me know. But here is what I'm experiencing:

We have a workflow that utilizes working glyph names up until the font is nearly done, then we rename everything to AGL names using psfix:

font(target = process('myfont.ttf', cmd('perl psfix ${DEP} ${TGT}'), name('My Font Name') ),
    source = ...
    ...

After a smith clean I can do a smith build and the above works perfectly ... once. If I, for example, tweak my graphite source and try another smith build I get build failure because of a load of undefined glyph and class names

I believe the problem is that smith is trying to compile the new code against the old result font -- but that font now has different (i.e. AGL) glyph names.

An easy work around is to always do a make clean before trying a smith build, but that counteracts all the clever things smith does to not have to rebuild everything each time.

[mhosken]

Dear Bob,

The process() function modifies a file, in effect, "in place" (though presumably by copying the file off and then executing the cmd on that copy). While this is clever in many situations, it can also cause problems.

[snip]

I believe the problem is that smith is trying to compile the new code against the old result font -- but that font now has different (i.e. AGL) glyph names.

An easy work around is to always do a make clean before trying a smith build, but that counteracts all the clever things smith does to not have to rebuild everything each time.

Yes. This is an unstated (due to oversight) presupposition that all processes that work on a font can be executed against an output font. I suppose we could add a flag into the cmd() that would say: this is not a reprocessable function and you therefore have to build the font from scratch every time. Do you want to go there with this, or can you make psfix perhaps just go: oh look I have no work to do, I'll just shut up and exit nicely?

I'm sure you are trying to have psfix flag all the glyphs you forgot to add mappings for. In that case, you could test to see whether a glyph has the name of the right hand side of a mapping and ignore that (or check that only one glyph has that name if you want to capture 2 glyphs one named the lhs and one the rhs as being an error).

Sorry smith isn't as perceptive as we might like.

GB, Martin

[bobh0303]

Thanks, Martin, for your quick reply.

Do you want to go there with this, or can you make psfix perhaps just go: oh look I have no work to do, I'll just shut up and exit nicely?

The problem isn't that psfix is failing. The problem is that the grcompile fails because master.gdl references glyph identifiers that no longer exist in the font.

Example:

master.gdl includes this line:

        absShadda  cShaddaKasraMarks  >  _  cShaddaKasraLigatures:(1 2);

The first time through smith build, the font has a glyph called absShadda which is seen in results\Lateef-Regular.gdl:

absShadda = glyphid(914) {diaAS = point(153m, 1390m); diaAM = point(153m, 1048m)};

but the next time that glyph has a different identifier:

g0651 = glyphid(914) {diaAS = point(153m, 1390m); diaAM = point(153m, 1048m)};

so the compile fails.

[mhosken]

Both Graphite and OpenType builds are affected by this. In fact, FEA based OpenType is more affected, since gdl can be gid() based and not actually query the postscript names in the font it is building. In addition, when testing, we would like the test results to be in terms of development glyph names rather than final glyph names. For that we will need a map.

Given we need a map. There is nothing to stop us feeding that map to the compiler. Notice that use of a map during fea compilation does not require its use for building a standalone font using some other tool based purely on features.fea. The tricky part is knowing when to apply the map and only the compiler can work that out. For example, a clean build would not need the map but a rebuild would.

An alternative processing model just says: hey rebuild everything from scratch every time. But that doesn't help the testing, for which we would need a map anyway.

[bobh0303]

FTLS-386

[bobh0303]

An alternative is to implement --norename option in wscript (to disable the glyph renaming) so that, for development and testing purposes, the project team can build and re-build without doing a smith clean between each. Harmattan and Scheherazade have this implemented (along with some other wscript options).

(Lateef, as it is still early in development, has the opposite default (to not rename) but supports --rename to request renaming. Eventually this will be changed)