textFrames collection
trych opened this issue · 9 comments
Equivalent to the words(), characters(), stories() collection functions, I would like to add a textFrames() collection function that loops through all text frames of a container, as I repeatedly noticed in my classes that such a function is needed, but still missing.
Such a function could return all text frames of a story, all text frames of the doc, but also all text frames of a hyphenated word etc. Also, one thing I would like to add to this would be the possibility to use a text frame as the input container and then have it return all the linked text frames. That would allow for an easy retrieval of connected text frames.
Are you guys fine with that? If so, I would go ahead and implement this.
Nice idea to have that as a collection too, especially for the potential of cycling through linked textFrames of an entire book! Does it need to change pages automatically when editing a textFrame on another page or would it just do it? Also guessing it should ping itself regularly to see if the textFrame length has changed... this is a bug that students occasionally run into.. changing the text size when cycling through lines() – since obviously the line groupings change if one changes the size/letterspacing/etc.. probably should also have it regularely ping to see if the following lines have changed after each one? On that note, one peeve that I think we've discussed before to try and deal with is something like words() breaking part-way if one changes the text size and some of the words become non-visible after being pushed beyond what can be seen in the textFrame.. This isn't an issue if one selects the actual contents of the textFrame first – but I think there were pros-cons of doing one vs the other.. maybe it was about bounds().
Does it need to change pages automatically when editing a textFrame on another page or would it just do it?
As this returns text frames only (or calls a callback function on them), this should not change pages by itself. If you need to change pages, you could do that manually in the callback function.
I also think we should leave the "pinging" out of these functions, as the intended and resulting behaviours are really hard to predict when working with text and changing its properties. So, I think handling issues like that would need to be addressed in the user script itself.
And actually now that I start implementing it, I'm not sure, if we should rather call it textContainers() instead, as I am not after finding nested child text frames, but rather the parent containers, which can either be text frames or text paths.
The corresponding properties are either called textContainers (for stories) or parentTextFrames (for text objects like words etc.).
So I'm thinking textContainers() would better describe what the function actually returns.
Opinions?
Ok, it's kind of tricky to decide what this function should actually do.
What I really need (in my classes) is a function to loop over linked text frames. However, in this case it does not make much sense to allow a document as container, as this does not really refer to a (one) story of linked text frames.
So maybe this should simply be a function called linkedTextFrames() that allows to loop over a single story of linked text frames (or paths). And then legal containers would be text frames (that would return the chain of text frames linked to the given text frame), stories and any text objects (words etc. that would then return the linked text frames of the parent story).
Sounds like a candidate for a plug-in?
I think the feature is relevant enough to be included in the main basil lib.
Now after giving this some more thought, I would split it up like this:
- a function
textFrames()that loops over thetextFramesproperty of a container - a function
linkedTextFrames()that loops over the linked text frames of a story, a text frame or the parent story of a text object
Thoughts? If you are both against this, then, yes, we could move it to a plugin, but as I said, I think this would be nice to include in the core lib.
Sounds better. Overloading the textFrames function sounded like an edge case usage for me. Keeping it in the style of words, lines etc is good.
Ok, perfect. Will see, if I can implement it anytime soon.