mutatorMath.log – Missing Unicode
Closed this issue · 13 comments
I wonder if it would make sense to constrain the “missing Unicode” message to non-suffixed glyph names only?
Missing unicodes for 454 glyphs:
.notdef
A.sc
A.sups
AE.sc
Aacute.sc
Abreve.sc
Abreveacute.sc
The test for a glyph name extension could happen here..
Only report glyphs without unicodes if there is no extension and the glyph is not .notdef.
Just wondering: why does mutatorMath warn about missing Unicode mappings to begin with?
If the glyphs in the masters have unicode values, users tend to expect that generated instances have them as well. If all masters agree on the same value it is not a problem. So MutatorMath has to do some validation to pick the right value, for instance some masters don't have a unicode value, or different ones. What to expect with, for instance, three masters without unicode, and one with?
I suppose it could warn only when there are conflicts.
I suppose it could warn only when there are conflicts.
Yeah, that sounds better to me.
I want to bring this back up -- these messages are generally unhelpful for us and even detrimental as they flood fontmake output with spurious "missing unicode" messages. However, it is helpful to have some output from MutatorMath.
My concerns come from running fontmake on Travis CI, where we can either time out due to >10m silence (so we do want some MM output), or go over the output limit (so we don't want too much MM output).
It would be great if either there were more tiers for verbosity, or MM only warned on conflicts.
@LettError what about using the master that has <info copy="1" /> as the driver for Unicode assignment/propagation? It may be seen as pouching the setting, and it doesn't solve the case wherein none of the masters carry that setting, but perhaps would allow you to avoid having to deal with the conflict shenanigans.
Verbosity: understood.
Info element : should there be a more explicit assignment of the default font? Could be an attribute in the source element.
Erik
On 17 Nov 2016, at 09:32, Miguel Sousa notifications@github.com wrote:
@LettError what about using the master that has as the driver for Unicode assignment? It may be seen as pouching the setting, and it doesn't solve the case wherein none of the masters carry that setting, but perhaps would allow you to avoid having to deal with the conflict shenanigans.
―
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
Ah, sorry to be bothersome, but I noticed you removed the "Writing [name] to..." messages printed during interpolation in addition to the missing unicode warnings. As I noted before we do need some output or Travis will time out due to a perceived lack of activity. Anyways MutatorMath does tend to take a long time to run so I think it's reasonable to have an info statement printed for each written instance.
Alright, I added some logging to test.py, reading and writing files, generating instances. tbh, I'm not really sure how to read the travis results. I get the impression it spends most of time installing and preparing the environment. The tests themselves do run rather quick.
Alright, I added some logging to test.py, reading and writing files, generating instances.
Thank you!
tbh, I'm not really sure how to read the travis results. I get the impression it spends most of time installing and preparing the environment. The tests themselves do run rather quick.
We may be talking about different Travis results. I was concerned with noto-source's Travis build, in which MutatorMath can take upwards of 30 minutes to run on our larger fonts.
(Reopened this issue, so I can find it)
@jamesgk Travis: I thought you meant the test of this code, did not think of Noto :)
Can I close this?