Am 05.11.2016 um 21:25 schrieb Stephan Witt <st.w...@gmx.net>:
> 
> Am 05.11.2016 um 16:31 schrieb Jean-Marc Lasgouttes <lasgout...@lyx.org>:
>> 
>> Le 05/11/2016 à 13:30, Jean-Marc Lasgouttes a écrit :
>>> OK, I can reproduce it now. The problem is with characters
>>> LINE SEPARATOR (U+2028)
>>> PARAGRAPH SEPARATOR (U+2029)
>>> 
>>> Since they break line/character in string display, we get "interesting"
>>> consequences when trying to move cursor. It should not be difficult to
>>> avoid the crash, but the result will not be satisfactory. I see two
>>> possibilities:
>>> 
>>> 1/ replace them with proper line-break or paragraph-break on import
>>> from Unicode text. This is not 100% fail-safe, but it be easy and
>>> help in many cases.
>>> 
>>> 2/ keep them but interpret them as space everywhere for display. This
>>> will not give the same as PDF output, I guess
>>> 
>>> 3/ find a way to replace them with proper line/paragraph breaks in our
>>> document seamlessly. This seems a bit difficult to achieve, actually.
>> 
>> Or;
>> 
>> 4/ catch the characters at the level of the row breaking algorithm 
>> (TextMetrics::breakRow). This should be pretty straightforward to do.
>> 
>> JMarc
>> 
> 
> Yes, this would be the best solution. It seems so easy that I tried to
> come up with a patch myself. See attached. It works for this problem -
> I don’t know if its covers all possible code paths, though.

After doing some code analysis and thinking again I came to the conclusion
that my patch is not the best one. One shouldn’t handle U+2028 and U+2029
the same way. To treat LINE SEPARATOR as a new line is ok, IMO.
The PARAGRAPH SEPARATOR needs a different handling and makes more work.
First it shouldn’t go in as is when pasting text. Probably the LyX file
parser can handle the case when the LX file somehow contains a U+2029 already.

What do you think? Is it possible to test for U+2029 this way? 

I attach the updated patch without the file parser change. I didn’t do this yet.

Stephan

Attachment: lineForTextPosition-4-crash.patch
Description: Binary data

Reply via email to