[scribus] Fwd: Improve typographic rule support

[Andreas Vox]

Czarek <czarek at ...> writes:

> 
> Discuse from other place:
> >> Personally I would like to change way how Scribus justify lines of text
> >> when text don`t feet line width and large spaces are inserted in line.
> >> In other layouting apps I saw option for set maximum space width and
> > maximum glyphs kerning loose if calculated space width is above maximum 
> value.
> > It works similar to current glyph extension feature, but for me it
> > creates better formatted lines as glyphs are not extended but kerning is
> > looser.
> > I think combining the two methods (loosing kerning and glyph extension)
> > should give users best possible method to avoid appearing of large wide
> > spaces.
> >
> >cezaryece
> 
> >I hate automatic character spacing. If you limit it to 5% it will not help
> > more than glyph stretching and if you allow more, it's most ugly.

...
 
> For me extending glyphs is just ugly option at all, for you increasing char 
> spacing is ugly - maybe there should be both methods used at once.
> Effect will be stronger with smaller visual impact.

Ok, some facts to defend my point:

*  the ratio of black pixels vs. white pixels stays the same with glyph
   extension but decreases with character spacing.
*  with glyph extension, the intra-char rythm of vertical stems and the 
   inter-char rythm stays in proportion; with character spacing the in-char 
   rythm is constant but the inter-char rythm changes.
*  OTOH width of vertical lines increases with glyph extesnion but stays the
   same with character spacing; also circles stay circles with character 
   spacing
*  looking at text from an angle has the same effect as glyph shrinking: 
   looking on a line at 10° from the right (or left) does the same as glyph
   shrinking to cos(10°) = 98,48%.


So since we look at text from an angle all the time, why shouldn't we accept 
the same effect for justifictaion?

> >IMO the correct behaviour for formatting lines when a maximum space
> > limit is exceeded would be to break inside a word
> > even if there is no recommended break position.
> >
> >/Andreas
> 
> And for me that behaviour is not acceptable - automation wouldn’t create 
> formatting errors like wrong hyphenation point!!!
> But maybe remove hyphenation from last word of previous line would be correct 
> and helpful.

A paragraph layouter would find such a possibility. When a paragraph layouter
finds itself in a situation where the best layout excceds the maxing word
spacing at some line, it has only three choices:
- accept it
- accept it and set the line flush left
- use a "wrong" hyphenation point

/Andreas