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
