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
"autotes
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 pa
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 t
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/
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
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
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 a
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
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 Lithuan
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
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 goa
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 justificatio
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
> 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
Le 29/08/2016 à 14:16, Jean-Marc Lasgouttes a écrit :
The patch looks good.
It's in at b30f8d3c4b
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 attache
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 differ
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
>
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)
>>>
>>>
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 expo
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 ch
21 matches
Mail list logo
