[scribus-dev] batch mode version of scribus

a.l.e ale.comp_06 at xox.ch
Thu Aug 26 18:12:56 CEST 2010

  hi farid,
> Hi all,
> I saw that there is a long standing feature request for a command line
> version of Scribus to be able to create pdf's in a batch mode
> (http://bugs.scribus.net/view.php?id=238). Our company now has a 
> student that
> could invest a couple of months development time in such a feature. 
> What we
> are thinking of is something like gimp's script-fu-server.
> see:
> http://www.linux-mag.com/id/973
> http://docs.gimp.org/en/gimp-filters-script-fu.html
> and
>  http://net-fu.sourceforge.net/
> In short: with script-fu-server you can write command's to a unix port 
> which
> is read by gimp and executed.
> The idea is to extend scribus such that it can read (python?) commands 
> from a
> port which will be executed. Scribus should be started with a new command
> line option:
> scribus --batch 10008
> the integer is the port number from where the commands are read.
> Additionally we could add a "--no-interface" option to stop the gui from
> being shown and also switch of rendering of the document to speed up 
> things.
> (An alternative would be to start scribus with the display set to a 
> virtual
> display using Xvfb.)
> I would appreciate it if someone from the development team could give us
> hints about :
> -would such a modification be possible within a couple of weeks 
> time-frame?
> -where in the code we should make these modifications.?
> -what are the pitfalls? (thread safety etc. although we would be happy if
> scripts could be executed one at a time)
> -could someone from the development team be reachable in case of 
> questions?
> (i'll be the mentor of the student myself but need someone for complex
> questions to contact)

what you are proposing is one of the most wanted features of scribus and 
there are indeed some companies and people interested in participating 
in the effort of making scribus to work in batch mode.

the problem is how to start: requests drop in every few months but no 
single company / person can do the whole work by itself.

by the way, your offer is -- afaict -- the most solid one among the ones 
i've read.

i'm not a member of the development team but i've already tried to look 
at this problem in the past so i guess can give you some -- sadly 
incomplete -- answers:

- you won't probably get very far with a couple of weeks of a student's 
work. a couple of months could lead to a breakthrough. i can't promise 
you that in this timeframe you can get to something which can be used 
for production, but it may be possible (it also depends on what you want 
to achieve).

- where to put your hands first: afaict, the biggest problem is related 
to the fact scribus has a very "visual" approach to the frame handling. 
having discussed the topic with some team members, i would say that the 
two first steps may be to create a second binary which will run in batch 
mode and make it able to read a .sla file and rewrite it to disk. the 
second step would be to output a pdf from it. and the third one to find 
a way to manipulate the .sla without rewriting all the scribus code.

- the "--batch portnumber" part seems to be easier than the "--no-gui" one.

- there are no threads in scribus, yet.

- the scribus developpers in the team are quite busy with their work and 
family life. it may be possible to get somebody to work on specifically 
on this topic if he can earn his life with it (in this matter it may be 
possible to get some companies pooling together to finance it).

so: there are people around who are already willing to work on this 
topic and companies willing to spend some money on it.
the question is: can we pull them together and find a solution?

it would be nice if your request would lead to a working solution!

i'm looking forward to an intersting discussion!

ps.: you should probably register to the scribus-dev mailing list (very 
low traffic) where this message has been posted and we may continue the 
discussion in there...

More information about the scribus-dev mailing list