[scribus] Scribus 1.5.3 on Debian with Python 3

Sat Sep 2 07:39:51 UTC 2017

Dear Scribus Team,

I now have managed to compile Scribus 1.5.3 on my system (Debian GNU/Linux) with Python 3. Of course there are many flaws so far (especially the string definitions have changed -> routines such as pdf creation still can't be invoked from Python)
-> a) I will test all the issues mentioned in my original message and - if needed - file them in the bug tracker
-> b) If you are interested, see the Python 3 diff in this attachment. Please mind that this isn't the pure Python changes, but includes also few other code changes and is not adapted to any coding style so I would suggest to review every single change before applying it. I didn't find a hint that a Python 3 progress is already ongoing in the development.

Greetings
 Jonas

----- Start Forwarded Message -----
Sent: Sat, 08 Jul 2017 23:54:32 +0200 (CEST)
From: "Jonas Bechtel" <post at jbechtel.de>
To: "Scribus User Mailing List" <scribus at lists.scribus.net>
Subject: Re: [scribus] Scientific Document language "WiScri" -> Bunch of
 bugs/proposals

Dear a.l.e, dear Greg,

thank you very much for your replies and the insights concerning the ongoing Scribus development!

General explanation: Yes, it was much work for a not-so-big document. But it was not too complicated. It was the minimum set of code which was necessary to fulfill most requirements of my supervisors (chapter numbering + table of content as usual; figure numbering; some requirements on the page numbers) and some requirements of myself (I wanted the last page to have the number "Z" and a multi-version file, but actually it was only one active version). And the second point is that I'm willing to reuse that script system for the diploma thesis, so the time usage is only half of what it seems to be.

When working on the "thesis" (document production was about 1.5 months) I didn't want to open one more communication channel, I wanted to concentrate on the document. So you didn't hear of me.

Now, I will tell you what I've taken from your answers, inline+numbered:

1> * The printer pre-tests warns for objects which are marked as "Do not print".

As you both misunderstood it, I have to explain it some more: When there's an object with warnings/errors (e. g. overflow/missing symbol) then these warning do appear in the pre-tests even if the object won't be printed. For single objects this isn't a problem (one warning less or more is managable) but for WiScri it's a problem as many invisible text objects will overflow which according to their very nature. Here begins the problem: you don't find the one important warning if there are so many to-be-ignored warnings.

[Besides - I checked the box to ignore non-printable layers - it didn't help -> If it's the same in version 1.5.3, I will file a bug report]

2> * All images are being treated equal concerning the compression method / level

As there are changes in the development branch, I won't do anything about it.

3> * All images are reencoded, even if already in target format.
4> * [png images could be used with no reencoding in pdf files, they seem simply to be split in some special way]

You stated that jpeg would be embedded directly, but this is not the case for 1.4.6 - I have found rastered images (/Filter /FlateDecode) in the final pdf document using compression method "zip". Same to "none", except that "none" produces a 1.7 times larger pdf file.

If it's the same in 1.5.3, it will become a feature request.

5> * 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)

This is important for me personally because I had a long path name for the project directory.
1) To ease [I was to about to write "enease" but this word apparently doesn't exist] the use I have symlinked it to as short name to my home directory.
2) It is a concern of mine to make things more archivable. Thus I had in mind that the project directory may be unzipped in 50 years an then work as flawlessly as possible. Of course I know that in 50 years it will be very very difficult to access today's project directory. But anyway - I think it's worth the effort.

It isn't enough to blindly guess which is the access ways of scribus. It would be nice to set the path to either <system root>/usr/share/extra/images/smiley.jpg or <document path>/../images/photograph.jpg and especially to see which of these access ways is actually happening to the image.

Thanks for the hint to the image manager which I didn't know so far. I have needed the functionality to see the path -> should have known it earlier. It doesn't help for this issue 5> *.

If it's the same in 1.5.3, it will become a feature request.

