View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005553||Scribus||General||public||2007-04-14 12:12||2016-05-06 19:32|
|Summary||0005553: column-/frame-breaks add line break to the next column/frame|
|Description||If one inserts a column/frame-break it should replace the line-break at the end of the paragraph. However currently it adds a line-break resulting in an empty line at the beginning of the next frame/column, if the break was set at the end of a paragraph.|
|Steps To Reproduce||Link two text-frames|
Type two paragraphs in the first one
Insert a frame-break at the end of the first paragraph
The second paragraph will move into the second frame and display an empty line at the top, which should not happen.
|Tags||No tags attached.|
|related to||0008749||closed||jghali||After an explicit frame-break, the first line of the paragraph is not indented as a first list|
|related to||0008892||closed||jghali||left indent is missing after the line/column/frame break|
|has duplicate||0010024||closed||In Linked Text Frame the Frame Break add extra blank line in the second frame's firs column|
|related to||0005366||new||frame break doesn't break paragraph|
One can work around this by placing the break in front of the next paragraph. Maybe it would be a bit more intuitive and consistent with other applications to implement it the way that one places the break after the paragraph.
What currently happens is:
<end of paragraph> (in the second frame)
The problem with the current implementation is that it is less robust then the one above. If for example one alters the box-size or font-size, it can happen that the last line of the last paragraph in the first box is exactly the last possible line in the box. If one places a break at the beginning of the next paragraph, the second box will stay empty, because the break was moved to the second box.
This seems to be a duplicate of bug 0005366, if I'm not mistaken.
||What is the status of this bug? :-)|
It has some duplicate 0010024
Related to: 0008749, 0008892
Perhaps the first reported bug: 0005366
Yep I reproduce this issue but its not easy to find a better way since as long as "frame break" is a special glyph, it will be part of a paragraph, and the EndOfParagraph will be AFTER the frame break; and of course, as a consequence, the end of paragraph is at the begining of the new frame.
As a workaround, or rather an other way of doing, is to insert the frame break AFTER the end of line paragraph = at the beginning of following paragraph.
Doing so, some of the paragraph properties as "vertical space before" will be used for the first part of paragraph and will be lost for paragraph main body. Of course.
There could be another solution : it would require to change the "frame break" into a "End of Paragraph" property (instead of being a special glyph)...
AMOF this very-last option is also what mkoren proposes in 0005366 : It seems like there need to be on more 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.
|2007-04-14 12:12||rabauke||New Issue|
|2007-05-02 18:31||rabauke||Note Added: 0016077|
|2007-10-28 15:14||rubikwuerfel||Note Added: 0017779|
|2007-10-28 15:14||rubikwuerfel||Note Edited: 0017779|
|2007-10-28 17:39||christoph_s||Relationship added||related to 0005366|
|2008-02-05 20:54||christoph_s||Status||new => acknowledged|
|2011-07-20 07:57||Mike||Note Added: 0026615|
|2011-07-20 08:05||Mike||Note Added: 0026616|
|2016-04-13 16:03||Kunda||Relationship added||related to 0008749|
|2016-04-13 16:03||Kunda||Relationship added||related to 0008892|
|2016-04-13 16:03||Kunda||Relationship added||related to 0010024|
|2016-04-13 16:08||Kunda||Tag Attached: duplicate|
|2016-04-13 17:03||JLuc||Relationship replaced||has duplicate 0010024|
|2016-04-13 17:06||JLuc||Note Added: 0040139|
|2016-04-13 17:12||JLuc||Note Added: 0040142|
|2016-04-13 19:41||JLuc||Note Edited: 0040142|
|2016-05-06 19:32||JLuc||Tag Detached: duplicate|