On Sat, May 16, 2015 at 7:49 AM, Juergen Spitzmueller wrote:
> commit 673217593e102586c5638ce3855178783e14c047
> Author: Juergen Spitzmueller
> Date: Sat May 16 13:48:17 2015 +0200
>
> Update comment.
>
> diff --git a/lib/languages b/lib/languages
> index 1661699..06d3c0f 100644
> --- a/lib
On Tue, Jun 16, 2015 at 08:33:41AM +0200, Jürgen Spitzmüller wrote:
> 2015-06-16 1:23 GMT+02:00 Scott Kostyshak :
>
> > On Sun, May 17, 2015 at 04:23:14PM +0200, Jürgen Spitzmüller wrote:
> > > 2015-05-17 15:48 GMT+02:00 Kornel Benko :
> > >
> > > >
> > > Conclusio: LuaTeX + polyglossia introduces
On Tue, Jun 16, 2015 at 08:49:17AM +0200, Jürgen Spitzmüller wrote:
> 2015-06-16 8:33 GMT+02:00 Jürgen Spitzmüller :
>
> > Alas, I do not have time to check the other ones.
> >
>
> However, it would help a lot if you could check whether any of these
> documents fail for you with LuaTeX, but _not_
Am Dienstag, 16. Juni 2015 schrieb Uwe Stöhr :
>>>iconv -t utf-8 input.txt | pandoc | iconv -f utf-8
>>
>> What do you propose?
I have no idea. I just can point you to the problem, which must be solved
in order to support pandoc.
>> (On my PC the encoding for output TeX files is already UTF8.)
>
On Tue, Jun 16, 2015 at 7:10 PM, Enrico Forestieri wrote:
> On Tue, Jun 16, 2015 at 06:51:29PM +0200, Jean-Marc Lasgouttes wrote:
>
>> Le 13/06/2015 21:04, Enrico Forestieri a écrit :
>> >On Sat, Jun 13, 2015 at 11:46:57AM +0200, Jean-Marc Lasgouttes wrote:
>> >
>> >>While answering to ticket #960
Pandoc uses the UTF-8 character encoding for both input and
output. If your
local character encoding is not UTF-8, you should pipe input
and output
through iconv:
iconv -t utf-8 input.txt | pandoc | iconv -f utf-8
What do you propose?
You
On 06/16/2015 11:45 AM, Enrico Forestieri wrote:
On Tue, Jun 16, 2015 at 11:11:28AM -0400, Richard Heck wrote:
On 06/16/2015 11:10 AM, Enrico Forestieri wrote:
commit cd1467383450613b0d63d5679afdd95c85a600d8
Author: Enrico Forestieri
Date: Tue Jun 16 17:03:32 2015 +0200
Avoid unnecess
From:
On Tue, Jun 16, 2015 at 06:51:29PM +0200, Jean-Marc Lasgouttes wrote:
> Le 13/06/2015 21:04, Enrico Forestieri a écrit :
> >On Sat, Jun 13, 2015 at 11:46:57AM +0200, Jean-Marc Lasgouttes wrote:
> >
> >>While answering to ticket #9609, I noticed that single instance mode
> >>requires that a pipe ha
Le 13/06/2015 21:04, Enrico Forestieri a écrit :
On Sat, Jun 13, 2015 at 11:46:57AM +0200, Jean-Marc Lasgouttes wrote:
While answering to ticket #9609, I noticed that single instance mode
requires that a pipe has been set up. Why do we need something so
inconvenient? Don't we have a socket mode
On Tue, Jun 16, 2015 at 11:11:28AM -0400, Richard Heck wrote:
> On 06/16/2015 11:10 AM, Enrico Forestieri wrote:
> >commit cd1467383450613b0d63d5679afdd95c85a600d8
> >Author: Enrico Forestieri
> >Date: Tue Jun 16 17:03:32 2015 +0200
> >
> > Avoid unnecessary growth of python lists
> > T
On 06/16/2015 11:10 AM, Enrico Forestieri wrote:
commit cd1467383450613b0d63d5679afdd95c85a600d8
Author: Enrico Forestieri
Date: Tue Jun 16 17:03:32 2015 +0200
Avoid unnecessary growth of python lists
The path argument of checkProg* was added to the PATH list in a nested
2015-06-16 15:45 GMT+02:00 Guenter Milde:
> Dear LyX developers,
>
> some LICR (LaTeX internal character representation) macros require
> termination by a {}, so that the macro name can be separated from the
> following text.
>
> Example: "\\OE", e.g. used in \OE{}vre
>
Note that we terminate b
Dear LyX developers,
some LICR (LaTeX internal character representation) macros require
termination by a {}, so that the macro name can be separated from the
following text.
Example: "\\OE", e.g. used in \OE{}vre
However, "lib/unicodesymbols" has also replacement code that must not be
terminat
On 2015-06-15, Georg Baum wrote:
> Uwe Stöhr wrote:
>> Am 09.06.2015 um 20:38 schrieb Georg Baum:
...
>>> At least the function names (e.g. quotedWinPath) suggest that the quoting
>>> is still windows specific.
>> Yes, because this function is only called if the OS is Windows, for all
>> other O
15 matches
Mail list logo
