View Issue Details

IDProjectCategoryView StatusLast Update
0011740ScribusUsabilitypublic2021-09-26 12:56
ReporterJLuc Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
Status feedbackResolutionopen 
Product Version1.5.0svn 
Summary0011740: Style effect of deleting end of paragraph
DescriptionWhen text1=paragraph 1 style is paragraphstyle1
and text2=paragraph 2 style is paragraphstyle2
if you delete end of paragraph at the end of paragraph 1
then text1 style becomes paragraphstyle2.
Ie : when deleting endofparagraph, scribus applies paragraphstyle2 to paragraph1.

Doing so, it deletes ALL character-related styles (as font, bold or italic) of the text in the first paragraph and applies to it the default character styles of the paragraphstyle2.

Problem is :

- If the text1 had multiple fonts and glyph effects, it is a drama to have all this work lost.

(- furthermore, undo is not working in such a case : 0011634 and 0011767)

Scribus today behaviour when deleting end of paragraph is often not the desired behaviour. When deleting endofparagraph, user just wishes to delete the change-line-carriage-return, but not change the styles of the text. If user wants later to apply paragraph style to the whole paragraph, he can do so with a later action.

Since paragraph styles include both paragraph and glyph characteristics, ONLY the *paragraph characteristics* of paragraphstyle2 should apply to the text1 once it is merged with text2.
Tags#pending, MABs
PatchNo

Relationships

related to 0011974 confirmed Removing a paragraph via backspace in the SE switches a previously "styled" paragraph to "No Style" 
related to 0016644 new Editing the end of a line / the whole line removes all text properties 

Activities

JLuc

2013-09-22 13:57

developer   ~0030610

Last edited: 2013-09-27 12:56

Sorry, after testing more, the bug report does not report the situation truthfully. AMOF, this issue is not terribly critical. Last time i edited a document, i had a really bad scribus behaviour relating to delete EndOfParagraph but i have to wait till next issue to reproduce and describe it more precisely because this report doesnt spot the real problem.

Note : EOP = end of paragraph = paragraph separator = PARSEP

Here is better description of the in-this-report-described behaviour, in 1.5svn :

- Localy applied styles in text1 are kept OK when deleting End Of Paragraph 1. Before and after deleting, these styles overwrite the character attributes defined in para1style or para2style.

- Character attributes not localy applied inherit the character attributes defined in the applied paragraph style

1) Thus : when the EOP is deleted, applied paragraph style changes for text1, and so are the inherited character attributes : before deleting, they inherit of style1 and after, they inherit style2

2) This happens whether these attributes have been explicitely defined in the applied paragraph style BUT also when these attributes have NOT been defined in the character style of the paragraph style (that is, when it is NOT based on a character style and/or when none of the character attributes have been modified in the character style pane).

I upload sample selfdocumented "deletingEOP.SLA" in case sbd want to test further.
I'm not sure this is a bug or not, but for sure 2) is more a bug than 1).

It's kind of a bug from a user's point of view because the user sees the style change when he has not asked that. This behaviour is only logic from a data structure point of view.
So it would be nice at least to be able to apply another more user-obvious behaviour : keeping style1 inherited character attributes applied on text1 when deleting EOP at the end of paragraph 1.
It would request to apply the default character attributes of paragraph style1 "inline" around all text1 when deletin EOP - without deleting/overwriting any of the more locally applied character styles -.

That user-friendly behaviour could be obtained :
- allways, as the normal default DEL-EOP behaviour
- or only when the ALT modifier is pressed when deleting the EOP (clicking ALT+DEL instead of DEL).
- this could be the behaviour when the paragraph style 2 is NOT based on a character style and has no overwriten attributes (character style pane has not been used).
- paragraph styles could have another boolean property / checkbox : "dont use character styles" that would totally neutralize their character style pane and attributes.
- Scribus could have a preference "dont use character styles for paragraph styles"

JLuc

2013-09-22 14:49

developer  

deletingEOP.sla (41,167 bytes)

JLuc

2013-09-27 08:26

developer   ~0030634

Last edited: 2013-09-27 13:07

