Story Editor Default View

Previous topic - Next topic

mesh

Hello,

I'm trying to figure out how to work with the story editor (although, based on what I've read so far, it looks like the story editor isn't the best option to use to edit text).

The default view of text in my story editor is a strange font that doesn't reflect what the font of the actual text is.  See screenshot attached.  Any ideas what's wrong?

EDIT: I figured it out.  My display font was different (in the story editor, Settings > Display Font).



[attachment deleted by admin]

Nermander

That is the way the story editor works, it has it's own font setting.

jack_cat

From the capacity to set the display font in Story Editor (which I find in 1.5.2 but was absent from 1.4.6), to go on to include the ability to display the fonts that have actually been applied to the text seems like it wouldn't be a huge step.

The Story Editor needs no more WYSIWYG capacity than that, because obviously it cannot show what is on the main page, but if it would display the markups that have been applied by displaying the actual font that has been applied to each word, phrase or paragraph, it would be vastly improved. I don't see why this couldn't be done... in time!

Nermander

The whole point with the story editor is to not be WYSIWYG.

If you want to edit WYSIWYG, then edit directly in the frame.

The story editor is useful for example if there are text frames that are rotated 90 degrees, or similar cases where editing "in frame" is not useful.

The story editor still shows paragraph styles at the left side. It does not show character styles though, and not direct formatting.

jack_cat

Nermander:
I was not being clear, I'm sorry. It is not that I wish the Story Editor to be WYSIWYG, this is clearly impossible
and does not describe what I am really talking about. That was not a thoughtful use of the term. And I feel that the point has not been properly made, and so I will try again to explain that I, as a genuine, consistent, practical, daily user of Scribus would find it useful to me, if the Story Editor might be improved in the way that I am suggesting. I assure you, I am a real daily Scribus user. I am not a lookie-loo saying, oh, I'll think about using it if it behaves better. I've been using it for 4 years already. I'm speaking about something that I am intimately familiar with on a daily basis.

What would be very useful, and would considerably improve the user-friendliness of the Story Editor, would be that the Story Editor would display the exact fonts and markups that have been applied to the text, within the paragraph format now existing, leaving out the auto-hyphenation and the shape of the text box, WYSIWYG features which would be inappropriate for inside Story Editor. Some of these attributes the Story Editor already DOES display: specifically, it shows superscript and subscript. Why not then also the correct font, and bold and italic as applied? What would be so much more difficult about that? It is merely a matter of being able to see one's work as one goes. When editing HTML I don't have a problem checking it in the browser every 2 minutes, and I don't have a problem with doing that with Story Editor, really, but you see, I can READ the HTML code myself, and I can see what it says in its own format. The problem, I am saying, with the Story Editor is precisely that when I look at the text within Story Editor ALL that I can see is the Paragraph Styles, and all of the other markups are invisible, which is a big drag, and appears to be unnecessary, because it appears to be merely an unfinished piece of work.

In Scribus 1.5.2 (currently the latest version that I can run on my machine due to a missing .dll for 1.5.5) the Story Editor has been distinctly improved by the capacity to set the display font. Although I am a non-programmer and don't know what the issues are, it appears to me that this improvement is already a step toward the display of the actual fonts in use, as I am proposing.

I am aware that you and A.L.E. have repeatedly insisted that the Story Editor should be disregarded and the Properties Window used instead. If it is a matter of prioritizing programming effort, I understand that the Properties Window could use work too: the criticisms raised in the thread on the Indigo project are well directed. However, the Story Editor does exist, and looks to me like it has already involved a huge amount of work. Do you feel that it was a mistaken element to include in the Scribus development plan? That may be. But it just needs a little more work to be much more user-friendly.

In other words, I am saying, as a steady Scribus user of at least the last four years, that no matter what you say the "intention" of the Story Editor was or is in terms of the development team's idea of it, I as a practical user wish to state that I use it a dozen times a day, and find it very useful. If Story Editor is redundant to the Properties Window, that's certainly nothing unusual for Scribus; Scribus has related functions scattered through every possible menu window, and the current Properties Window of 1.5.2  is a complete chaos of internal cascading drop-down menus which IMO is kind of ugly. Therefore, dissing the Story Editor in favor of the Properties Window cuts no ice with me. I have been using the program for 4 years, and I am telling you, loud and clear, that I use the Story Editor daily, and find it often considerably more convenient than the properties window. I am putting in my two cents worth as one user in no uncertain terms: The Story Editor is valuable to me, and if it worked a little better as described above, it would be more so.

Now, as one end user who is not a programmer, I cannot push the Queen Mary if the plan is something else.
But I believe that I have a reasonable opinion on this, as a practical, experienced and consistent user (willing to experiment, explore and report on Scribus as a project in process and to accept its temporary failings), which I feel has been now several times casually brushed aside in favor of some abstract idea of what the program was supposed to be like according to some plan that was made in 2005.

There is another much more minor point on which I have an opinion: I think that "Story Editor" itself is a frivolous title for a useful tool, and that pegging the poor project with a silly name is part of the conceptual problem that it suffers from. I'm not about writing Alice in Wonderland, and would, myself, far prefer that it be called the Text Editor, without euphemism.

thanks
jack

a.l.e

i just checked, both quark express and adobe indesign call it "story editor".

from the screenshot, the adobe indesign one looks very much like the scribus one, but with even less features.

