[scribus] Scientific Document language "WiScri" -> Bunch of bugs/proposals
ale.comp_06 at xox.ch
Sat Jul 8 09:52:34 UTC 2017
eh eh, you have lot of questions!
but you could have asked them while you were working on your thesis:
a few of them are not real issues...
> 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)
seems to be something interesting, but exactly were you doing with that
i will have to look at the documents your have linked soon : - )
and now to the lot of questions:
> * The printer pre-tests warns for objects which are marked as "Do not
as far as i can tell, it tells you when you have a mismatch between
visibility and print.
if you don't want that to be checked you can turn it off in the
preferences / document settings.
> * All images are being treated equal concerning the compression
> method / level
the development branch already has an optional per image compression
but in my experience, most of the times, it's better to compress and
crop the images before loading them into scribus and do not ask scribus
to change anything.
> * 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]
as far as i know, this only happens if you ask scribus to compress them.
did you wonder why i was suggesting to do all the image editing before
loading the image in scribus?
do you have any evidence that it's not that 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)
the information is available in "extra > manage images" (and probably
if you launch the load dialog while the frame is selected)
you can also change the path there.
but you have to do it for each image individually.
(being able to change the multiple images is a feature request that has
been filled a long time ago)
> * You cannot modify pdf links (except changing the document .sla
just double click on it.
am i missing something?
> * 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.
please fill a bug report...
with a short test document and script.
> * [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
i have already expressed my opinion on it in the past:
- items should not have a visible name.
- you should be able to set a name for your own usage, but scribus
itself should never use it internally.
> * 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.
please fill a bug report.
but the correct solution would be to always use styles when formatting
text from a script (afaik, it's still not possible to apply character
styles from the scripter, so your approach is probably the only
> * Whilst executing my scripts, scribus excessively puts itself into
> the foreground and uses the clipboard
the scripter has been created for automating users' actions.
but i agree with you that it should not be that the scripter should not
use the clipboard except when explicitly asked to so.
please fille a bug report with the list of commands that use the
> * Whilst executing my scripts, scribus doesn't let other programs use
> the clipboard (script execution breaks)
if you have more details about this, please fill a bug report.
how can we replicate this?
> * 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 = ;
... you should be heading to the bug tracker now...
we will need a demo script.
> * 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 = ...]
this is not my experience with 1.5.3. i could export the pages in the
order i wanted.
but you might be doing something differently than i was doing...
> * 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)
yes, this is a feature request : - )
> * There's no handy tool to relink text frames - you don't really see
> what you are doing.
in the view menu, you can ask scribus to render the arrows in the text
> 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, a little roundup.
after having read my comments above, it would be nice if you could
download scribus 1.5.3 and check if the issues are still there.
the bug tracker is at https://bugs.scribus.net .
just ask if you have issues with installing 1.5.3!
finally, you seem to have the skills to extend the scripter... just ask
if you need help to get your hands dirty!
More information about the scribus