🚀 go-pugleaf

Robert,

Those code samples look very similar to me, except:

- The first example iterates through all flows in the doc, while the second one reads the main flow only. The main flow is the standard flow in which authoring takes place, normally named flow "A". A document typically has many other flows, though, such as any text frame, including text frames on the reference pages.

- The second example reads the line ends into the textitemsT structure, while the first does not. I don't think this really matters to you because you'll get separate strings in the structure for each line anyway, I believe.

Some other points related to your questions:

- I don't know how you can get the flows in document order. Maybe there is some trick to finding out what page the first text frame of a flow is on, then deducing the order from that. I don't know how to do it. I do know, however, that iterating through the internal stack like your first example will not necessarily give you the flows in document order. Furthermore, you won't even know whether they are even on the body pages.

- Most flows do not have names. For example, if somebody sticks in a text frame for a graphic callout, it won't have a name. So I'm not sure how much that would help you, unless you are dealing with an exceptionally rigid template that was specially designed for your application.

- I don't know any way to ASCIItize your strings, except iterating over the characters and looking for characters in the unicode range and then converting them to something. I'm no expert in this area, though, so that's just my quick answer.

- A flow is not an element. A flow is one or more connected text frames that contain a flow of text, which may or may not have that text wrapped in a tree of structural elements. If you really are talking about elements instead of flows, then much of what we have said so far is not applicable, because you might be barking up the wrong tree, so to speak. Can you maybe clarify what your goal is?

Russ