Am 07.11.2016 um 10:59 schrieb Jean-Marc Lasgouttes <lasgout...@lyx.org>:
> 
> Le 06/11/2016 à 14:30, Jean-Marc Lasgouttes a écrit :
>> This is a more radical approach that what I have in mind, and I do not
>> know whether it is safe. My idea was to modify the Row building code and
>> replace the character with some visual cue (in addition with the row
>> breaking), because I am not confident in sending this character to Qt
>> string rendering functions.
>> 
>> I'll propose something shortly.
> 
> Finally, I convinced myself that your approach is correct if we want to keep 
> the breaks. In the following patch I add some one screen hints of what is 
> going on. I could use a color of the characters, but I am not sure what to 
> do, these are actual characters, not insets. A solution could be to add a 
> frame around the characters.
> 
> The next problem is running LaTeX. By default, these characters are not 
> accepted. Could our local latex+unicode experts tell us whether it makes any 
> sense to handle these characters in LaTeX of whether nobody cares and they 
> should be ignored on output?
> 
> I suspect that adding them to lib/unicodesymbols would do more harm than good.
> 
> I am not sure that the approach of removing them when converting from plain 
> text (paste or insert) is worth it, since we have to handle the characters 
> anyway. But again, at some moments it seems right to me to handle them there.
> 
> For example, this hints that we should handle them like (CR)LF:
> http://stackoverflow.com/questions/3072152/what-is-unicode-character-2028-ls-line-separator-used-for
> 
> JMarc
> 
> <0001-Handle-properly-unicode-paragraph-line-break.patch>

I tested your patch and it works for me. The change of "lib/unicodesymbols“
leads to proper output. I cannot tell how the impact of the latter change is.

Stephan

Reply via email to