setting frame text without resetting style

Previous topic - Next topic


I am working on a collaboratively translated document (a comic book) with many irregularly distributed text frames with different styles (think of descriptions, callouts, etc); the style is set per-frame. I export plain-text of text frames into google document, let people improve the translation, then load it back (it is a bit more complicated to match frames with pages and such, but that's is not important now).

I set new text of each frame, something like:
for page in range(1,scribus.pageCount()+1):
  for frame in scribus.getPageItems():
    if frame[1]!=4: continue # not a text frame
    newText=... # grab new text value

but what happens is that styles of processed frames are reset.

Is there a way to set text while preserving the style information? Note that even in (rare) cases of multi-paragraph frames, they still all have the same style which I applied to the frame itself.



stelf came up with this solution:

import scribus

tb = 'Text2'
repl = 'new cntent'

l = scribus.getTextLength(tb)
scribus.selectText(0, l-1, tb)
scribus.insertText(repl, 0, tb)

l = scribus.getTextLength(tb)
scribus.selectText(l-1, 1, tb)

which is also what you would do in the UI.

i hope that someday the way formatting is defined will be fixed... until that time such hacks will be needed...


Thnanks :) works nicely. I hope new scripting functionality with a saner API (like the never-finished scripter-ng) will come, this feels so much like visual basic ;D


i hope too (and i'm working to make it real... help is always welcome!)

but this issue is in scribus itself and cannot (really) be solved in the scripter...


Quotei hope too (and i'm working to make it real... help is always welcome!)
where can I check what is being worked on? Github? And which scripter plugin? Got lost a bit, -ng, 2, ... ;) Thanks for your work!


my work on the new scripter was/is in this github repository:

the most interesting information source is

as you can read in the (currently) last comment of mine, i'm right now testing a new approach using pybind11.

my tentatives can be followed here:

it still looks a bit wild but i'm close to get a prototype that could be used for building a new scripter.
and, with a bit of luck, that repository will transform in a nice manual on how to embed a python interpreter inside of a c++ application.
(imo, this is something that is not well documented, and every project is creating its own solution)

the reason why i'm trying a new approach is this issue:
(we cannot get signals and slot to cross the c++ -> python boundary)

combined with the issue 3 linked above -- which states that the technology used by the scripter created by henning is not supported anymore (and have never really been supported) -- i prefer restarting from scratch, get much inspiration from the wonderful previous new scripter (really, it looks like a very clever solution... even if i could not understand everything!), and produce a new scripter with a very similar API as the so called scripter 2.

i hope to have my tentatives finished by the end of next week and then i could need work with defining the API and porting the code from the scripter 1 and 2 to the scripter 3

ah, please, forget as soon as possible the name scripter 3... if it gets into scribus, it should simply be the new scripter or the pybind11 scripter : - )

To cut a long story short: it's saturday evening,  time to party!


Wow, very happy you chose pybind11. I have a LOT of experience with boost::python and have liked pybind11 from the very beginning (still know only from docs), it is solving a lot of boost::python's issues, plus is much more lightweight. I will look at it. Good luck and thanks for the thorough information! vaclav


thanks for your "insight" on pybind!

i'll open a topic about the "pybind11 based scripter" in the forums, as soon as i've cleaned up the repository in a way that helps understanding what i am up to : - )