6> * You cannot modify pdf links (except changing the document .sla source)

OK, misunderstanding: you can open some GUI dialog and modify the pdf links, but you cannot do this in Python.

If it's the same in 1.5.3, it will become a feature request.

7> * 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.

Next misunderstanding: the strings are all fine. The problem is that the scribus.selectText() counts 2-Byte/3-Byte chars a 1 char whereas the strings from scribus.getText() contain them as as 2-3 chars. For WiScri I have to access specific text sequences depending on the text itself.

Hm, I think, it could be a feature request.

8> * [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]

(no comment)

9> * 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.

Yes, it is possible to set specific fonts. But it's not easy to discover :-) (I don't remember the details now, but I guess you have to switch the "frame's" style _before_ inserting text but you have to switch the "frame's" font _after_ selecting the inserted text -> this is one of the reasons for which 7> * is an issue)

So you see it does make sense to query a frame for the actual font - if you selected some specific text in advance.

I have chosen my font configuration in order to detect paragraphs which haven't any style yet - they will appear in frame's default style which is different from the other styles so I see that there's a implicit TODO.

I consider this a bug as I get the right fonts without tricks when questioning the original object (from which the "bad" copy was made).

10> * Whilst executing my scripts, scribus excessively puts itself into the foreground and uses the clipboard
11> * Whilst executing my scripts, scribus doesn't let other programs use the clipboard (script execution breaks)

I will try to find the commands which are problematic, as requested, and file a bug report.

12> * 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 = [];

If present in 1.5.3, I will file a bug report.

13> * 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 = ...]

I have downloaded the recent code and have clearly seen that the setter for "p.pages = ..." sorts the list (ironically it doesn't unify duplicate pages). That it will be checked 2 times was a guess of mine.

14> * 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)

OK, it will become a feature request.

15> * There's no handy tool to relink text frames - you don't really see what you are doing.

When working with my document, I had to insert a text frame in the middle of an already linked text frame row. As I view the document with 100% size factor, I have to scroll to see the next text frame. And in addition the arrows sometimes were wrong. Maybe the arrows are right in 1.5.3. 

Anyway: You are right, the functionality is implemented. consider this item 15> * only as a nice-to-have feature request for some GUI dialog where you can reorder the linked frames by drag'n'drop. This is the kind of dialog with which you play when the ideas come to slow. It's simply not important.

It may sound strange to you after you read all this - I have not much time. So maybe I will try to modify two tiny things in the Scripter Extension (pdf page setter, pdf link configuration), but there's no room for more. It is very unlikely that I will change substantial parts of the code. To prevent from doing harm to the code I will ask in advance before beginning to design the code changes. [Anyway thanks for your offer!]

Greetings
 Jonas

P. S.: One tiny special thing about the study thesis is that I state four sentences (thesis) in the beginning which I recall in the end. In order to get an exact textual representation I define + show four variables (for four thesis) and in the end I show these variables again. (Because you asked what I'm doing with that language.)

On Fri, 07 Jul 2017 18:37:15 +0200 (CEST), "Jonas Bechtel" <post at jbechtel.de> wrote:

> 
> 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
> 
> 
> __..--::°°""^^´´
> 
> 
> ___
> Scribus Mailing List: scribus at lists.scribus.net
> Edit your options or unsubscribe:
> http://lists.scribus.net/mailman/listinfo/scribus
> See also:
> http://wiki.scribus.net
> http://forums.scribus.net

----- End Forwarded Message -----

-------------- n�chster Teil --------------
Ein Dateianhang mit Bin�rdaten wurde abgetrennt...
Dateiname   : scribus_python3.diff
Dateityp    : text/x-patch
Dateigr��e  : 49350 bytes
Beschreibung: nicht verf�gbar
URL         : <http://lists.scribus.net/pipermail/scribus/attachments/20170902/2a977cb8/attachment.bin>