UPDATE – this 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.
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 ?)