Cezaryece has worked on this issue and proposed an alternative (22 feb 2013) :
http://scribus-ece.info/News/Merging%20paragraphs

The relevant commit is dee26785d5f354850b85 (19 feb 2013) whose log is :
"Change of getting character style at end of paragraph (from last character, not from paragraphStyle).
+ Fix for normal Word Tracking change from PP."

I upload the whold diff in cezariece_potential_fix.diff but the relevant part is this little change in /text/storytext.cpp around line 825 :

    if (text(pos) == SpecialChars::PARSEP)
- return paragraphStyle(pos).charStyle();
+ {
+ if ((pos == 0) || text(pos-1) == SpecialChars::PARSEP)
+ return paragraphStyle(pos).charStyle();
+ else //get charStyle from last char in paragraph
+ --pos;
+ }

It gives hope that it is possible to easily change behaviour localy, without refactoring whole style management but i cannot test it because i cannot compile right now.

Cezariece describes it as : it "replaces style in next PARSEP with style from deleted PARSEP"

This solution is close to LibreOffice and MSWord's solutions since both apply STYLE1 to text2 after the merge (Note : the local formating of text2 is overwriten with LibreOffice. Is it the same with cezariece's solution ?).

But when deleting EndOfParagraph1, the text1 looses both its paragraph related characteristics but also default glyph-related characteristics.
Could there not be another goal to reach : to keep all 1st paragraph char-related effects, both inline defined and due to the paragraph default
? It seems this is not possible, or not clean, because if the charcharacteristics of the paragraphstyle1 are changed, how would this text1 style evolve when it is not anymore linked to paragraphstyle1 ? Thats impossible.

JLuc

2013-09-27 08:27

developer  

cezariece_potential_fix.diff (4,768 bytes)   
diff --git a/Scribus/scribus/scribusdoc.cpp b/Scribus/scribus/scribusdoc.cpp
index d2af346..e0469e4 100644
@@ -9029,6 +9029,13 @@ void ScribusDoc::itemSelection_SetTracking(int kern, Selection* customSelection)
 	itemSelection_ApplyCharStyle(newStyle, customSelection, "TRACKING");
 }
 
+void ScribusDoc::itemSelection_SetWordTracking(double track, Selection* customSelection)
+{
+	CharStyle newStyle;
+	newStyle.setWordTracking(track);
+	itemSelection_ApplyCharStyle(newStyle, customSelection, "WORDTRACKING");
+}
+
 void ScribusDoc::itemSelection_SetLineSpacingMode(int m, Selection* customSelection)
 {
 	ParagraphStyle newStyle;
diff --git a/Scribus/scribus/scribusdoc.h b/Scribus/scribus/scribusdoc.h
index 078a2f5..e1f1a02 100644
@@ -1080,6 +1080,7 @@ public:
 //	void chAbStyle(PageItem *currItem, int s);
 
 	void itemSelection_SetTracking(int us, Selection* customSelection=0);
+	void itemSelection_SetWordTracking(double us, Selection* customSelection=0);
 	void itemSelection_SetFontSize(int size, Selection* customSelection=0);
 	//void FlipImageH();
 	//void FlipImageV();
diff --git a/Scribus/scribus/text/storytext.cpp b/Scribus/scribus/text/storytext.cpp
index 418c4c3..a97e946 100644
@@ -818,14 +818,19 @@ const CharStyle & StoryText::charStyle(int pos) const
 		return defaultStyle().charStyle();
 	}
 	else if (pos == length()) {
-		qDebug() << "storytext::charstyle: access at end of text %i" << pos;
+//		qDebug() << "storytext::charstyle: access at end of text %i" << pos;
 		--pos;
 	}
-	//for notes frames - get style from note text, not from mark
-	if ((pos+1 < length()) && hasMark(pos) && mark(pos)->isNoteType())
-		++pos;
+//	//for notes frames - get style from note text, not from mark
+//	if ((pos+1 < length()) && hasMark(pos) && mark(pos)->isNoteType())
+//		++pos; FIXME - why in fact?
 	if (text(pos) == SpecialChars::PARSEP)
