View Issue Details

IDProjectCategoryView StatusLast Update
0005366ScribusStory Editor / Text Framespublic2024-01-09 19:17
Reportermkoren Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
PlatformanyOSanyOS Versionany
Product Version1.3 
Summary0005366: frame break doesn't break paragraph
DescriptionIf you insert a frame break (probably column breaks too, I haven't tried), it doesn't break the paragraph, which means that you can't apply different styles to the last paragraph in one frame and the first in the next.

I don't know if a frame break that doesn't break the paragraph would ever be desirable, but in most cases you certainly want it to since a frame is a "bigger" unit than a paragraph (breaking to the next section, etc.)

This is a significant design problem, due to the issue with applying styles. You can sometimes work around it by adding an extra paragraph break at the end of the previous frame, but that's

a) ugly, and
b) not possible if you're at the very bottom of the first frame already (which can change any time with reflow, so you won't even know). Yuck.
Steps To Reproduce- Make 2 linked frames
- add some text in the first, then a frame break
- add some more text in the second, stopping to trigger a redraw so you can see it :)
- try to apply a style to the paragraph at the end of one frame or beginning of the next

-> both paragraphs get the new style.
Tags#please_test, discussion, linked frames
Patch

Relationships

related to 0005553 acknowledged column-/frame-breaks add line break to the next column/frame 
has duplicate 0008749 closedjghali After an explicit frame-break, the first line of the paragraph is not indented as a first list 
has duplicate 0008892 closedjghali left indent is missing after the line/column/frame break 
has duplicate 0017112 closedjghali Paragraph style does not work on first paragraph after frame break 
related to 0010024 closed In Linked Text Frame the Frame Break add extra blank line in the second frame's firs column 

Activities

avox

2007-02-19 06:25

administrator   ~0015314

This is intended. IMHO framebreaks, colbreaks and linebreaks are used to finalize the textflow of a document. Editing text will always cause rework for that.

If you want a new paragraph, create one and put a framebreak at the beginning of the next. It might help if you put a space scaled to 0.1 pt before the framebreak.

cbradney

2007-02-19 12:10

administrator   ~0015321

mkoren, please update your version to the one you are testing. "1.3" is not useful for us to know. If its a cvs version, please indicate the current date from Help About.

mkoren

2007-02-20 00:55

reporter   ~0015334

Last edited: 2007-02-26 22:46

I'm on 1.3.3.6, but I didn't say more as I thought this was a design issue.

>>> IMHO framebreaks, colbreaks and linebreaks are used to finalize the textflow of a document. Editing text will always cause rework for that.

Not only for that. If you're at the end of a section, you want to end the paragraph _and_ the page and start anew on the next page. Or in this case, I have a chart made of many small frames linked together, and I use breaks to get between them.

>>> If you want a new paragraph, create one and put a framebreak at the beginning of the next. It might help if you put a space scaled to 0.1 pt before the framebreak.

This is not reliable. If the text before the break goes to the bottom of the frame, adding a parsep+framebreak would leave an empty frame. (This is the case in my chart.) See my description above.

Anyway, that sounds more like a hack than an intended usage. What you want is _one_ break that = parsep+framebreak, but without adding a blank line like that combination.

mkoren

2007-02-26 22:57

reporter   ~0015404

Ok, I see what you mean about using them to finalize layout. But there are two things that break to the next line, linebreaks and paragraph breaks, i.e. you can go to the next line with or without starting a new paragraph (which can have a new style, etc...). You can't currently do that cleanly for frame breaks....

It seems like there need to be two more breaks, e.g., the existing frame break is to x as linebreak is to parsep. This "x" would be a normal semantic divider just like a parsep, not a last-minute adjustment, and would start a new paragraph in the next frame. It could possibly even be used to break sections for some kind of section-based styling mechanism in the future.

Do you see my point?

rubikwuerfel

2007-10-28 15:30

reporter   ~0017780

IMHO, bug 0005553 seems to be a duplicate of this and points out an even bigger problem:
When inserting a frame break into a text that looks like this in the story editor (two paragraphs, should appear in two linked frames):
[Style foo] Lorem ipsum
[Style bar] Dolor sit

Now we enter a frame break because only part of the second par would appear in frame 1 (avox called this "finalize the textflow of a document"):
[Style foo] Lorem ipsum<frame break>
[Style bar] Dolor sit

What happens is:
The page break happens as wanted after "ipsum", BUT there's a blank line now in the second frame, just before the second paragraph starts with "Dolor". This happens on 1.3.3.9, please ask if you need more information.

mkoren

2007-11-16 20:31

reporter   ~0017942

The issue raised in 0005553 just shows that neither order of paragraph break + frame break is robust: if you put the frame break first, you get a blank line in the next frame, but if you put the paragraph break first, you risk getting a blank frame if the paragraph happens to be at the end of the first frame.

This wouldn't be an issue if there were a single kind of break that breaks both the paragraph and the frame. The example given in the last note hides the fact there are really two breaks involved:

[Style foo] Lorem ipsum<frame break><paragraph break>
[Style bar] Dolor sit

The paragraph break is only necessary because the frame break doesn't end the paragraph, but it also includes a line break. (And you can't just ignore it because you might actually want a blank paragraph at the beginning of the new frame.) So we need one of two things: a break that _only_ ends a paragraph, but doesn't break to the next line:

[Style foo] Lorem ipsum<non-linebreaking paragraph end><frame break>
[Style bar] Dolor sit

