What is the logic behind 'story editor' and 'text properties', why not merge?

Previous topic - Next topic

ikhider

I was working with text in Scribus and noticed the 'Story Editor' and 'Text Properties' and wonder why the two must be kept separate. Two dialog windows for what should be the same task seem redundant, especially since you can control font selections from both. It seems that 'Story Editor' is for styling the body of the text, such as italics, but it lacks a live preview. Whereas 'text properties' does live preview the text, but you cannot style parts of the text within the body or be selective about alignment. 'Text Properties' does, however, have a font weight menu. Handling fonts in 'Story Editor' tends to be awkward as it keeps reverting to default font. It seems a better workflow would be to have a one-stop-shop for text styling/editing by merging 'story editor' and 'text properties'. Having two separate menus for what should be the same task is awkward. Further, why not have the option to dock font menus as text and attendant styling is pretty important in desktop publishing. Perhaps something to consider for Scribus 2.0? Maybe someone can explain the logic of the two dialog windows?

a.l.e

the story editor has been created a long time ago, when editing in the frame was too slow.

nowadays, the story editor should only be used in those case when editing in the frame is not comfortable... and you should avoid doing the formatting in there.
personally, i use it once every two years...

and, yes, we need a new story editor that does even less formatting (but, probably, shows the formatting in a sort of markup). some sort of power tool, for those who don't need to see the formatting.

for your case, just ignore the story editor and do your editing in the frame.

ikhider

@a.l.e. Thanks for the reply.

Normally I cut and paste text into the text frame and then style it bold and italics as needed. So based on your advice I imported a Libre Office Doc that had some styling to the text already. Unfortunately, this may not always be a workable solution. Sometimes the font weights do not show properly and I need to test in different styles. When I change to a heavier weighted font, I lose my formatting. So the story editor becomes essential for applying those styles. Unless there is a way to keep italics, bold, etc.. as I move between font weights to test how something looks. A lot of previewing is required and the story editor is not good for that. How would you handle multi formatted text in Scribus? Especially if you need to move between font choices and weights to see how something looks?

a.l.e

sorry, i don't understand your issue.
you probably need to give more exact steps on what happens and what works in the SE that does not work with the frame and the text properties.

personally, i do all my formatting in the frame (without the story editor) and i'm more than happy with it.

since you're asking:
if i would need to show multiple different formatting, i would go with styles, in multiple documents.
a bit of an effort. but it works.

finally, indeed, scribus is not that good for testing multiple font options on a text that is already formatted.
i've opened a ticket and we will see if somebody thinks that it's easy enough to (try to) keep the font style "inside of the selection".

ikhider

@a.l.e.

"personally, i do all my formatting in the frame (without the story editor) and i'm more than happy with it."

This is interesting, as I thought you can only edit text in 'Story Editor' or in the document before importing. How would you format in frame?

AdmFubar

I find it handy when needing to edit text that is stuck behind another object. I tend to use a lot of grouping and have found it to be much handier than ungrouping and  rearranging the items on the page to make a minor change in text.
Using Scribus 1.6.1, openSUSE 15.5
Advanced hobbyist

ikhider

Something to consider, merge properties with story editor so we can get a real time preview of text layout. Right now, I need to keep launching the story editor to test every little change. Also, make the text properties/story editor windows dockable. It is a huge ask, I know, and there is only one developer. So please consider for version 2 or 3. The less clicking and window  launching, the better.

a.l.e

oooooh!

just double click on the frame and start typing, selecting and formatting using the properties!

the alternative is to click on the frame and then press the e key (instead of double clicking).

the story editor is the rickroll of scribus... some people get trapped into it...
i'm really sorry for them.

as i wrote and ikhider confirmed, the story editor is for special cases...
and ikhider will have learned something new: instead of starting the story editor he/she can now press on the "e" key and then start editing! (sometimes it will be then more comfortable to move around with the arrow keys instead of using the mouse)

dragonfly

I confess that I am a casual visitor to this forum dropping in from time to time to read trends.
I defer to more experienced users.

However I have an idea to develop a "power tool" to which @a.l.e. refers above.

Basically using UI automation scripts the Scribus GUI (including properties windows) can be controlled using external helper scripts (macros).  This would allow meta commands to drive more complex operations using Scribus built in methods.

We do have the benefit of Scripter but my approach would be to "drive" the Scribus GUI to apply various processes.

The biggest obstacle is finding an automation "power tool" which is truly cross platform.
I have one which covers Linux (my desktop) plus Windows, but not Mac.  However Mac has its own family of automation tools.

If I get around to writing one I will post it here.  But the general idea is to use Scribus in a "tool chain" such as importing markdown content from an Editor such as atom.io (or Scrivener or Sublime .. ) into Scribus text frame(s) (as one example of a pipeline). Another example would be using pandoc to pump content into Scribus frames.