View Issue Details

IDProjectCategoryView StatusLast Update
0007629ScribusStory Editor / Text Framespublic2017-12-31 10:12
Reporterbrunod Assigned To 
PrioritynormalSeveritytextReproducibilityhave not tried
Status newResolutionopen 
PlatformX86 32bitOSUbuntu (latest) 8.04OS Version1.3.5 svn
Product Version1.3.5svn 
Summary0007629: RFE : No automatic spacing in unbreakable space (// thin & other spaces)
DescriptionWhen using right and left align in a text, Scribus stretches the sentence by growing spaces between them.
In case of unbreakable space (ctrl-space) i find it unappropriate.
I would prefer unbreakable space being considered as usual letter in this case to avoid a big hole between the two parts that should remain together.
This must certainly be considered including halves and thin spaces too.
Thanks.
Tagsdiscussion, layout
Patch

Relationships

has duplicate 0015087 closedcbradney Non-breaking space doesn't do what is expected when it comes to text alignment 

Activities

subik

2009-01-19 12:39

manager   ~0020937

Reminder sent to: avox

Andreas, is it possible in 135svn?

jghali

2009-01-19 13:12

administrator   ~0020938

Last edited: 2009-01-19 13:19

I think we should split the old and new text engine in separate classes before fixing that one. Fixing it now would probably break lots of existing documents. So better wait 1.3.6 probably.

pierremarchand

2009-01-29 13:00

reporter   ~0021041

In my opinion, nbspaces should not prevent stretching mechanism in any case. Thus, I consider that actual behaviour is right. On the other hand, we certainly need to completly redesign the way Scribus handles spaces itself. First of all providing users with a full set of usual spaces even if the current font haven’t them (with the possibility for the user to edit these computed spaces), make the non-breakable attribute a user defined attribute for any space, attach a stretch factor to a class of spaces, etc.

avox

2011-10-24 09:11

updater   ~0027093

I support pierre. NBSPACE should expand (unless it's defined otherwise in the unicode std, but I don't think so).
Additional thin spaces would automatically not expand as they are treated as normal characters (so they would be subject to glyph stretching)

cezaryece

2011-10-24 14:00

updater   ~0027098

I am supporting Pierre here also. Only role of NBSPACE is avoid breaking two words between different line. Mostly used for short words, but also for keeping together initials, numbers and dates. But I dont se any sense in make NBSPACE fixed width as it can provide un-equal width spaces in one line.

Mike

2011-10-28 18:31

reporter   ~0027125

I also agree. Then the text will be nicer.

jghali

2011-10-28 21:45

administrator   ~0027128

According to Unicode standards, NBSPACE is subject to compression and expansion when performing justification. See introduction of "Unicode Line Breaking Algorithm" (http://unicode.org/reports/tr14/#GL) :

"When compression or expansion is allowed, a locally optimal line break seeks to balance the relative merits of the resulting amounts of compression and expansion for different line break candidates. When expanding or compressing interword space according to common typographical practice, only the spaces marked by U+0020 SPACE and U+00A0 NO-BREAK SPACE are subject to compression, and only spaces marked by U+0020 SPACE, U+00A0 NO-BREAK SPACE, and occasionally spaces marked by U+2009 THIN SPACE are subject to expansion. All other space characters normally have fixed width. When expanding or compressing intercharacter space, the presence of U+200B ZERO WIDTH SPACE or U+2060 WORD JOINER is always ignored."

ale

2011-10-29 09:48

manager   ~0027129

personally, i think that we can close this bug report... i understand why somebody may want unbreakable spaces not to expand (most of all the old french habit to add a nb space before colons) but we can't have it as a rule for all nb spaces!

the solution is to have a setting which automatically can add a thin spacing before the punctuation needing it.

TeX does it that way and it's imo the way to go...

Issue History

Date Modified Username Field Change
2008-11-25 10:54 brunod New Issue
2009-01-19 12:39 subik Note Added: 0020937
2009-01-19 13:12 jghali Note Added: 0020938
2009-01-19 13:19 jghali Note Edited: 0020938
2009-01-29 13:00 pierremarchand Note Added: 0021041
2011-10-24 09:11 avox Note Added: 0027093
2011-10-24 14:00 cezaryece Note Added: 0027098
2011-10-28 18:31 Mike Note Added: 0027125
2011-10-28 21:45 jghali Note Added: 0027128
2011-10-29 09:48 ale Note Added: 0027129
2014-04-07 15:46 JLuc Tag Attached: layout
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-05-18 18:50 Kunda Tag Attached: discussion
2017-12-31 10:12 jghali Relationship added has duplicate 0015087