If the line is a mid-paragraph line of text then there is no way to capture the text. Only if the text is something separate - like <tag> text </tag> and the 'text' fits on a single line could you capture it.

What are you trying to do with the line of text if you could capture it? There might be another way. (Rule #2 of Frills Processing ;)

I'd like to capture the line of text from the paragraph and send it back to the frame as an indicator, which is similar to the margin notes but not using <px;;0>. 

Besides, please suggest if the 'text' fits on a single line. Thanks

Hi Terrence,

There is no direct way to capture or extract the text of a (main text) line during frills processing.

You would need to capture the text of the line during composition, and then somehow output that text while doing frills processing.

One way to do that is with text registers (px/pa or cs/ce). Why will that not work for you?

Another possibility is to capture the text with XyPerl, but that would require that the text you want to capture is "tagged" (i.e. within a start and end tag and that also implies using XML or CSS modes). Your XyPerl would be responsible to "save" the captured text in some way and then you would need to use XyPerl within your frills processing to "output" that saved text.

You've been kind of sketchy on details; perhaps if you provide more details on your scenario we might be able to give more specific or other suggestions. Or it might be a good idea to open up a ticket with Customer Support, where you can provide all the necessary details (including a sample job).

Jonathan Dagresta
SDL XPP Engineering

I'm not sure why Mark says that the captured text cannot be mid-paragraph or has to fit on a single line, but he is correct that the text has to be "tagged" (either with px/pa or cs/ce or start/end tags and using XyPerl).

As far as I know, the captured text can be longer than one line if using cs/ce or if using px/pa or start/end tags with XyPerl the suppressed text can then be re-output back into the (main) stream and then result in more than a single (composed) line of (generated) text.

But the "details" are important, as what else (i.e. coding) is in the captured text may pose some challenges in what could otherwise be a straightforward solution.

Jonathan Dagresta
SDL XPP Engineering

Hi JD. If a para was tagged <p> text </p> and that text ran over multiple lines, there's no way to pick out a mid-para line. That was what I meant. Perhaps I didn't make that clear ;)     However, I have always wondered why Frills Proc can't extract a line's text - i.e. the mid-para scenario.   It exists. XPP knows its there. XPP knows all sorts of info about it (max ascender height, indents, etc etc), why not extract the text using F.P.  (although I realise that everything about F.P. querying XPP returns only numbers.   It would certainly make life (as a developer) easier having direct access to non-explicitly tagged text. (i.e. the mid-para scenario)

Yes, Mark, it was not clear to me.

However, if you had <p>text1 text2 <capture>text3 text4</capture> text5 text6</p> then you could capture the "mid-para line" tagged by the "capture" tag.

How else would you define what it is that you want to capture? Do you really just want to capture some "random" line in the middle of the paragraph that is just determined by where the beginning and ending line breaks occur? Seems like a strange use case to me.

As I said, XPP does not currently provide a way in frills processing to directly extract a line's text during frills processing.

That would be an RFE, i.e. something that could be entered as an SDL XPP Idea.

I don't believe that there is any way that XPP classic macro processing would be able to just give you back a "string". In my thinking, there would have to be added some way to capture a "line" into something like a text register. There would be a number of things to determine/design, and we would need to know what are the full set of  "requirements" of such a feature.

Jonathan Dagresta
SDL XPP Engineering

IMHO - yes, I might want to capture mid-para lines of text (no ability to capture composed lines) mid-para.  There may be some sort of other event that might trigger the need to 'read' the composed line of text. e.g. a number register is set to a particular value or a macro executes </fg>.

I certainly agree that it is probably time to take away the many limitations of frills processing.
Maybe it is time to put some thought in this and launch a new idea.
I would like to see:
- allow multiple fg macros on the same line, each triggering their own event
- add a number to the fg macro (fg;2) so that we can start different actions if we encounter a flag event
- add the horizontal position of the fg macro in the line as a frills processing variable
- allow each fg event to have its own px;;0 text register allowing to store several text strings on the same line
- and last but not least: I do see some value if the content of the current line could be read during frills processing

I have turned this into a new idea on the SDL idea page
So feel free to add other things that you find useful or things that I have missed.
Just go to https://community.sdl.com/ideas/contenta-ideas/i/ideas-xpp/extending-enhancing-xpp-frills-processing

Oh and please do not forget to vote my idea UP!

Hi Jonathan,

Text registers <px;;0> works for me. Unfortunately, it is occupied by the margin notes on the same line. 

I'm interested to know how do we "save" the captured text and pass it to XyPerl?

Below is the sample paragraph in which 'AAA' is the right margin notes and 'B1' is the index. The text register is occupied by <ufm>. I'm wondering if it is possible to pass the whole line to XyPerl during frills processing so that I could extract 'B1'.

%<ufm>AAA<ufn>[tag]B1 The following tables summarize our consolidated financial results during the Track Record Period and should be read in conjunction with the section headed “Financial Information” on pages 10 to 20 of this Prospectus and the Accountants’ Report set out in Appendix I to this Prospectus, together with the respective accompanying notes.

Terrence