-		return paragraphStyle(pos).charStyle();
+	{
+		if ((pos == 0) || text(pos-1) == SpecialChars::PARSEP)
+			return paragraphStyle(pos).charStyle();
+		else //get charStyle from last char in paragraph
+			--pos;
+	}
 	StoryText* that = const_cast<StoryText *>(this);
 	return dynamic_cast<const CharStyle &> (*that->d->at(pos));
 }
diff --git a/Scribus/scribus/ui/propertywidget_advanced.cpp b/Scribus/scribus/ui/propertywidget_advanced.cpp
index f26932b..b6ef209 100644
@@ -203,6 +203,12 @@ void PropertyWidget_Advanced::displayTracking(double e)
 		return;
 	tracking->showValue(e / 10.0);
 }
+void PropertyWidget_Advanced::displayWordTracking(double e)
+{
+	if (!m_ScMW || m_ScMW->scriptIsRunning())
+		return;
+	normWordTrackingSpinBox->showValue(e * 100.0);
+}
 
 void PropertyWidget_Advanced::handleBaselineOffset()
 {
@@ -247,9 +253,7 @@ void PropertyWidget_Advanced::handleNormWordTracking()
 	{
 		Selection tempSelection(this, false);
 		tempSelection.addItem(i2, true);
-		ParagraphStyle newStyle;
-		newStyle.charStyle().setWordTracking(normWordTrackingSpinBox->value() / 100.0);
-		m_doc->itemSelection_ApplyParagraphStyle(newStyle, &tempSelection);
+		m_doc->itemSelection_SetWordTracking(normWordTrackingSpinBox->value() / 100.0, &tempSelection);
 	}
 }
 
@@ -374,9 +378,9 @@ void PropertyWidget_Advanced::updateCharStyle(const CharStyle& charStyle)
 	displayTextScaleH(charStyle.scaleH());
 	displayTextScaleV(charStyle.scaleV());
 	displayTracking(charStyle.tracking());
+	displayWordTracking(charStyle.wordTracking());
 	displayBaseLineOffset(charStyle.baselineOffset());
 
-	normWordTrackingSpinBox->showValue(charStyle.wordTracking() * 100.0);
 	maxTrackingSpinBox->setMinimum(charStyle.tracking() / 10.0);
 	maxWordTrackingSpinBox->setMinimum(charStyle.wordTracking() * 100.0);
 }
@@ -391,10 +395,10 @@ void PropertyWidget_Advanced::updateStyle(const ParagraphStyle& newCurrent)
 	displayTextScaleH(charStyle.scaleH());
 	displayTextScaleV(charStyle.scaleV());
 	displayTracking(charStyle.tracking());
+	displayWordTracking(charStyle.wordTracking());
 	displayBaseLineOffset(charStyle.baselineOffset());
 
 	minWordTrackingSpinBox->showValue(newCurrent.minWordTracking() * 100.0);
-	normWordTrackingSpinBox->showValue(newCurrent.charStyle().wordTracking() * 100.0);
 	minGlyphExtSpinBox->showValue(newCurrent.minGlyphExtension() * 100.0);
 	maxGlyphExtSpinBox->showValue(newCurrent.maxGlyphExtension() * 100.0);
 	if (newCurrent.maxTracking() < charStyle.tracking())
diff --git a/Scribus/scribus/ui/propertywidget_advanced.h b/Scribus/scribus/ui/propertywidget_advanced.h
index 88e7b93..7c17d37 100644
@@ -52,6 +52,7 @@ public slots:
 	void displayTextScaleH(double e);
 	void displayTextScaleV(double e);
 	void displayTracking(double e);
+	void displayWordTracking(double e);
 
 	void updateCharStyle(const CharStyle& charStyle);
 	void updateStyle(const ParagraphStyle& newCurrent);
cezariece_potential_fix.diff (4,768 bytes)   

JLuc

2013-09-27 13:07

developer   ~0030635

Last edited: 2016-12-17 08:42

After irc discussion, i conclude that my idea of how it should be (detailed in the above comment) is not possible now (at least without radicaly disruptive innovation !).

