[scribus] EOL interpreted as end of paragraph.

[Jean Ghali]

Le 31/03/2012 18:47, john Culleton a écrit :
> I note that when importing text prepared in an external editor
> like Gvim every end of line is interpreted by Scribus text
> importer as an end of paragraph marker. I have set up Gvim to
> automatically generate an EOL after I type 72 characters. For a
> paragraph end I insert a blank line, following the TeX
> convention. But when I import the text file into Scribus every
> line becomes a paragraph. 

This is most likely caused by gvim using line-feed (0x0A) or carriage return (0x0D) as
line separator :
- this way of doing is ancient and non portable as the interpretation of those characters
is totally platform dependent
- this method is not unicode compliant : for unicode those characters are both paragraph
separators, with the exception that 0x0D0A sequence must be interpreted as only one
paragraph separator instead of two

Unicode has defined non ambiguous and portable characters to use as line and paragraph
separator :
- line separator : 0x2028 (http://www.fileformat.info/info/unicode/char/2028/index.htm)
- paragraph separator : 0x2029 (http://www.fileformat.info/info/unicode/char/2029/index.htm)

In gvim case it should be using 0x2028 character and not the carriage return.

> if I delete all EOL markers in Gvim then Gvim
> will still wrap the lines visually but may divide lines in the middle
> of a word to accomplish the visual wrap. That's a bit clumsy.

This only underlines gvim uses a basic and non unicode compliant line breaking algorithm.

> 
> HTML does not so interpret an EOL for example. And the blank line
> convention is followed when typing emails.

For HTML line feed and carriage-return are equivalent to a space. But this is specific to
HTML. As most mail programs implement unicode line breaking algorithm, text wraps without
problems.

> 
> Is there a setting somewhere that prevents Scribus from
> interpreting an EOL as an end of paragraph marker when importing text? 

No, because we follow here the unicode guide line about interpretation of characters in a
word processing context. See following link section 4.2 point 2 :

http://unicode.org/standard/reports/tr13/tr13-5.html#Interpreting%20characters%20in%20text

"In word processing, interpret any NLF the same as PS."

That mean 0x0D0A, 0x0A, 0xOD sequences are to be interpreted as paragraph separators.

However as far as i remember we currently do not interpret the new unicode line and
paragraph separators. This is something we'll have to fix at a point. But gvim should be
using the proper line separator too.

Jean