ctests for input encoding

[Guenter Milde]

Dear Kornel,

the recent discussion about http://www.lyx.org/trac/ticket/10474
showed, that input encoding support was never fully tested.

I suggest to extend the tests in autotests/export/latex/Unicode-characters
to all encodings defined in lib/encodings.

Could you write a rule testing 
"autotests/export/latex/Unicode-characters/*.lyx" with all encodings 
(this would also allow to remove the ascii vs. utf8 doubling) or
should I place individual files into
autotests/export/latex/Unicode-characters/ ?

Günter

Re: [patch] remove unsupported encoding l7xenc

[Guenter Milde]

On 2016-11-06, Uwe Stöhr wrote:
> Am 05.11.2016 um 23:54 schrieb Guenter Milde:

>> Inputenc never supported an l7x or l7xenc option. LyX got this wrong
>> from the beginning
...

> So the fix is simply the attached one. No fileformat change is necessary.

Yes, that should do it.

> I tested the patch with some Lithuanian texts from the Lithuanian 
> Wikipedia and it works.

Great. IMO, this is should also go to stable.


Do you also update the wiki?

Then it would make sense to add a remark that not only Unicode fonts, but
also the font-encoding L7X solves the problem with drag-and-drop of accented
characters from the PDF.

In LyX, you can set the font encoding under
 Document>Settings>Fonts>LaTeX font encoding
L7X is supported by LatinModern and the standard Postscript fonts as well as
TeXGyre.

thanks a lot

Günter

Re: Apparmor profile for LyX on Linux ?

[Tommaso Cucinotta]

Just something concrete to play with, attached.

If I run:

  lyxwrap rm /tmp/whatever

it is executed, but if I run:

  lyxwrap rm /home/tommaso/whatever

it says "Permission denied" :-)!
So, the idea is to wrap execution of any external converter/plotter/etc., so 
that they can only write into the /tmp/ folder, except for the case of 
exporting to .pdf, .tex, etc.

Any distro packager on the list with comments?

Thanks,

T.

On 06/11/2016 21:11, Tommaso Cucinotta wrote:

Hi all,

#10481 is dealing with the problem of making LyX robust to any
possible threat arising from maliciously crafted .lyx files that
launch unwanted code when viewed on screen and/or converted to
PDF/others. The currently provided patch warns the user before
launching any converter marked as "needauth".

In addition to that, a very good way to deal with the issue seems to
give external scripts/converters permissions to write exclusively
within /tmp/lyx_tmpdir* temporary folders, this being possible on
Linux shipping LyX along with an Apparmor profile (Apparmor is a kind
of chroot() on steroids)

http://wiki.apparmor.net/index.php/QuickProfileLanguage

as nowadays this is widely used by many other programs (just type
"find /etc/apparmor.d/"). This would imply to add a usr.bin.lyx file
to be installed in /etc/apparmor.d/ on Linux only.

Before working out a first try, I'd like to hear comments from
others, especially on the side of portability (Mac/Win users). From a
quick search, it seems the Mac OS-X way for the same thing would be
using TrustedBSD:

http://sysdev.me/trusted-bsd-in-osx/

Any comment welcome, thanks!

T.


commit 0eb1417d
Author: Tommaso Cucinotta 
Date:   Mon Nov 7 00:39:33 2016 +0100

Added lyxwrap wrapper along with apparmor.d script for safe execution of external converters.