Cezariece's proposal could be better because it's closer to user's habit (LibreOffice, Word, usw). It'd be even better if it doesnt overwrite the localy=in-glyph applied charstyles (it might be allready so).

Kunda

2016-05-29 03:27

updater   ~0041517

need to relate relevant tickets to this.

Kunda

2016-12-16 21:11

updater   ~0043070

@PeterBenedek This has a dupe, right ?

JLuc

2018-03-23 08:39

developer   ~0045078

There is still an issue with EOP delete. Describe it in another report and close this one.

Issue History

Date Modified Username Field Change
2013-09-22 10:10 JLuc New Issue
2013-09-22 13:57 JLuc Note Added: 0030610
2013-09-22 14:38 JLuc Note Edited: 0030610
2013-09-22 14:39 JLuc Note Edited: 0030610
2013-09-22 14:42 JLuc Note Edited: 0030610
2013-09-22 14:43 JLuc Note Edited: 0030610
2013-09-22 14:44 JLuc Note Edited: 0030610
2013-09-22 14:44 JLuc Note Edited: 0030610
2013-09-22 14:49 JLuc File Added: deletingEOP.sla
2013-09-22 15:32 JLuc Note Edited: 0030610
2013-09-22 15:33 JLuc Note Edited: 0030610
2013-09-22 15:36 JLuc Note Edited: 0030610
2013-09-23 22:42 JLuc Note Edited: 0030610
2013-09-27 08:26 JLuc Note Added: 0030634
2013-09-27 08:27 JLuc File Added: cezariece_potential_fix.diff
2013-09-27 08:28 JLuc Note Edited: 0030634
2013-09-27 08:30 JLuc Note Edited: 0030634
2013-09-27 08:32 JLuc Note Edited: 0030634
2013-09-27 08:36 JLuc Note Edited: 0030634
2013-09-27 09:42 JLuc Note Edited: 0030634
2013-09-27 09:44 JLuc Note Edited: 0030634
2013-09-27 09:45 JLuc Note Edited: 0030634
2013-09-27 09:46 JLuc Note Edited: 0030610
2013-09-27 09:47 JLuc Note Edited: 0030634
2013-09-27 09:47 JLuc Note Edited: 0030634
2013-09-27 09:49 JLuc Note Edited: 0030634
2013-09-27 09:51 JLuc Note Edited: 0030634
2013-09-27 09:52 JLuc Note Edited: 0030634
2013-09-27 09:54 JLuc Note Edited: 0030634
2013-09-27 09:54 JLuc Note Edited: 0030634
2013-09-27 09:57 JLuc Note Edited: 0030634
2013-09-27 10:01 JLuc Note Edited: 0030634
2013-09-27 10:22 JLuc Note Edited: 0030634
2013-09-27 10:23 JLuc Note Edited: 0030634
2013-09-27 10:25 JLuc Note Edited: 0030634
2013-09-27 10:26 JLuc Note Edited: 0030634
2013-09-27 12:56 JLuc Note Edited: 0030610
2013-09-27 13:06 JLuc Note Edited: 0030634
2013-09-27 13:07 JLuc Note Added: 0030635
2013-09-27 13:07 JLuc Note Edited: 0030634
2013-09-27 13:08 JLuc Note Edited: 0030635
2013-10-29 19:32 JLuc Note Edited: 0030635
2016-05-29 03:27 Kunda Note Added: 0041517
2016-05-29 03:28 Kunda Tag Attached: #pending
2016-12-16 21:11 Kunda Note Added: 0043070
2016-12-17 08:40 JLuc Description Updated
2016-12-17 08:40 JLuc Patch => No
2016-12-17 08:42 JLuc Note Edited: 0030635
2018-03-23 08:38 JLuc Tag Attached: MABs
2018-03-23 08:39 JLuc Assigned To => JLuc
2018-03-23 08:39 JLuc Status new => feedback
2018-03-23 08:39 JLuc Note Added: 0045078
2018-03-30 11:32 JLuc Assigned To JLuc =>
2021-06-29 06:51 JLuc Relationship added related to 0011974
2021-09-26 12:56 JLuc Relationship added related to 0016644