omniJS – Copy As > JS chokes on mixed font sizes?

UPDATEthis turned out to be a misunderstanding of some kind of transient condition, which hasn’t recurred since.

If a shape contains more than one font size, Copy As > JS appears to fail – emitting no code for text, geometry, line, fill etc,
and generating only code which creates just a tiny (effectively invisible) shape at the canvas origin.

( OmniGraffle 7.5 test v181.3 r294205 built Aug 18 2017 )

Having closed and reopened the document, I can no longer immediately reproduce this.

Is the Javascript context of the document that is seen by the Automation Console directly involved in the Edit > Copy As > JavaScript code ?

I was drafting and testing shapetext-reading scripts at the time, and I wonder if I stumbled into creating a namespace clash that somehow choked some element of the Copy AS JS process ?

My habit is to enclose script code in a module wrapper, to localize all name-bindings, but I’m certainly guilty of simply binding names in the global name space when I’m using the Console.

(And I guess users may be quite likely to do that generally - the code examples on omni-automation.com, for example, are all binding names in the global namespace (they are all unwrapped by anything like the ‘module’ closure (an immediately-invoked anonymous function) below :

(function () {
  
    //... local function and (const | let | var) declarations
})();

(Hard to reconstruct, because the famously crowded JS global context is reset once a document has been closed and reopened)

(I guess another possibility is that something arose at the line break, rather than at the font size change, and that an anomalous line-break in the live document was normalised by the save to file ?)