diff --git a/configure.ac b/configure.ac
index 05e73285..773fe002 100644
--- a/configure.ac
+++ b/configure.ac
@@ -387,6 +387,7 @@ AC_CONFIG_FILES([Makefile \
   development/lyx.spec \
   lib/lyx.desktop-temp:lib/lyx.desktop.in
   lib/Makefile \
+  lib/usr.bin.lyxwrap \
   lib/doc/Makefile \
   lib/lyx2lyx/lyx2lyx_version.py \
   lib/lyx2lyx/Makefile \
diff --git a/lib/Makefile.am b/lib/Makefile.am
index a19d4f2c..4b2fedf6 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -2485,6 +2485,9 @@ install-data-hook:
 			chmod 644 "$(DESTDIR)$(pkgdatadir)/$$i"; \
 		fi; \
 	done
+if INSTALL_POSIX
+	cp usr.bin.lyxwrap /etc/apparmor.d/
+endif
 
 alltests: check alltests-recursive
 
diff --git a/lib/usr.bin.lyxwrap.in b/lib/usr.bin.lyxwrap.in
new file mode 100644
index ..dd990d25
--- /dev/null
+++ b/lib/usr.bin.lyxwrap.in
@@ -0,0 +1,15 @@
+# vim:syntax=apparmor
+# Author: Tommaso Cucinotta 
+
+#include 
+
+@prefix@/bin/lyxwrap {
+  /tmp/** ixrw,
+  @{HOME}/** ixr,
+  / ixr,
+  /** ixr,
+  deny /etc/security/ xrw,
+  deny /etc/security/** xrw,
+  deny /etc/passwd* xrw,
+  deny /etc/shadow* xrw,
+}
diff --git a/src/Makefile.am b/src/Makefile.am
index 8ac13067..4e51ba5b 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -25,7 +25,7 @@ OTHERLIBS = $(BOOST_LIBS) $(MYTHES_LIBS) $(ENCHANT_LIBS) $(HUNSPELL_LIBS) \
 	$(LIBSHLWAPI) $(LIBPSAPI)
 
 noinst_LIBRARIES = liblyxcore.a
-bin_PROGRAMS = lyx
+bin_PROGRAMS = lyx lyxwrap
 
 lyx_LDADD = \
 	liblyxcore.a \
@@ -100,6 +100,9 @@ if LYX_WIN_RESOURCE
 lyx_SOURCES += lyxwinres.rc
 endif
 
+lyxwrap_SOURCES = \
+	lyxwrap.cpp
+
 SOURCEFILESCORE = \
 	Author.cpp \
 	boost.cpp \

Re: #10481: Hardening LyX against potential misuse

[Tommaso Cucinotta]

On 07/11/2016 00:19, Richard Heck wrote:

Questions:

We're not supposed just to use "Yes" and "No", right?


still missing the global option to suppress any questions (assume always yes or always 
no), and, I think also the persisting the chosen yes/no to disk (where? any hint? what 
about $HOME/.lyx/auth-files.txt containing a simple list of abs filenames where the user 
said "yes, and don't ask for this doc" ?)


This changes the format of some file or other. Which one? Is this a
format change in the relevant sense of "master only"?


there's a new option among the flags/options of converters, without file format change; 
new shipped format would have those additional "needauth" flags set on known 
potentially harmful converters.


+   static const char securityWarning[] =


This can just be a string yes? I don't think we usually use char[].


I'm ok with anything, is there a usual place where to place a shared string 
across 2 modules, like this? (noticed it got twice into the final lyx 
executable, perhaps as I'm compiling debug-mode)

Thanks,

T.

Re: #10481: Hardening LyX against potential misuse

[Richard Heck]

Questions:

We're not supposed just to use "Yes" and "No", right?

This changes the format of some file or other. Which one? Is this a
format change in the relevant sense of "master only"?

> diff --git a/src/Converter.cpp b/src/Converter.cpp
> index 58e486e6..02631ca4 100644
> --- a/src/Converter.cpp
> +++ b/src/Converter.cpp
>
> + if (conv.need_auth()) {
> + static const char securityWarning[] = 

This can just be a string yes? I don't think we usually use char[].

> diff --git a/src/graphics/GraphicsConverter.cpp
> b/src/graphics/GraphicsConverter.cpp 
> index 67b1580f..6017073f 100644
> --- a/src/graphics/GraphicsConverter.cpp
> +++ b/src/graphics/GraphicsConverter.cpp
> @@ -15,6 +15,7 @@
>  #include "Converter.h"
>  #include "Format.h"
>  
> +#include "frontends/alert.h"
>  #include "support/lassert.h"
>  #include "support/convert.h"
>  #include "support/debug.h"
> @@ -372,6 +373,15 @@ static void build_script(string const & from_file,
>   outfile = tempfile.name().toFilesystemEncoding();
>   }
>  
> + if (conv.need_auth()) {
> + static const char securityWarning[] = 

Same here?

Richard

caption text for image not justify

[edu Gpl]

Dear lyx team
thank you for your job, support, creativity.
I got samll problem in the caption text of image, it's not justify.
please see the image in attachment files.

​

best regards


caption.lyx
Description: application/lyx


caption.pdf
Description: Adobe PDF document

Apparmor profile for LyX on Linux ?

[Tommaso Cucinotta]

Hi all,

#10481 is dealing with the problem of making LyX robust to any possible threat arising 
from maliciously crafted .lyx files that launch unwanted code when viewed on screen 
and/or converted to PDF/others. The currently provided patch warns the user before 
launching any converter marked as "needauth".

In addition to that, a very good way to deal with the issue seems to give 
external scripts/converters permissions to write exclusively within 
/tmp/lyx_tmpdir* temporary folders, this being possible on Linux shipping LyX 
along with an Apparmor profile (Apparmor is a kind of chroot() on steroids)

  http://wiki.apparmor.net/index.php/QuickProfileLanguage

as nowadays this is widely used by many other programs (just type "find 
/etc/apparmor.d/"). This would imply to add a usr.bin.lyx file to be installed in 
/etc/apparmor.d/ on Linux only.

Before working out a first try, I'd like to hear comments from others, 
especially on the side of portability (Mac/Win users). From a quick search, it 
seems the Mac OS-X way for the same thing would be using TrustedBSD:

  http://sysdev.me/trusted-bsd-in-osx/

Any comment welcome, thanks!

T.

Re: #10481: Hardening LyX against potential misuse

[Tommaso Cucinotta]

last patch attached.

T.

On 06/11/2016 20:56, LyX Ticket Tracker wrote:

#10481: Hardening LyX against potential misuse
-+--
  Reporter:  t.cucinotta  |   Owner:  lasgouttes
  Type:  enhancement  |  Status:  new
  Priority:  highest  |   Milestone:
Component:  general  | Version:  unspecified
  Severity:  major|  Resolution:
  Keywords:   |
-+--

Comment (by t.cucinotta):

  Just fixed minor things and the wording in the attached .2.patch file,
  however there's the major issue that in GraphicsConverter there's no info
  whatsoever about buffer name, so it won't be possible to have the "yes,
  don't ask for the doc" option in that case, that case being display
  on-screen, which is probably the most common/needed (the one that works ok
  is when you export to PDF or other formats).
  Tried to add the missing context in a separate patch, but got to nothing
  but ... segfaults!



commit c5c02d37
Author: Tommaso Cucinotta 
Date:   Sat Nov 5 01:00:44 2016 +0100

Add needauth option to converters that need explicit user authorization before being run.

Addressing #10481.

Converters marked with the new "needauth" option won't be run unless
the user gives explicit authorization, which is asked on-demand when
the converter is about to be run (question is not asked if the file is
cached and the converter is not needed).

The user prompt has a 3rd button (yes to all for document) so that
he/she's not prompted again for the same converter over the same document
(identified through buffer->filePath()).

diff --git a/lib/configure.py b/lib/configure.py
index 09d053e9..705aed6c 100644
--- a/lib/configure.py
+++ b/lib/configure.py
@@ -749,8 +749,8 @@ def checkConverterEntries():
 rc_entry = [r'''\converter latex  lyx"%% -f $$i $$o"	""
 \converter latexclipboard lyx"%% -fixedenc utf8 -f $$i $$o"	""
 \converter literate   lyx"%% -n -m noweb -f $$i $$o"	""
-\converter sweave   lyx"%% -n -m sweave -f $$i $$o"	""
-\converter knitr   lyx"%% -n -m knitr -f $$i $$o"	""'''], not_found = 'tex2lyx')
+\converter sweave   lyx"%% -n -m sweave -f $$i $$o"	"needauth"
+\converter knitr   lyx"%% -n -m knitr -f $$i $$o"	"needauth"'''], not_found = 'tex2lyx')
 if path == '':
 logger.warning("Failed to find tex2lyx on your system.")
 
@@ -763,24 +763,24 @@ def checkConverterEntries():
 \converter literate   dviluatex "%%"	""'''])
 #
 checkProg('a Sweave -> LaTeX converter', ['Rscript --verbose --no-save --no-restore $$s/scripts/lyxsweave.R $$p$$i $$p$$o $$e $$r'],
-rc_entry = [r'''\converter sweave   latex  "%%"	""
-\converter sweave   pdflatex   "%%"	""
-\converter sweave   xetex  "%%"	""
-\converter sweave   luatex "%%"	""
-\converter sweave   dviluatex  "%%"	""'''])
+rc_entry = [r'''\converter sweave   latex  "%%"	"needauth"
+\converter sweave   pdflatex   "%%"	"needauth"
+\converter sweave   xetex  "%%"	"needauth"
+\converter sweave   luatex "%%"	"needauth"
+\converter sweave   dviluatex  "%%"	"needauth"'''])
 #
 checkProg('a knitr -> LaTeX converter', ['Rscript --verbose --no-save --no-restore $$s/scripts/lyxknitr.R $$p$$i $$p$$o $$e $$r'],
-rc_entry = [r'''\converter knitr   latex  "%%"	""
-\converter knitr   pdflatex   "%%"	""
-\converter knitr   xetex  "%%"	""
-\converter knitr   luatex "%%"	""
-\converter knitr   dviluatex  "%%"	""'''])
+rc_entry = [r'''\converter knitr   latex  "%%"	"needauth"
+\converter knitr   pdflatex   "%%"	"needauth"
+\converter knitr   xetex  "%%"	"needauth"
+\converter knitr   luatex "%%"	"needauth"
+\converter knitr   dviluatex  "%%"	"needauth"'''])
 #
 checkProg('a Sweave -> R/S code converter', ['Rscript --verbose --no-save --no-restore $$s/scripts/lyxstangle.R $$i $$e $$r'], 
-rc_entry = [ r'\converter sweave  r  "%%"""' ])
+rc_entry = [ r'\converter sweave  r  "%%""needauth"' ])
 #
 checkProg('a knitr -> R/S code converter', ['Rscript --verbose --no-save --no-restore $$s/scripts/lyxknitr.R $$p$$i $$p$$o $$e $$r tangle'],
-rc_entry = [ r'\converter knitr  r  "%%"""' ])
+rc_entry = [ r'\converter knitr  r  "%%""needauth"' ])
 #
 checkProg('an HTML -> LaTeX converter', ['html2latex $$i', 'gnuhtml2latex',
 'htmltolatex -input $$i -output $$o', 'htmltolatex.jar -input $$i -output $$o'],
diff --git a/src/Converter.cpp b/src/Converter.cpp
index 58e486e6..02631ca4 100644
--- a/src/Converter.cpp
+++ b/src/Converter.cpp
@@ -100,7 +100,7 @@ Converter::Converter(string const & f, string const & t,
 		 string const & c, string const & l)
 	: from_(f), to_(t), command_(c), flags_(l),
 	  From_(0), To_(0), 

Re: [patch] remove unsupported encoding l7xenc

[Uwe Stöhr]

Am 05.11.2016 um 23:54 schrieb Guenter Milde:


Inputenc never supported an l7x or l7xenc option. LyX got this wrong from the 
beginning


Tanks, now I got it.

So the fix is simply the attached one. No fileformat change is necessary.

I tested the patch with some Lithuanian texts from the Lithuanian 
Wikipedia and it works.


thanks and regards
Uwe
 lib/encodings | 3 +--
 lib/languages | 2 +-
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/lib/encodings b/lib/encodings
index 75ae8f3..47c23cf 100644
--- a/lib/encodings
+++ b/lib/encodings
@@ -69,8 +69,7 @@ End
 Encoding iso8859-9 latin5 "Turkish (ISO 8859-9)" ISO-8859-9 fixed inputenc
 End
 
-# Not standard, see http://www.vtex.lt/tex/littex/index.html
-Encoding iso8859-13 l7xenc "Baltic (ISO 8859-13)" ISO-8859-13 fixed inputenc
+Encoding iso8859-13 latin7 "Baltic (ISO 8859-13)" ISO-8859-13 fixed inputenc
 End
 
 Encoding iso8859-15 latin9 "Western European (ISO 8859-15)" ISO-8859-15 fixed 
inputenc
diff --git a/lib/languages b/lib/languages
index 53d5feb..4433738 100644
--- a/lib/languages
+++ b/lib/languages
@@ -800,7 +800,7 @@ Language lithuanian
BabelNamelithuanian
PolyglossiaName  lithuanian
QuoteStyle   german
-   Encoding iso8859-4
+   Encoding iso8859-13
FontEncoding L7x
LangCode lt_LT
AsBabelOptions   true

Re: pasted non-acceptable symbol

[Stephan Witt]

Am 06.11.2016 um 14:30 schrieb Jean-Marc Lasgouttes :
> 
> Le 05/11/2016 à 21:25, Stephan Witt a écrit :
>>> 4/ catch the characters at the level of the row breaking algorithm 
>>> (TextMetrics::breakRow). This should be pretty straightforward to do.
>> 
>> 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.
> 
> 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.

Ok, Stephan

Re: [patch] On-screen justification: stretch in proportion with the em, up to a limit

[Jean-Marc Lasgouttes]

OK.

JMarc

Le 6 novembre 2016 16:33:09 GMT+01:00, Guillaume Munch  a écrit :
>
>Most of the times it is already clear from the other lines that the
>text 
>is justified. In addition, on-screen justification cannot be much more 
>than cosmetic anyway, since there is an option to disable it. The goal 
>is to increase readability, and additional clues would only clutter, in
>
>my opinion.

Re: [patch] On-screen justification: stretch in proportion with the em, up to a limit

[Guillaume Munch]

Le 06/11/2016 à 16:11, Jean-Marc Lasgouttes a écrit :

Something I meant to mention: shall we add some on screen cue that the
row has not been completely stretched ?

JMarc


Most of the times it is already clear from the other lines that the text 
is justified. In addition, on-screen justification cannot be much more 
than cosmetic anyway, since there is an option to disable it. The goal 
is to increase readability, and additional clues would only clutter, in 
my opinion.

Re: [patch] On-screen justification: stretch in proportion with the em, up to a limit

[Jean-Marc Lasgouttes]

Something I meant to mention: shall we add some on screen cue that the row has 
not been completely stretched ?

JMarc

Le 6 novembre 2016 14:57:30 GMT+01:00, Guillaume Munch  a écrit :
>Le 29/08/2016 à 14:16, Jean-Marc Lasgouttes a écrit :
>>
>> The patch looks good.
>
>It's in at b30f8d3c4b

Re: Shutdown bug?

[Paola Manzini]

> On 6 Nov 2016, at 12:32, Stephan Witt  wrote:
> 
>> Am 06.11.2016 um 13:21 schrieb Paola Manzini :
>> 
>> Hi All,
>> 
>> I am running LyX on mac OS Sierra on a macbook pro, and El Capitan on an 
>> iMAc, and I’ve noticed the following bug, both with 2.2.0 and 2.2.2 on the 
>> Sierra machine, and 2.2.2 on the El Capitan machine: whenever I try to 
>> either open a file from any directory on my hard disk, or save a new file 
>> (or save as, requiring a change in filename), the command succeeds, but at 
>> the same time I get a pop up “bug” message, and lyx shuts down, see 
>> screenshot.
> 
> Hi Paola,
> 
> I’m sorry for that - but I cannot reproduce this problem on my system (El 
> Capitan and LyX 2.2.2 or LyX 2.3.x development).
> Unfortunately the crash report you’ve posted is not helpful.
> 
> Do have the problem with all LyX documents or not?
> 
> Regards,
> Stephan
> 
Dear Stephan,
yes I do have the same issue with all files, and on both machines.
It is an inconvenience, but it does not prevent me from working, though. I did 
wonder whether this was my problem only.
Many thanks,
Paola

Re: [patch] On-screen justification: stretch in proportion with the em, up to a limit

[Guillaume Munch]

Le 29/08/2016 à 14:16, Jean-Marc Lasgouttes a écrit :


The patch looks good.


It's in at b30f8d3c4b

Re: pasted non-acceptable symbol

[Jean-Marc Lasgouttes]

Le 05/11/2016 à 21:25, Stephan Witt a écrit :

4/ catch the characters at the level of the row breaking algorithm 
(TextMetrics::breakRow). This should be pretty straightforward to do.


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.


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.

JMarc

Re: pasted non-acceptable symbol

[Jean-Marc Lasgouttes]

Le 06/11/2016 à 13:25, Stephan Witt a écrit :

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.


This patch is orthogonal to the other one. I am not sure that you want 
to do it in real paste (i.e. when pasting LyX text to LyX text), but 
rather in the insertStringAs(Lines/Paragraphs) methods, when the two 
unicode characters should be interpreted as needed.


Moreover I do not think it is interesting to add a new method in 
textutils.h for testing a single character. The convention we use now is 
like:

 static char_type const thin = 0x2009; // U+2009 THIN SPACE
directly at the place of the source where you use it.

JMarc

Re: Shutdown bug?

[Stephan Witt]

Am 06.11.2016 um 13:21 schrieb Paola Manzini :
> 
> Hi All,
> 
> I am running LyX on mac OS Sierra on a macbook pro, and El Capitan on an 
> iMAc, and I’ve noticed the following bug, both with 2.2.0 and 2.2.2 on the 
> Sierra machine, and 2.2.2 on the El Capitan machine: whenever I try to either 
> open a file from any directory on my hard disk, or save a new file (or save 
> as, requiring a change in filename), the command succeeds, but at the same 
> time I get a pop up “bug” message, and lyx shuts down, see screenshot.

Hi Paola,

I’m sorry for that - but I cannot reproduce this problem on my system (El 
Capitan and LyX 2.2.2 or LyX 2.3.x development).
Unfortunately the crash report you’ve posted is not helpful.

Do have the problem with all LyX documents or not?

Regards,
Stephan

Re: pasted non-acceptable symbol

[Stephan Witt]

Am 05.11.2016 um 21:25 schrieb Stephan Witt :
> 
> Am 05.11.2016 um 16:31 schrieb Jean-Marc Lasgouttes :
>> 
>> 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


lineForTextPosition-4-crash.patch
Description: Binary data

Re: loset my cocnut in lyx

[edu Gpl]

Dear Richard, Joel
Thank you for your supported.
Best regards

بتاريخ ٠٤‏/١١‏/٢٠١٦ ٧:٣٥ م، كتب "Joel Kulesza" :

> On Fri, Nov 4, 2016 at 9:41 AM, Richard Heck  wrote:
>
>> Practically speaking, you're probably best off exporting the svg to png
>> and using that in the LyX file.
>
>
> I tested exporting the SVG to PDF with Inkscape, and all coconuts are
> present, accounted for, and in vector form.  This might be another option.
> That said, I was able to render SVG using pdflatex.
>
>

Re: Inverted colors for cursor

[racoon]

On 22.10.2016 14:38, Joel Kulesza wrote:

Interesting, yes, the options are different when that checkbox is
selected (I would have expected them to remain the same but be
overridden by the system colors).  Furthermore, unchecking that box
(which is checked, by default, I believe), permits me to change colors
for items like the shaded box (that I reported on in Ticket 10420).

I will update the ticket with a suggestion to "grey out" the color box
when System Colors is checked.  This should direct users to the right
place and/or right option to enable/disable.


I think your ticket was "removed" without the greyed out suggestion 
being appreciated. I have added a new ticket and a patch for it.


http://www.lyx.org/trac/ticket/10483

Let's see whether it finds supporters apart from you and me. :)

Daniel