integrate ScribusGenerator script in next release about scribus HOT 4 OPEN

hey berteh,

personallly, i've made a few bad experiences with tweaking documents "from the outside".
not only with scribus, but also with rtf and docx.
even pdf gets very tricky.
and i've seen how a few tries at doing so with scribus documents fail when the scribus code base (and .sla format) changes.

this is even more true all when the format is not correctly documented.
like in the case of scribus.

somehow i would love it if all the hours of work that have been put in such solutions (there have been a few already) would have been put in getting the new scripter to work.
which would give everybody a real solution for filling documents with content without having to mess with a badly documented file format.

now, back to your second question.

as far as i know, there are plans to create a script downloader... like there is already for the hyphenation files and dictionaries (iirc)

from scribus.

Hey berteh, ale,

I had a cursory look at the source code and had a good impression. I’d like to see this plugin in Scribus.

Of course it will have to be adapted for the new file format. The days of are counted! J

/Andreas

from scribus.

eh eh... the better the code the more sade i am... somebody witth good skills has put a lot of work in something that by definition is of limited use.

really, having it inside of the scripter would allow the script to check for sizes, overflows and do a much better work!

from scribus.

Hi Ale, Andreas,

Of course I understand your preference to see such a functionality in the core code.

Just to explain a bit of the history I needed this tool about 2 years ago to generate (serious game) cards decks in many languages. I tried to hack it in the code for a few hours, but my (very) weak C++ knowledge, and poor traversal capabilities of the Scribus data model (at that time at least) quickly made it very unefficient and slooooow. Accessing all these elements without a proper api was close to impossible in 1.4.x. And my skills not good enough to code a full API on that basis, while scripter API was only in its infancy and announced "more than likely to change drastically".

Therefore I used a (lower level) XML + regexp substitution approach that is much faster (takes less than 7 seconds to generate 150 unique copies of a quite complex SLA, and usually about 2 seconds for "normal" usage)... and easier to code in python (for me at least, as it required no compilation).

The generation is mostly independent from the syntax of the file (as long as you give a valid SLA in input, you get it valid in the output) but for a few mechanisms (below). So overflow, hypertext links, frames linking, layers and all other validations provided by Scribus are still working with no extra work.

For a few functionalities though I had to indeed "dig" into the not (well) documented SLA format... and for these indeed, future changes in the file format will mean adapting the code of the script. These are (only):

• shifting the multiple copies of objects from one page to the next when you want a single "merged" output file (using pages dimensions and gaps as per this pseudo-code)
• replacing linebreaks and tabulations in the source (csv) data into the appropriate scribus elements (namely breaklines and itexts with similar style)
• saving the options of your generation run in the scribus file, for future reuse. (in a custom "script" element)
• preserving colors palette ("color" elements) from being altered by the generation ("too" generic for sake of speed) .
• linking text frames properly in merged document

For this reason I waited for the 1.6.0 syntax to come... but now 1.5.2 is announced "pretty stable", so it seems to be the time to push this script forward.

FYI A requested feature is for the generator to allow to build "tables" from a repeating cell/row/line. For such thing indeed scripter would be more than useful... so I may have a look at it in the future, but it's not going to be soon as I have no clients for such a feature nowadays.

@andreas-vox do you already know what will replace itext ch? where can I find such info? is any other element I mentioned above going to change in the new format?

from scribus.