you might want to be a bit more careful when pushing with such fervor an idea. there is a thin boundary you should try not to overstep, if you want to be seen as a trustworthy partner and contributor.

at this point i think you should imo try to change the tone of this discussion and probably focus on how goals can be achieved with scribus, rather than trying to force your view on a specific tool.

shorty back to one of your concerns. it's not a "text editor," because you are supposed to edit your text in the frame. your naming proposal would imo be a wrong signal to the beginners (i think that the command was called "edit text" in the past and it was a bad idea: "edit text" is what happens when you press the "e" key while a frame is selected).
from your own sayings, you are using the SE multiple times a day. but if you're such a power user you will be using the in frame editing thousands of time during the same day.
that's the "normal" way of editing a text in scribus! for you too.

Nermander

The point of the tory editor is to edit the contents. Not to format it. It's not called Story formatter.

I am quite sure the background is that in traditional production the editing of the contents is done separately from the layout, because the skills for these tasks are different.

jack_cat

#7
" in traditional production the editing of the contents is done separately from the layout,"
"The point of the tory editor is" .... ????

Thank you, duly noted, and I apologize if I am making waves.
I am posing a technical proposal which is being mis-interpreted as an
attack on the aesthetics of the program design, and I am being misunderstood.
I am not being argumentative, I am pointing out a useful function for a useful tool.

The roots of the Scribus plan are clearly in "traditional production".
Yet this really no longer exists for many of us. 
I have the 1993 Chicago style manual, well into the computer age, and it is laughably
out of date. Traditional production is a dinosaur. We are dealing with a new world,
and in this new world, Scribus can emulate the dinosaurs, or evolve.
Personally, I have chosen Scribus as a tool which can do what I want it to,
not because it is a traditional production tool: DIY publishing is NOT traditional
production, and I don't need it to be. I am not that user.

I am saying that a good tool in the toolbox could be
sharpened on yet another edge, and thereby become a better tool.
Sharpening that edge should be neither difficult nor dangerous,
and so far, no _technical_ reasons have been offered that stand in the
way of this: the reasons which have so far been offered for rejecting
my proposal appear to be purely aesthetic:
"Story Editor is not intended to be used in this way."
Why is that a valid response? I do use it in that way.
It can be used in that way. If something can be done,
someone will do it. This is one of the main reasons why I am a Scribus user:
I am used to making programs do things that they weren't designed for
in order to achieve my own artistic goals. It's not different
from modifying a shop tool. In this particular case I don't
have the skill to modify the tool, but I see the potential
loud and clear, as with any other tool that I use daily.

Thank you for the opportunity for a valuable discusssion,
and I appreciate your consideration for my point of view as a dedicated user.
jack_cat

Nermander

As has been mentioned before, the story editor is written in a way that it is not easy to change it. Someone would have to write a completelty new editor to get functionality you are asking for.

People have been asking for a rewrite of the story editor for years and years. Your proposal is not the first, and likely not the last. That is why we who have been following the Scribus developement over the years feel "Here we go again".

utnik

hi jack_cat

as you mention dinosaurs, i can't resist to point out that the whole text engine has changed and the 'text properties' palette is completely new since scribus 1.5.3.

you're working with 1.5.2 and you're lamenting about in-frame editing and the way the 'properties' palette works – what exactly is this all about? nobody will introduce new features into an old development version!

scribus is not perfect, i know that. but it is good in many ways and it works better for people who are aware of the limitations and know how to avoid them...

utnik

a.l.e

hi jack_cat

you're doing it again· you're teaching us what life looks like, instead of first trying to understand how the current situation is, what has already been done, where we would like to go.

still, i will try to keep it positive.

we have made it clear, that if we want the story editor to shine, a rewrite is needed.
proposal for improvements can be done, there are even chances that somebody implements part of them but, personally, i'm not interested in that at all (really: it's a bad use of scarce resources: the result will not be significantly better).

also, programming a new story editor is not a huge thing. it's probably a straight forward work.
the hard part is to program it the right way.

- what should it do?
- how?

as you say, the editorial world has changed and the story editor feels like a dinosaur.

so the first question is: what should the story editor do, in a modern world?
we need a description of what it is and one or more use cases.
then we need to check and validate them.

the narrower the use cases, the easier it will be to program it.

in the past i've discussed the topic with some power users and we found some ideas you might find inspiring:

- the only formatting that you can apply in the SE are character and paragraph styles.
- no wysiwyg at all.
- the formatting (for sure the styles, possibly also other styles) are shown in place with some sort of markup (we thought of something like the html tags, but not editable and as a gray superscript that does not interfere with the flow of the text)
- if you select a word in the SE, it should stay selected in the frame so that you can apply formats from the PP (the two might even be synchronized)

as said, take it just an inspiration, as an information about what has already been discussed.
before you have formalized one or more use cases, avoid telling us what you like and dislike in there.

we first need to make clear what we want to solve, before we look for a solution.

i think that if you have never done so, you might now need to get some information about use cases.
an interesting read might be https://en.wikipedia.org/wiki/Use_case .
it's a bit long and the methodologies presented are often overkill for us (as an example, i don't think you will need to draw any schema... text should be enough)
if you search for "use cases" you will find lots of articles and tutorials. pick one that looks simple enough : - )

that's life: sometimes you bring up an idea and everybody falls in love with it and it will be implemented before you even notice; other times you will need to so some hard work before your dream comes true.

ciao
a.l.e