Clarifications on how `%SG_NEXT-RECORD%` works... about scribusgenerator HOT 5 CLOSED

hello.

In the current implementation %SG_NEXT-RECORD% is not to be considered a variable, but rather a signpost in the SLA template file that instantly loads the data of the next record when met to be used for the current and subsequent substitutions... and the SLA template file is read by ScribusGenerator as a plain text file, in sequence, since Scribus was not using much of the XML nesting features.

So its effect really boils down to either the moment you include it in your template (in your case I'd recommand to remove all but firt 2 cards content (with variables and all ready), then add a text frame with simple content %SG_NEXT-RECORD% (if it's empty it will be removed by SG), and then add all content of second row. No need to create extra pages if your content is the same: the first page will be duplicated to fit the provided data length.

a more detailed walktrough for %SG_NEXT-RECORD% is available at https://github.com/berteh/ScribusGenerator/wiki/How-to-use-%25SG_NEXT-RECORD%25

any suggestion to improve this feature is welcome, especially along with a PR.
B.

from scribusgenerator.

Thanks for the response. I think what you are saying is what I expected :-/

I have already tried what you suggest (I added a text frame with %SG_NEXT-RECORD% between the first row and second) but the first card on the second row only seems to have ~50% of the variables correctly updated (the rest are from the previous record).

I have checked the outline view and the text field with %SG_NEXT-RECORD% appears to be located in the correct place. Looking at other issues and the wiki, is it safer to assume that the XML generated by Scribus is not a direct representation of the outline? Or, is it that Python doesn't load the XML nodes in sequential order?

from scribusgenerator.

1. indeed the XML generated by Scribus is not a direct representation of the outline. things such as parent page, groups, levels, inline images and some more are coded as plain text attributes and not the XML hierarchy. Scribus stores the elements more or less in the order of creation.

2. the scribus generator (currently) loads the XML exactly in sequential (textual) order, not hierarchical (the outline).

If you are comfortable witḣ reading XML code, the easiest way is to open the SLA template with a text editor and move the element containing %SG_NEXT-RECORD% to the location that suits your needs (I'd guess just below all the content of your first row). I isually add meaningful IDs to my object properties, so finding them with a text search goes fast.

from scribusgenerator.

Thanks for the reply (and clarification). I can understand now why this is so annoying to implement!

I am fairly familiar with XML, thought I cannot say I enjoy it much :-p. I will have a play around and see what I come up with,

from scribusgenerator.

good luck !

any improvement to the documentation is welcome directly in the wiki at https://github.com/berteh/ScribusGenerator/wiki/How-to-use-%25SG_NEXT-RECORD%25

or if you have a better idea for the overall workflow don't hesitate to open a new issue on that topic !

from scribusgenerator.