[scribus] Scientific Document language "WiScri" -> Bunch of bugs/proposals

[Jonas Bechtel]

Dear Scribus team,

on monday I have submitted my study thesis. This thesis was written in scribus, but for the chapter numbering, page numbering and limited conditionals, I implemented an own language in python and called it WiScri (for scientific Scribus = wissenschaftliches Scribus in german). It ended up in following kind of statements:
##SET(varname 5)##IF(##GET(varname)==5 5: korrekt ++ELSE 5: nicht korrekt)

(Because I'm confused with all this LaTeX stuff and I don't have Word on Linux which has limited "field" functionality and OpenOffice/LibreOffice seem to have even less "field" functionality)

But not everything was fine; there were some barriers which could be teared down. I do list them here, please tell me which points are to be handled in which way (bugtracker, ...)

I'm using Scribus 1.4.6

The barriers were:
* The printer pre-tests warns for objects which are marked as "Do not print".
* All images are being treated equal concerning the compression method / level
* All images are reencoded, even if already in target format.
* [png images could be used with no reencoding in pdf files, they seem simply to be split in some special way]
* Display and modify the source link for embedded image/eps files. (To correct links like ../../../../../home/user/subdir/subsub/mydoc/pic1.jpg - I have done this in the document .sla source)
* You cannot modify pdf links (except changing the document .sla source)
* The internal utf-8-representation doesn't match the output bytestream for scribus.getAllText() - I had to escape all 2-Byte/3-Byte chars before main WiScri processing and reescape them back after WiScri processing.
* [When copying objects the new object get's a localized name which only can be guessed - OK, that seems to be better in the recent version]
* After copying an object this object reports wrong font names when they are programmatically questioned. To circumvent this you have to insert some text and delete it in the same line as the questioned text before questioning.
* Whilst executing my scripts, scribus excessively puts itself into the foreground and uses the clipboard
* Whilst executing my scripts, scribus doesn't let other programs use the clipboard (script execution breaks)
* After using the Python PDFWriter object, the Python execution ends with errors when performing simple string operations which work perfectly before. Sometimes you can circumvent this by deinitializing it: p = scribus.PDFfile(); ... p.save(); p = [];
* pdf export checks 2 times the page numbers if invoked by python. Especially stupid is the routine which _sorts_ the page numbers without any technical need for it. I had to "hack" the binary (as I didn't want to recompile it on my rather old system) in order to switch off page number sorting. [happens directly in the setter for p.pages = ...]
* Position of pieces of text - It would be pretty nice to know the final position for the words inside text objects (so-to-speak to know where the sub-chapter heading is located, when knowing it is char 456 - 481 of the text object)
* There's no handy tool to relink text frames - you don't really see what you are doing.


If you want to have a look at the file, feel invited to visit http://jbechtel.de/site/Tools/Zellortung where you find the actual pdf and the compressed project directory.
Most likely, your document build won't work for the first time - don't hesitate do ask me questions on the code I've written and how to bring it to life :-)


So again: this is a big list, please tell me how to dispatch it's items.


Greetings
 Jonas Bechtel


__..--::°°""^^´´