[scribus-dev] Scribus 1.4

[Craig Ringer]

Andreas Vox wrote:

>> 2) Feature request #1 is imposition. We had a GSoC project that  
>> wasn't exactly a success. I don't think 1.4 can be released without  
>> completion of this code.
>>
> Agree (or a replacement)

BTW, I still think that doing imposition during PDF export is likely to 
work best for most users. If the PDF code wasn't quite such a tangle of 
positioning calculations it wouldn't even be that hard. Instead of 
emitting pages directly the PDF code would emit XObjects for each page, 
then assemble the XObjects onto pages. It might not even require 
particularly significant changes to the page output code.

When I tried to do this I didn't understand that I didn't need to adjust 
all the object positioning code. I could just output page contents as 
xobjects then scale, rotate, and translate them as appropriate.

To make the feature essentially complete and allow for custom crop marks 
etc all that it'd need would be the ability to apply a master page to 
physical pages after imposition. Again, XObjects to the rescue.

I'm just not convinced that imposing using Scribus documents will be 
sufficiently fast or reliable, or that the flexibility is worth the 
complexity.

Then again, I made a rather half-hearted try at implementing this, gave 
up as I didn't understand PDF well enough and was trying to go about it 
all wrong, and haven't revisited the actual work since. So maybe I'm not 
one to talk.

>> 9) ScripterNG should definitely become part of 1.4.
>>
> Definitely.

There's some exciting stuff happening in Qt land with QtScript. I'm 
increasingly convinced that Python is the wrong choice for Scribus (and 
remember, I've worked with it *way* too much):

- It offers no sandboxing or limited functionality mode. You cannot 
trust a script you get off the 'net not to exec rm -rf / or go fishing 
for passwords.

- It's clumsy when trying to isolate scripts from each other. We're 
using a dreadful hack to do it that only works through sheer luck. 
Subinterpreters are designed to be one-per-thread. We can't just spawn 
threads for them, though, since Qt isn't safe for use from other threads 
even when an application-wide lock is used.

- The standard tools for wrapping functionality are crude and require 
lots of manual work. Alternate tools, like Boost::Python, require faith 
in large amounts of template metaprogramming black magic that's 
incomprehensible by normal mortals and is likely to break spectacularly 
with Python 3.0 . They're also arguably not much easier to use to 
produce solid, correct code.

- The GUI toolkit module, PyQt, isn't designed for or tested with 
application embedded interpreters. It happens to work, but only with 
some interesting restrictions.

Compare this to QtScript, which:

- Permits trivial export of app functionality
- Provides useful Qt classes for user scripting
- Has a built in UI engine
- Lets you control how much, or little scripts can do
- Comes "free" with Qt rather than being an additional dependency

http://doc.trolltech.com/4.4/qtscript.html

IMO QtScript is the natural choice for Scribus if the scripting layer is 
to be replaced - and I agree that it does need to be.

However, any QtScript API would need to be based on an abstracted and 
higher level C++ API than Scribus currently presents. One that might 
also be useful for plugins, exporting via Kross to any number of 
scripting languages, etc.

That way most user scripting could be done with QtScript. If people want 
to do more complex things like talk to databases, though, options like 
Kross could expose more powerful (but dangerous and harder for most 
users to understand) languages like Python, Ruby, etc. With luck, Kross 
may be available for Win32 and Mac OS X with kdelibs4 progressing.

I'm just not sure that new python bindings to replace old Python 
bindings is the right answer, even if the new ones do use a cleaned up 
and simplified C++ interface and use a wrapper generator.

I've been meaning for some time to throw together a plugin to 
demonstrate simple QtScript scripting of Scribus. I'll have to see what 
I can do once PoDoFo 0.6.0 is out the door. It'll be interesting to see 
what is and isn't possible in practice.

--
Craig Ringer