View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0004813 | Scribus | Story Editor / Text Frames | public | 2006-12-14 09:30 | 2006-12-21 23:44 |
Reporter | christoph_s | Assigned To | avox | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Platform | x86 | OS | Linux | OS Version | SuSE 10.1 |
Product Version | 1.3.4cvs | ||||
Fixed in Version | 1.3.4cvs | ||||
Summary | 0004813: Text effects (colours) are only applied to visible text | ||||
Description | Text effects like colours, shadows) are only applied to visible text. In the frame on the screenshot I applied different text effects to a text frame and enlarged the frame two times. As you can see, the last parts (invisible before the last change) is black, another part (invisble before first enlargement) is red with a shadow. The major part (visible all the time) has also lower saturation. So I have three different kinds of text effects, depending on the visibility of text at a given time. | ||||
Tags | No tags attached. | ||||
Patch | |||||
related to | 0003261 | confirmed | Changing text alignment from the properties palette does behave weird sometimes |
2006-12-14 09:31
|
|
|
How does 1.3.3.x behave? The alternative would be to apply those changes to the whole story, including preceding and following linked frames. |
|
I think it should not matter whether the text is visible or not when we need to apply any kind of effect or formatting to it. The frame is only a window that shows part or totality of the text (or image). The selection is the most important thing here. If someone has clicked into a frame and make "select all" then, any settings applied to that selection will affect the selection. If a user has selected a few paragraph, visible or not in that frame but nonetheless existing, (this can be done with a key-combination as well) then applied settings affect this part of the text. It's sometimes very useful to work efficiently on some formatting without actually having to see all what you get. Power users know what they'll get: they format and then move around with the frames. Depends mostly on how you work. |
|
Clicking into the frame and pressing Ctrl-A works as expected: even the invisible text will get changed. The question is what to do if you are not in text edit mode and only have the textframe itself selected. |
|
I see. I was not aware we could change text color without actually selecting it. I think this can lead to mistakes. Can we take this feature away? To me, having this possibility is in no way a plus. I understand we can format a frame like that. This is ok. But the text? More or less, it could be considered as the false bold and italic issue. Other thoughts? |
|
IMHO, selecting a frame is the same as selecting a text with Ctrl+A. Let's think about it. You can apply formatting to the visible text, and the visible text only. Then a slight change in kerning or applying hyphenation, deleting a word or a letter will result in different formatting within the text frame. Therefore, selecting one text frame should have the same effect as Ctrl+A, even if the text flows across many frames. |
|
Well... I disagree! :) My experience of formatting would tell me to avoid working that way. I think text formatting should be available only with the content tool. Then, if you wish, you hit CTRL-A and you apply the formatting you want. Since Scribus is working like that for a long time it's a hard call to ask to take it away. But I think we should consider that issue from another angle as well: productivity. At the moment, if I am not mistaken, the content tool is only available when a frame is selected. It is not possible to grab that tool and click in a frame to edit the text. This is under-efficient imo. These issues are related. It's because of this actual behaviour that some users would like to format text with the Select Tool and the Properties Palette. But this way will always be limited and sooner or later you need to get access to the Content tool to perform finer formatting, applying lots of different stylesheets, enrich text, etc. In my view, there should not be that many doors to text formatting. Select tool should not allow to format text. Only content tool should allow that. Or the SE, of course. Am I too rigid? |
|
I agree ... to some extent. I see the use of the select tool for formatting as a quick and dirty way to apply formatting, nothing else. One possibility is, as you suggest, removing the capability, but then expect hundreds of help requests on the mailing list ;) If it is kept, it should work as "Select All", IMHO. |
|
Ok, so is there a consensus that neither Ctrl-A nor the select tool should affect only the visible characters in a frame? If I remove that the only way to achieve that effect were to select the visible characters manually and apply the change then. If that is so, I'd make the select tool affect the story's default style (currently there's no good way to do that). This means that both the select tool and Ctrl-A would affect the whole story, but the select tool only indirectly: if the user applied some formatting with the content tool before, this will stay if the story's default style is changed. |
|
"If I remove that the only way to achieve that effect were to select the visible characters manually and apply the change then." Seems to be the "natural" way to me. "if the user applied some formatting with the content tool before, this will stay if the story's default style is changed." Is this behaviour reasonable? I'm not sure. If, as I assumed, the select tool serves as a quick and dirty way to apply formatting to larger amounts of text, then it should behave "dirty" amd overwrite all previous formatting. The user should be warned to apply it. OTOH, if previous formatting stays intact, this will most likely cause confusion. But of course I may be wrong ;) |
|
>>>Ok, so is there a consensus that neither Ctrl-A nor the select tool should affect only the visible characters in a frame? I agree with that as well. Consensus! I'll get back with more comments about the story's default style. I'd like to give it some more thougths. Be back soon. |
|
IMO C-A should affect all chars in a story, and a selected frame should affect all chars in the frame. IIRC ID works like that too but its awhile since I tested. |
|
Just checked. ID works as if the user had selected all text and formats even the invisible part of the text. Enlarging the frame afterwards shows the text has been completely formatted. When you say "should affect all characters in a frame" do you mean "visible or not" or only the visible part of the text? |
|
I meant visible. What does ID do when its a linked frame? In any, case, I support what ID does here. I found it always worked well with ID1.x and ID2.x before I switched to Scribus. |
|
When frames are linked, ID doesn't allow to edit text with the Select Tool. The Type Palette is greyed. You have to take the Type Tool to be able to format your text. I think this behaviour is expected and is meant to avoid errors. A linked frame could be anywhere else in a document and changes could easily go unnoticed. Select Tool = select all on a single frame, no matter whether you see whole or part of text. Type Tool (Content Tool in Scribus) = you can edit thoroughly but you have to make a text selection. You can apply formatting to linked text. I would welcome such behaviour in Scribus. To make that fully usable, I would welcome a [ Create Style ] button in the Properties palette that would pick the formatting and create a style right away, only asking for a name. It has to be so simple that user do use it. The "quick an dirty way" is the best way of rapidly testing any kind of text formatting, I agree, and picking up the settings automagically is just what we use computer for. That way, Scribus would be ahead of a few other DTP apps! :) |
|
changing textstyle in select mode now only affects the story's default style. If the story has direct paragraph or character formatting, that will take precedence over this setting. I might remove the concept of "story's default style" later; it might be too obscure to be useful. |
Date Modified | Username | Field | Change |
---|---|---|---|
2006-12-14 09:30 | christoph_s | New Issue | |
2006-12-14 09:31 | christoph_s | File Added: text-colours.png | |
2006-12-14 10:37 | fschmid | Status | new => assigned |
2006-12-14 10:37 | fschmid | Assigned To | => avox |
2006-12-14 16:23 | avox | Note Added: 0013923 | |
2006-12-16 20:59 | avox | Status | assigned => feedback |
2006-12-16 21:11 | louisdesjardins | Note Added: 0013970 | |
2006-12-16 21:12 | louisdesjardins | Note Edited: 0013970 | |
2006-12-16 21:41 | avox | Note Added: 0013972 | |
2006-12-16 22:12 | louisdesjardins | Note Added: 0013974 | |
2006-12-18 13:04 | christoph_s | Note Added: 0013994 | |
2006-12-18 14:55 | louisdesjardins | Note Added: 0014006 | |
2006-12-18 15:03 | christoph_s | Note Added: 0014007 | |
2006-12-18 15:47 | avox | Note Added: 0014008 | |
2006-12-18 15:57 | christoph_s | Note Added: 0014012 | |
2006-12-18 16:39 | louisdesjardins | Note Added: 0014016 | |
2006-12-18 16:44 | cbradney | Note Added: 0014017 | |
2006-12-18 17:02 | louisdesjardins | Note Added: 0014020 | |
2006-12-18 19:29 | cbradney | Note Added: 0014047 | |
2006-12-18 21:27 | louisdesjardins | Note Added: 0014052 | |
2006-12-21 11:42 | christoph_s | Relationship added | related to 0003261 |
2006-12-21 18:18 | avox | Status | feedback => resolved |
2006-12-21 18:18 | avox | Fixed in Version | => 1.3.4cvs |
2006-12-21 18:18 | avox | Resolution | open => fixed |
2006-12-21 18:18 | avox | Note Added: 0014154 | |
2006-12-21 23:44 | avox | Status | resolved => closed |
2015-09-17 20:08 | Kunda | Category | Story Editor / Text Frames => Story Ed/Txt Frames |
2015-09-17 20:12 | Kunda | Category | Story Ed/Txt Frames => Story Editor / Text Frames |