|
|
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. |
|
|
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. |
|
|
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. |
|
|
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? |
|
|
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. |
|
|
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 |
|
|
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. |
|
|
forced.jpg (246,680 bytes) |
|
|
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). |
|
|
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. |
|
|
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 |
|
|
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). |
|
|
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 ? |
|
|
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 |
|
|
This still happens even if you break between paragraphs. |
- Anonymous
