On Mon, Jan 28, 2013 at 10:42 PM, Scott Kostyshak wrote:
> On Mon, Jan 28, 2013 at 10:09 PM, wrote:
>> From: Scott Kostyshak
>>
>> This test should fail because #7673 is not yet fixed in trunk.
>> Note that it is fixed in branch.
>
> Can someone confirm that this test runs correctly (and fails)
On Mon, Jan 28, 2013 at 10:09 PM, wrote:
> From: Scott Kostyshak
>
> This test should fail because #7673 is not yet fixed in trunk.
> Note that it is fixed in branch.
Can someone confirm that this test runs correctly (and fails) on CMake
and/or autotools?
The previous patch in this series shoul
From: Scott Kostyshak
This test should fail because #7673 is not yet fixed in trunk.
Note that it is fixed in branch.
This is the first autotest that uses an existing .lyx file,
bug-7673.lyx.
---
development/autotests/bug-7673-in.txt |9 ++
development/autotests/bug-7673.lyx| 157 +
From: Scott Kostyshak
If the test opens an existing .lyx file and crashes, it will leave
around a .emergency file. If a test with that same name is run again,
LyX will try to recover the .emergency file, which could throw
off the test.
This is implemented for both CMake and autotools.
---
devel
Hello Jürgen,
you recently added support for a lot of fonts. Today I stumbled over the kurier
fonts
http://www.ctan.org/tex-archive/fonts/kurier/
ftp://ftp.rrzn.uni-hannover.de/pub/mirror/tex-archive/fonts/kurier/doc/fonts/kurier/kurier-info.pdf
because they are used by modernCV by a theme. In
Am 28.01.2013 07:54, schrieb Jürgen Spitzmüller:
The linebreak is necessary to get the city in its own line.
This is a requirement for some job applications. At least that was once
reported to me.
Look, the problem is that some modernCV themes (casual, which has the address
information in the
Am 28.01.2013 07:47, schrieb Jürgen Spitzmüller:
Hm. But you know there is no class called "koma-script".
Sorry. When will I even learn that MiKTeX works different? (I can test for a package named
"koma-script" and also for scrbook.cls).
Yesterday I fiddled a lot with the miktex package inst
Am 21.01.2013 21:16, schrieb Georg Baum:
This was a problem in configure.py that was kindly fixed by Enrico some
weeks ago. The fix is included for both installer of LyX 2.0.5.1.
Does this mean that the version installed by the windows installer is not
built from the 2.5.0.1 source tarball?
On Mon, Jan 28, 2013 at 07:47:22AM +0100, Jürgen Spitzmüller wrote:
> Uwe Stöhr wrote:
> > +\TestPackage{koma-script}
>
> Hm. But you know there is no class called "koma-script".
Really? But MikTeX installs that package when adding this line.
--
Enrico
Jean-Marc Lasgouttes wrote:
> You mean that when rtl support is disabled, we would just let qt do its
> thing and see what happens?
Exactly. Probably it won't be perfect, but I suppose we can start from there.
> What I can try to do also is to reduce the differences between hebrew
> and arabic
Le 28/01/2013 13:00, Jürgen Spitzmüller a écrit :
Jean-Marc Lasgouttes wrote:
One of the things I would like to do in Milano (if it proves possible)
is to implement word-level metrics computation, at least for LtR text.
This would be great!
Don't hold your breath yet :)
but I will not try
Jean-Marc Lasgouttes wrote:
> One of the things I would like to do in Milano (if it proves possible)
> is to implement word-level metrics computation, at least for LtR text.
This would be great!
> It would be great to get rid of our Bidi stuff too,
Even better.
> but I will not try
> anythin
Le 28/01/2013 12:19, John Tapsell a écrit :
Hi,
Qt uses harfbuzz to get the information. You can do the same.
It seems that QChar gives the relevant information, if only I could
understand it :)
JMarc
Hi,
Qt uses harfbuzz to get the information. You can do the same.
John
On 28 January 2013 10:45, Jürgen Spitzmüller wrote:
> Jean-Marc Lasgouttes wrote:
>> What I had in mind is the helper functions isHebrewComposeChar or
>> isArabicComposeChar in Encoding.cpp. Actually, I am not sure why the
Le 28/01/2013 11:45, Jürgen Spitzmüller a écrit :
I understand that a compose char is a compose char. But how many compose chars
are there over the whole unicode range? My point is: If Qt already knows this,
and if we can catch this information, why should we hardcode a list of code
points oursel
Jean-Marc Lasgouttes wrote:
> What I had in mind is the helper functions isHebrewComposeChar or
> isArabicComposeChar in Encoding.cpp. Actually, I am not sure why these
> could not just be 'isComposeChar'. What does the language has to do
> with it? Is there a reason for testing the language as
Le 28/01/2013 09:00, Jürgen Spitzmüller a écrit :
Jean-Marc Lasgouttes wrote:
I guess we need some
special support like we have for arabic. Are there some special
character composition rules we should know about?
Do we really have to reinvent the wheel given that Qt has all this
information? I
Jean-Marc Lasgouttes wrote:
> I guess we need some
> special support like we have for arabic. Are there some special
> character composition rules we should know about?
Do we really have to reinvent the wheel given that Qt has all this
information? I understand it would be significant work to b
18 matches
Mail list logo