(but the problem there is what to do if it occurs alone), _or_ one break that does both:

[Style foo] Lorem ipsum<frame breaking paragraph end>
[Style bar] Dolor sit

ale

2010-01-27 17:42

manager   ~0023148

since scribus does have forced justification, i don't see any case where it would be necessary to have a frame break which does not break the paragraph.

even if i agree with avox that the current implementation is much "cleaner", it is imho only acceptable if there is a way to combine paragraph and frame breaks in a way that the text flow is broken without having any empty paragraph.
(inserting a space char with height 0.1 is not a solution :-)

so: if a proper solution can be found, i suggest to keep the current behavior, if not, i would really prefer to have frame breaks which do break the paragraph.

subeditor

2010-04-20 08:19

reporter  

forced.jpg (246,680 bytes)   
forced.jpg (246,680 bytes)   

subeditor

2010-04-20 08:26

reporter   ~0023731

Last edited: 2010-04-20 08:46

One more vote for combine column/frame (not line!) break with paragraph break.
Pics attached (http://bugs.scribus.net/file_download.php?file_id=4705&type=bug) illustrates another bug related to this topic: when I resize frame with frame brake in it, justification randomly changes from justified to forced and back.
Maybe this should be posted as separate bug (catched with Scribus 1.3.7svn on WinXP).

JLuc

2016-04-13 17:09

developer   ~0040140

Last edited: 2016-04-13 17:14

I agree with mkoren interesting proposal. It seems like there need to be one more breaks, e.g. x-break. The existing frame break is to x-break as linebreak is to parsep. This x-break would be a normal semantic divider just like a parsep, not a last-minute adjustment, and would start a new paragraph in the next frame.

JLuc

2016-04-13 17:56

developer   ~0040144

In 0005553, i proposed to keep using the paragraphSeparator and add it a break property : values could be colum or frame.

eg :
<para PARENT="Default Paragraph Style" break="frame"/>
<para PARENT="Default Paragraph Style" break="column"/>

This would also fix the "blank space on top of 2nd frame" issue cf 0010024

eudoxos

2017-06-22 19:56

reporter   ~0044076

One more option to solve the confusion might be:
* page-break always implies frame break and paragraph break;
* frame break always implies paragraph break;
* contiguous group of breaks (of any kind) are always collapsed into the higest one: (a) any group of adjacent breaks containing page-break will break page (with implied frame and paragraph break); (b)any group containing at most frame-break will make single frame break (with implied paragraph break); (c) any group of paragraph break will make one paragraph break (the last one is optional, perhaps empty paragraph are admissible).

JLuc

2017-06-23 04:31

developer   ~0044077

Couldnt there be situations where we do NOT want to have an other or new paragraphe style applied to the part of text AFTER the break ? But maybe there are workaround for these situations, not inserting a break but an overflaping frame ?

eudoxos

2017-06-23 12:13

reporter   ~0044079

The next paragraph after the break can have the same style. Otherwise I don't see what you mean. One can always start the new paragraph after the break without indent (like in LaTeX, \newpage\noindent ...) if you want to pretend new paragraph was never started. But I can't imagine much the use-case.

IMHO what is much more common is the problem already described above. The following three will each cause different output, even though the intent is (very likely) the same in all cases: two paragraphs, with frame break in-between them, something which is currently impossible to achieve due to spurious paragraph at the end of the first frame, or the beginning of the second frame, or both (each | is a paragraph in the story editor):

   | lorem ipsum
   | [frame-break]
   | dolor sit amet

   | lorem ipsum [frame-break]
   | dolor sit amet

   | lorem ipsum
   | [frame-break] dolor sit amet

automorphism

2024-01-09 19:17

reporter   ~0050859

This still happens even if you break between paragraphs.

Issue History

Date Modified Username Field Change
2007-02-18 22:19 mkoren New Issue
2007-02-19 06:25 avox Note Added: 0015314
2007-02-19 12:10 cbradney Note Added: 0015321
2007-02-20 00:55 mkoren Note Added: 0015334
2007-02-26 22:46 mkoren Note Edited: 0015334
2007-02-26 22:57 mkoren Note Added: 0015404
2007-10-28 15:30 rubikwuerfel Note Added: 0017780
2007-10-28 17:39 christoph_s Relationship added related to 0005553
2007-11-16 20:31 mkoren Note Added: 0017942
2010-01-27 00:03 jghali Relationship added has duplicate 0008749
2010-01-27 17:42 ale Note Added: 0023148
2010-02-28 20:33 jghali Relationship added has duplicate 0008892
2010-04-20 08:19 subeditor File Added: forced.jpg
2010-04-20 08:26 subeditor Note Added: 0023731
2010-04-20 08:46 subeditor Note Edited: 0023731
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
2016-04-13 16:04 Kunda Relationship added related to 0010024
2016-04-13 17:09 JLuc Note Added: 0040140
2016-04-13 17:14 JLuc Note Edited: 0040140
2016-04-13 17:56 JLuc Note Added: 0040144
2016-04-14 14:15 Kunda Tag Attached: linked frames
2016-04-30 14:02 Kunda Tag Attached: #please_test
2016-05-16 00:43 Kunda Tag Attached: discussion
2017-06-22 19:56 eudoxos Note Added: 0044076
2017-06-23 04:31 JLuc Note Added: 0044077
2017-06-23 12:13 eudoxos Note Added: 0044079
2024-01-09 19:01 jghali Relationship added has duplicate 0017112
2024-01-09 19:17 automorphism Note Added: 0050859