View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0006235ScribusGeneralpublic2007-09-19 19:002016-03-28 22:54
ReporterJLuc Assigned Tojghali  
PrioritynormalSeverityfeatureReproducibilityalways
Status closedResolutionfixed 
PlatformPCOSWindows Vista (sometime XP o Me)OS Version1.3.3.9
Product Version1.3.3.9cvs 
Fixed in Version1.5.2.svn 
Summary0006235: bad display of character STYLE when selection is not empty
Descriptioncharacter style in property window
is not appropriate when there selection is not empty.
Steps To Reproducecopied from the IRC :

suppose i have the word boldregular
with bold in bold and regular in regular
and move the insertion carret along these letters.

Try with both an empty selection (simple insert carret) and a non empty selection (insertion carret is at the end of the selection) and see how the property palette's text pane state changes to reflect change of selection content style or insert carret place.

1) as long as the selection is empty, the text pane buttons and styles states in the property window displays the character style of the glyph that is immediately next to the right of the caret character.
That is OK (a correct possible choice).

2) alas, the behaviour is the same when the selection is not empty, and that is not OK because user expects the display to reflect the selection style.

When i select the first bold letter, then the 2 first bold letters, the 3 etc of boldregular,
then the display panel shows 'bold' style until 'bol' is selected,
but it displays regular as soon as all 'bold' letters are entirely selected.
it seems that at this point 1) applies there : PP display state of text OUTSIDE of selection, on the immediate outside right of it.

Issue is that since only bold text is selected, i expect the display to display "bold" state !
Additional Informationfrom irc
<Tsoots> yes and definitely a bug
    behaviour should change when there's a selection
    this stuff has all rewritten in 1.3.4+ so it might be fixed there already
    but feel free to submit a new bug entry for 1.3.3.9
    there's 1.3.3.10 coming soon maybe we can get this one fixed before that

    oh and i tested it here too and it behaves exactly how you told

TagsNo tags attached.
PatchNo

Activities

JLuc

2007-09-20 11:56

developer   ~0017334

tested on 1.3.3.9 (not cvs)

JLuc

2007-09-24 09:26

developer   ~0017386

same with 1.3.3.10svn22/08

JLuc

2008-06-24 14:37

developer   ~0019879

same with 1.3.3.12

JLuc

2009-12-27 01:41

developer   ~0022998

same with 1.3.6svn

Beside : as for me, when some of the letters selected have different fonts, the "font" property should display nothing (or be grayed). Now, it display the font at the right of the caret. Confusing.

JLuc

2010-03-23 21:13

developer   ~0023602

Same with 1.3.6, example :

There is a dingbat enum dot followed with helvetica text.
If only the dot is selected, the property displays the font as being Helvetica
(since Helvetica is the font on the right of the selection). Confused !

JLuc

2012-09-14 23:07

developer   ~0028929

Last edited: 2013-01-01 20:52

 Same with 1.4.1 and same with today 1.5 svn : propertie displayed are not accurate when selection is not empty since they reflect the properties of the glyph at the right of the selection, and not the properties of the selected text.

Kunda

2016-02-12 16:19

updater   ~0038668

Jluc, I'm having trouble understanding how to reproduce this bug. Can you retest and report how it effects current 1.4.6 and 1.5.1svn ? Thanks mate

JLuc

2016-02-13 12:23

developer   ~0038696

Nothing has changed in scribus relating to this. I updated the description of the report. Can you try again to understand the issue Kunda ?

JLuc

2016-03-28 21:02

developer  

BOLDregular.jpg (34,375 bytes)   
BOLDregular.jpg (34,375 bytes)   

JLuc

2016-03-28 21:27

developer  

middle of text.jpg (27,932 bytes)   
middle of text.jpg (27,932 bytes)   

JLuc

2016-03-28 22:22

developer   ~0039481

So it happens the bug only happens when selection is done from left to right and *with the keyboard* (not the mouse)...

i confirm it's now fixed

Kunda

2016-03-28 22:54

updater   ~0039482

Nice. Love seeing 9 year old bugs be closed.
jghali committed fix in 21132
and thanks to jluc's follow-up tenacity

Issue History

Date Modified Username Field Change
2007-09-19 19:00 JLuc New Issue
2007-09-20 11:56 JLuc Note Added: 0017334
2007-09-24 09:26 JLuc Note Added: 0017386
2008-02-05 21:30 christoph_s Status new => confirmed
2008-06-24 14:37 JLuc Note Added: 0019879
2009-12-27 01:41 JLuc Note Added: 0022998
2009-12-28 00:13 christoph_s Status confirmed => assigned
2009-12-28 00:13 christoph_s Assigned To => avox
2010-03-23 21:13 JLuc Note Added: 0023602
2012-09-14 23:07 JLuc Note Added: 0028929
2013-01-01 20:52 JLuc Note Edited: 0028929
2016-02-12 16:17 Kunda Patch => No
2016-02-12 16:17 Kunda Steps to Reproduce Updated
2016-02-12 16:19 Kunda Note Added: 0038668
2016-02-13 12:21 JLuc Steps to Reproduce Updated
2016-02-13 12:23 JLuc Note Added: 0038696
2016-02-13 12:23 JLuc Steps to Reproduce Updated
2016-02-13 12:24 JLuc Steps to Reproduce Updated
2016-02-13 12:25 JLuc Steps to Reproduce Updated
2016-03-28 21:02 JLuc File Added: BOLDregular.jpg
2016-03-28 21:27 JLuc File Added: middle of text.jpg
2016-03-28 22:17 jghali Status assigned => resolved
2016-03-28 22:17 jghali Fixed in Version => 1.5.2.svn
2016-03-28 22:17 jghali Resolution open => fixed
2016-03-28 22:17 jghali Assigned To avox => jghali
2016-03-28 22:22 JLuc Note Added: 0039481
2016-03-28 22:22 JLuc Status resolved => closed
2016-03-28 22:54 Kunda Note Added: 0039482