ctests for input encoding

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

Re: [patch] remove unsupported encoding l7xenc

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

Re: Apparmor profile for LyX on Linux ?

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

Re: #10481: Hardening LyX against potential misuse

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

Re: #10481: Hardening LyX against potential misuse

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 > ---

caption text for image not justify

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 ?

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

Re: #10481: Hardening LyX against potential misuse

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

Re: [patch] remove unsupported encoding l7xenc

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

Re: pasted non-acceptable symbol

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

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

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

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

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

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

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

Re: Shutdown bug?

> 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

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

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

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

Re: pasted non-acceptable symbol

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

Re: Shutdown bug?

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:

Re: pasted non-acceptable symbol

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) >>>

Re: loset my cocnut in lyx

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

Re: Inverted colors for cursor

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