Explore related tutorials & articles
17
Replies
of course, I should have guessed there was a story 
can't you check if you have threaded items before duplicating? then if so, thread them back right after duplicating?
Yea that's what the 'overkill' code does 
Well, to elaborate: (and you just had to go there 
) - there's a 'issue' with threaded frames in Illustrator similar to how there's an 'issue' with the polarity of a path acting a little 'weird'... ( from that other topic on here ).
In this case, when you think you can just walk through all the text frames in a group and find all threaded ones by using the "previousFrame" and "nextFrame" - and you think it's going to work like normal - that's when it doesn't.
The failure in this case is there's an 'infinite link' between the threaded textframes as far as scripting is concerned, so whereas a regular person may assume the very first text frame has a previousFrame of null, no it actually points right back to the last text frame.
[EDIT] - Per Uwe the previousFrame indeed does return null! It's the nextFrame which is problematic.
As these text frames can be in different stacking order - and in fact, in different sub-groups of the group, it's not acceptable to assume a rigid order within these kinds of usages I'm looking at.. so the bottom line is we have to go by stories.
Stories don't lie. They have only a limited amount of textFrames, and there's one with an index of beginning and one of the end.
So while stories allow you to get a survey of all threaded text frames (stories whose textFrames are more than just the one) and isolate some into a trackable piece of data in memory, the duplication of art from one document to another means having to find those textFrames all over again.
To me it was an alternative between some code creating and returning some kind of node-tree as a set of instructions for re-threading, and what seems to be the more generic option of using tags. This way the items can be in any different place, and the re-threading function can still weave the separate items together based on sorting the text frames via their tag content.
Of course it's stuff like this that may help some super awesome project be saved from death for somebody out there, and I wish them well
But as for me, as much as I love Illustrator and scripting trivia, believe it or not - I never actually anticipated that this would be the case.. because I simply expected the stuff to work a 'normal' way. But here we are, as you can see... I didn't choose the thug life; it chose me!
Laubender wrote
… I'd consider this as bug!
Hm. I was wrong, there is no bug.
If I test the first text frame in a story with:
app.selection[0].previousFrame
or:
app.activeDocument.stories[0].textFrames[0].previousFrame
it returns indeed null.
Tested with my German Illustrator CC 2019 version 23.0.2 on Windows 10.
Regards,
Uwe
Hi Silly-V ,
interesting!
So something like the code below should work if we do not care about stacking order:
var sourceDoc = app.documents.getByName("Source.ai");
var targetDoc = app.documents.getByName("Target.ai");
var sourceStory = sourceDoc.stories[0];
var sourceFrames = sourceStory.textFrames;
var currentFrame = sourceFrames[0].duplicate( targetDoc , ElementPlacement.INSIDE );
for( var n=1; n<sourceFrames.length; n++ )
{
var dup = sourceFrames
.duplicate( targetDoc , ElementPlacement.INSIDE ); currentFrame.nextFrame = dup;
// Redifining currentFrame:
currentFrame = dup;
};
Big Question: Where did you look up the enumerator ElementPlacement.INSIDE ?
Searched the DOM documentation and couldn't find it. In the OMV the link from ElemenentPlacement to a specific discription did not work.
Fun fact: In my tests I was able to do two threaded text frames where the last frame in the story was threaded to the first one so this all became circular.
This happened accidently. Now I can recreate it.
Two threaded frames of a story in the document.
Nothing unusual for now:
Run this snippet code:
var story = app.activeDocument.stories[0];
story.textFrames[1].nextFrame = story.textFrames[0];
Result:
EDIT: Or even more absurd would be:
var story = app.activeDocument.stories[0];
story.textFrames[ story.textFrames.length-1 ].nextFrame = story.textFrames[ story.textFrames.length-1 ].nextFrame;
But that yields the same result.
Regards,
Uwe
Or see into this case.
Two threaded text frames.
Yellow text on the left > Cyan text on the right
With both texts I applied effect Multiply.
Running:
var story = app.activeDocument.stories[0];
story.textFrames[ story.textFrames.length-1 ].nextFrame =
story.textFrames[ story.textFrames.length-1 ].nextFrame;
Result:
Overlapping text rendering in the left frame.
But this special kind of text rendering will not travel well to an exported PDF/X4:
Regards,
Uwe
AdChoices