Re: Status of LyX 1.5.0?
On Wed, Jul 11, 2007 at 07:12:42AM +0200, Peter Kümmel wrote: > Enrico Forestieri wrote: > > On Tue, Jul 10, 2007 at 09:40:38PM +0200, Peter Kümmel wrote: > >> Here an updated patch which only calls the Ex functions > >> if they are available. > >> > >> And what was the status? It doesn't work on Vista? > >> And also needs some chmod changes on cygwin? > > > > The patch works on Vista. However, for some inexplicable reason the > > font files must have the executable flag set. I only found > > this explanation: http://cygwin.com/ml/cygwin/2005-11/msg00100.html > > hinting that "the executable flag means more than just execution" > > in Windows. This is not cygwin related, though. I incurred in this > > "bug" only because the cygwin svn did not set the executable flag > > on the files in lib/fonts. When the fonts are installed through the > > NSIS or cygwin installation tools, everything is fine, seemingly. > > > > Isn't this stuff for the installer? But we could also set the flags > in os_win32/os_cgwin, but I can't do it before this evening. The installers get it right, indeed. No need to do anything as I was experiencing the problem only when running LyX in place. > Therefore, if LyX is really released today and we use my patch, > then someone should just commit it. Maybe we should move the common > code into a new file, os_win.cpp, and include this one in the > other two files. I think that the patch by Joost is more compact. I am just complementing it with the changes for cygwin and then will send it to the list. -- Enrico
Re: Status of LyX 1.5.0?
Enrico Forestieri wrote: > On Tue, Jul 10, 2007 at 09:40:38PM +0200, Peter Kümmel wrote: >> Here an updated patch which only calls the Ex functions >> if they are available. >> >> And what was the status? It doesn't work on Vista? >> And also needs some chmod changes on cygwin? > > The patch works on Vista. However, for some inexplicable reason the > font files must have the executable flag set. I only found > this explanation: http://cygwin.com/ml/cygwin/2005-11/msg00100.html > hinting that "the executable flag means more than just execution" > in Windows. This is not cygwin related, though. I incurred in this > "bug" only because the cygwin svn did not set the executable flag > on the files in lib/fonts. When the fonts are installed through the > NSIS or cygwin installation tools, everything is fine, seemingly. > Isn't this stuff for the installer? But we could also set the flags in os_win32/os_cgwin, but I can't do it before this evening. Therefore, if LyX is really released today and we use my patch, then someone should just commit it. Maybe we should move the common code into a new file, os_win.cpp, and include this one in the other two files. -- Peter Kümmel
Re: Status of LyX 1.5.0?
On Tue, Jul 10, 2007 at 09:40:38PM +0200, Peter Kümmel wrote: > Here an updated patch which only calls the Ex functions > if they are available. > > And what was the status? It doesn't work on Vista? > And also needs some chmod changes on cygwin? The patch works on Vista. However, for some inexplicable reason the font files must have the executable flag set. I only found this explanation: http://cygwin.com/ml/cygwin/2005-11/msg00100.html hinting that "the executable flag means more than just execution" in Windows. This is not cygwin related, though. I incurred in this "bug" only because the cygwin svn did not set the executable flag on the files in lib/fonts. When the fonts are installed through the NSIS or cygwin installation tools, everything is fine, seemingly. -- Enrico
Re: Status of LyX 1.5.0?
Here an updated patch which only calls the Ex functions
if they are available.
And what was the status? It doesn't work on Vista?
And also needs some chmod changes on cygwin?
Peter
Index: src/support/os_cygwin.cpp
===
--- src/support/os_cygwin.cpp (revision 19031)
+++ src/support/os_cygwin.cpp (working copy)
@@ -19,7 +19,12 @@
#include "debug.h"
+// compile with Windows > Win98 API, but load those functions dynamically
+// only needed for AddFontResourceEx
+#define _WIN32_WINNT 0x0500
+#define WIN32_LEAN_AND_MEAN
#include
+
#include
#include
#include
@@ -27,6 +32,8 @@
#include
+#include
+
using std::endl;
using std::string;
@@ -324,6 +331,40 @@
}
+// same as in os_win32.cpp
+static
+void fontResources(const std::string& name, LPCTSTR font_file_name)
+{
+ // first try to get the Ex version
+ typedef int (WINAPI* FontFunc)(LPCTSTR);
+ typedef int (WINAPI* FontExFunc)(LPCTSTR, DWORD, PVOID);
+ static FontFunc func = 0;
+ static FontExFunc func_ex = 0;
+ static std::string resolved_name;
+ if (resolved_name != name) {
+ QLibrary win_lib("gdi32");
+ win_lib.load();
+ std::string name_exa = name + "ExA";
+ func_ex = (FontExFunc) win_lib.resolve(name_exa.c_str());
+ if (!func_ex) {
+ std::string name_a = name + "A";
+ func = (FontFunc) win_lib.resolve(name_a.c_str());
+ }
+ resolved_name = name;
+ }
+ if (func_ex) {
+ func_ex(font_file_name, FR_PRIVATE, 0);
+ LYXERR(Debug::FONT) << "fontResources function: " <<
name.c_str() << "Ex" << endl;
+ } else if (func) {
+ func(font_file_name);
+ LYXERR(Debug::FONT) << "fontResources function: " <<
name.c_str() << endl;
+ } else {
+ // could never happen
+ LYXERR(Debug::FONT) << "fontResources - fatal error" << endl;
+ }
+}
+
+
void addFontResources()
{
#ifdef X_DISPLAY_MISSING
@@ -334,7 +375,7 @@
string const font_current = to_local8bit(from_utf8(convert_path(
addName(fonts_dir, win_fonts_truetype[i] + ".ttf"),
PathStyle(windows;
- AddFontResource(font_current.c_str());
+ fontResources("AddFontResource", font_current.c_str());
}
#endif
}
@@ -350,7 +391,7 @@
string const font_current = to_local8bit(from_utf8(convert_path(
addName(fonts_dir, win_fonts_truetype[i] + ".ttf"),
PathStyle(windows;
- RemoveFontResource(font_current.c_str());
+ fontResources("RemoveFontResource", font_current.c_str());
}
#endif
}
Index: src/support/os_win32.h
===
--- src/support/os_win32.h (revision 19031)
+++ src/support/os_win32.h (working copy)
@@ -42,6 +42,10 @@
# define _WIN32_IE 0x0500
#endif
+// compile with Windows > Win98 API, but load those functions dynamically
+// only needed for AddFontResourceEx
+#define _WIN32_WINNT 0x0500
+#define WIN32_LEAN_AND_MEAN
#include
Index: src/support/os_win32.cpp
===
--- src/support/os_win32.cpp(revision 19031)
+++ src/support/os_win32.cpp(working copy)
@@ -30,6 +30,8 @@
#include
#include
+#include
+
/* The GetLongPathName macro may be defined on the compiling machine,
* but we must use a bit of trickery if the resulting executable is
* to run on a Win95 machine.
@@ -403,6 +405,39 @@
}
+static
+void fontResources(const std::string& name, LPCTSTR font_file_name)
+{
+ // first try to get the Ex version
+ typedef int (WINAPI* FontFunc)(LPCTSTR);
+ typedef int (WINAPI* FontExFunc)(LPCTSTR, DWORD, PVOID);
+ static FontFunc func = 0;
+ static FontExFunc func_ex = 0;
+ static std::string resolved_name;
+ if (resolved_name != name) {
+ QLibrary win_lib("gdi32");
+ win_lib.load();
+ std::string name_exa = name + "ExA";
+ func_ex = (FontExFunc) win_lib.resolve(name_exa.c_str());
+ if (!func_ex) {
+ std::string name_a = name + "A";
+ func = (FontFunc) win_lib.resolve(name_a.c_str());
+ }
+ resolved_name = name;
+ }
+ if (func_ex) {
+ func_ex(font_file_name, FR_PRIVATE, 0);
+ LYXERR(Debug::FONT) << "fontResources function: " <<
name.c_str() << "Ex" << endl;
+ } else if (func) {
+ func(font_file_name);
+ LYXERR(Debug::FONT) << "fontResources function: " <<
name.c_str() << endl;
+ } else {
+ // could never happen
+
Re: Status of LyX 1.5.0?
On Thu, Jul 05, 2007 at 05:23:52PM +0200, Enrico Forestieri wrote: > On Thu, Jul 05, 2007 at 03:30:56PM +0200, Jean-Marc Lasgouttes wrote: > > > > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: > > > > Enrico> No, and this is most astonishing, the thing seems to survive a > > Enrico> reboot. I tried to find whether the info is stored in the > > Enrico> registry, but could not find anything. > > > > Enrico> However, I investigated further and it turned out that what I > > Enrico> said occurs on Vista but it does not occur on Win2k. Don't > > Enrico> know about XP. > > > > I read somewhere that vista does not need fonts to be explicitly > > installed. So it is different from xp in this respect. > > No, I don't think so: > http://blogs.msdn.com/michkap/archive/2006/08/27/726378.aspx > > and here: > http://msdn2.microsoft.com/en-us/library/ms534231.aspx > http://msdn2.microsoft.com/en-us/library/ms533937.aspx > > Vista is explicitely mentioned, so this is a bug on Vista. > > I can make AddFontResource(Ex) work only when I put the fonts in > a precise location on disk, and given that this location is > "C:\cygwin\usr\local\share\lyx\fonts", i.e., the path where they > got initially installed with lyx 1.4.4, I presume that once you > used some fonts with those functions, you cannot move them > somewhere else anymore. Even after a reboot. Ouch. Just for the records, I discovered that the font files must have the executable flag set, otherwise they are not found, unless they and all of their path components have proper ACLs. However, I can only guarantee that this happens on thursday with a full moon. Don't know in other conditions... -- Enrico
Re: Status of LyX 1.5.0?
On Fri, Jul 06, 2007 at 12:48:10AM +0200, Enrico Forestieri wrote: > On Wed, Jul 04, 2007 at 04:31:55PM +0200, Jean-Marc Lasgouttes wrote: > > > With Qt4.2, we can also use QFontDatabase::addApplicationFont > > http://doc.trolltech.com/4.2/qfontdatabase.html#addApplicationFont > > I tried this option (see attached patch). It works on Win2k and solves > the problem of having fonts with the same name as the bakoma ones in > the system font directory, but fails on Vista, where addApplicationFont > always returns -1. > > However, pointing addApplicationFont to the the fonts of the installed > LyX 1.4.4, it succeeds. So, this seems to be the same bug afflicting > AddFontResource. Having spent some (too much) time on this problem, > I think I can say there is no way to solve it on Vista, the only > workaround being installing the bakoma fonts in the Windows font > directory. Being Windows ... well ... Windows (no need to say more), I think I should not be surprised. This one I think should be added to the old wives' tales about it. Please, have a look at what I obtain with the above patch applied: $ ./src/lyx-qt4.exe -dbg font Setting debug level to font Debugging `font' (Font handling) Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/cmex10.ttf FAIL Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/cmmi10.ttf FAIL Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/cmr10.ttf FAIL Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/cmsy10.ttf FAIL Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/eufm10.ttf FAIL Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/msam10.ttf FAIL Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/msbm10.ttf FAIL Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/wasy10.ttf FAIL Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/esint10.ttf FAIL $ chmod a+x /usr/local/src/lyx/lyx-devel/lib/fonts/*.ttf $ ./src/lyx-qt4.exe -dbg font Setting debug level to font Debugging `font' (Font handling) Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/cmex10.ttf OK Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/cmmi10.ttf OK Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/cmr10.ttf OK Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/cmsy10.ttf OK Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/eufm10.ttf OK Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/msam10.ttf OK Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/msbm10.ttf OK Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/wasy10.ttf OK Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/esint10.ttf FAIL $ chmod a-x /usr/local/src/lyx/lyx-devel/lib/fonts/*.ttf $ ./src/lyx-qt4.exe -dbg font Setting debug level to font Debugging `font' (Font handling) Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/cmex10.ttf FAIL Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/cmmi10.ttf FAIL Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/cmr10.ttf FAIL Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/cmsy10.ttf FAIL Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/eufm10.ttf FAIL Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/msam10.ttf FAIL Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/msbm10.ttf FAIL Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/wasy10.ttf FAIL Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/esint10.ttf FAIL I can't believe it! The font files must have the executable flag set, otherwise they are not found. But why, my god, why? However, there must be more to it, as when I look at the fonts installed with LyX 1.4.4 I don't see the executable flag set: $ ls -lG /usr/local/share/lyx/fonts/eufm10.ttf -rw-r-+ 1 root 23744 Jul 12 2006 /usr/local/share/lyx/fonts/eufm10.ttf but notice that '+' there, meaning that the file has an ACL attached: $ getfacl /usr/local/share/lyx/fonts/eufm10.ttf # file: /usr/local/share/lyx/fonts/eufm10.ttf # owner: root # group: users user::rw- group::r-- group:SYSTEM:rwx group:administrators:rwx mask:rwx other:--- These ACLs were set up by the cygwin installation tool, which surely knows more than me about Windows, but even when I copy them using $ getfacl source_file | setfacl -f - target_file the files are not found. Most probably, in this case all the path components should have a proper ACL. Windows really drives me mad. However, I will stick with the executable flag set, which seems working. And for the sake of my sanity, I will not try to find a logical explanation. This is Windows, after all... -- Enrico
Re: Status of LyX 1.5.0?
On Wed, Jul 04, 2007 at 04:31:55PM +0200, Jean-Marc Lasgouttes wrote:
> With Qt4.2, we can also use QFontDatabase::addApplicationFont
> http://doc.trolltech.com/4.2/qfontdatabase.html#addApplicationFont
I tried this option (see attached patch). It works on Win2k and solves
the problem of having fonts with the same name as the bakoma ones in
the system font directory, but fails on Vista, where addApplicationFont
always returns -1.
However, pointing addApplicationFont to the the fonts of the installed
LyX 1.4.4, it succeeds. So, this seems to be the same bug afflicting
AddFontResource. Having spent some (too much) time on this problem,
I think I can say there is no way to solve it on Vista, the only
workaround being installing the bakoma fonts in the Windows font
directory.
--
Enrico
Index: src/frontends/qt4/GuiFontLoader.cpp
===
--- src/frontends/qt4/GuiFontLoader.cpp (revision 18990)
+++ src/frontends/qt4/GuiFontLoader.cpp (working copy)
@@ -21,8 +21,11 @@
#include "support/filetools.h"
#include "support/lstrings.h"
#include "support/Systemcall.h"
+#include "support/Package.h"
+#include "support/os.h"
#include
+#include
#include
@@ -33,6 +36,9 @@
#endif
using lyx::support::contains;
+using lyx::support::package;
+using lyx::support::addPath;
+using lyx::support::addName;
using std::endl;
using std::make_pair;
@@ -41,6 +47,12 @@ using std::pair;
using std::vector;
using std::string;
+#if defined(Q_WS_WIN) && QT_VERSION >= 0x040200
+string const win_fonts_truetype[] = {"cmex10", "cmmi10", "cmr10", "cmsy10",
+ "eufm10", "msam10", "msbm10", "wasy10", "esint10"};
+const int num_fonts_truetype = sizeof(win_fonts_truetype) /
sizeof(*win_fonts_truetype);
+#endif
+
namespace lyx {
namespace frontend {
@@ -189,6 +201,19 @@ pair const getSymbolFont(st
GuiFontLoader::GuiFontLoader()
{
+#if defined(Q_WS_WIN) && QT_VERSION >= 0x040200
+ string const fonts_dir =
addPath(package().system_support().absFilename(), "fonts");
+
+ for (int i = 0 ; i < num_fonts_truetype ; ++i) {
+ string const font_file = lyx::support::os::external_path(
+ addName(fonts_dir, win_fonts_truetype[i] + ".ttf"));
+ fontID[i] =
QFontDatabase::addApplicationFont(toqstr(font_file));
+ LYXERR(Debug::FONT) << "Adding font " << font_file
+ << static_cast
+ (fontID[i] < 0 ? " FAIL" : " OK")
+ << endl;
+ }
+#endif
for (int i1 = 0; i1 < Font::NUM_FAMILIES; ++i1)
for (int i2 = 0; i2 < 2; ++i2)
for (int i3 = 0; i3 < 4; ++i3)
@@ -197,6 +222,17 @@ GuiFontLoader::GuiFontLoader()
}
+GuiFontLoader::~GuiFontLoader()
+{
+#if defined(Q_WS_WIN) && QT_VERSION >= 0x040200
+ for (int i = 0 ; i < num_fonts_truetype ; ++i) {
+ if (fontID[i] >= 0)
+ QFontDatabase::removeApplicationFont(fontID[i]);
+ }
+#endif
+}
+
+
void GuiFontLoader::update()
{
for (int i1 = 0; i1 < Font::NUM_FAMILIES; ++i1)
Index: src/frontends/qt4/GuiFontLoader.h
===
--- src/frontends/qt4/GuiFontLoader.h (revision 18990)
+++ src/frontends/qt4/GuiFontLoader.h (working copy)
@@ -47,7 +47,7 @@ public:
GuiFontLoader();
/// Destructor
- virtual ~GuiFontLoader() {}
+ ~GuiFontLoader();
virtual void update();
virtual bool available(Font const & f);
@@ -75,6 +75,8 @@ public:
private:
/// BUTT ugly !
QLFontInfo * fontinfo_[Font::NUM_FAMILIES][2][4][10];
+
+ int fontID[10];
};
Re: Status of LyX 1.5.0?
On Thu, Jul 05, 2007 at 03:30:56PM +0200, Jean-Marc Lasgouttes wrote: > > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: > > Enrico> No, and this is most astonishing, the thing seems to survive a > Enrico> reboot. I tried to find whether the info is stored in the > Enrico> registry, but could not find anything. > > Enrico> However, I investigated further and it turned out that what I > Enrico> said occurs on Vista but it does not occur on Win2k. Don't > Enrico> know about XP. > > I read somewhere that vista does not need fonts to be explicitly > installed. So it is different from xp in this respect. No, I don't think so: http://blogs.msdn.com/michkap/archive/2006/08/27/726378.aspx and here: http://msdn2.microsoft.com/en-us/library/ms534231.aspx http://msdn2.microsoft.com/en-us/library/ms533937.aspx Vista is explicitely mentioned, so this is a bug on Vista. I can make AddFontResource(Ex) work only when I put the fonts in a precise location on disk, and given that this location is "C:\cygwin\usr\local\share\lyx\fonts", i.e., the path where they got initially installed with lyx 1.4.4, I presume that once you used some fonts with those functions, you cannot move them somewhere else anymore. Even after a reboot. Ouch. However, I must say that this is not one of the most strange bugs or behaviors on Windows. For example, I learned that you cannot programmatically install fonts, because even if you copy them to the system font dir, they are not seen until after you open in explorer (the Windows file manager) the aforesaid font directory. Yes, exactly like that: copy the fonts in their place and then open the font directory in explorer (sic!). I think that without Cygwin I had already give up with Windows. -- Enrico
Re: Status of LyX 1.5.0?
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: Enrico> No, and this is most astonishing, the thing seems to survive a Enrico> reboot. I tried to find whether the info is stored in the Enrico> registry, but could not find anything. Enrico> However, I investigated further and it turned out that what I Enrico> said occurs on Vista but it does not occur on Win2k. Don't Enrico> know about XP. I read somewhere that vista does not need fonts to be explicitly installed. So it is different from xp in this respect. JMarc
Re: Status of LyX 1.5.0?
On Wed, Jul 04, 2007 at 04:31:55PM +0200, Jean-Marc Lasgouttes wrote: > > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: > > Enrico> It seems that once you have used AddFontResource to add a font > Enrico> file, you have no choice and cannot move them from the > Enrico> original position, otherwise they will not be found. I am > Enrico> really disgusted. > > Until you reboot, right? No, and this is most astonishing, the thing seems to survive a reboot. I tried to find whether the info is stored in the registry, but could not find anything. However, I investigated further and it turned out that what I said occurs on Vista but it does not occur on Win2k. Don't know about XP. > Might it be that we do not remove the font > where we should? We use RemoveFontResource at exit, but I don't know to what avail. > With Qt4.2, we can also use QFontDatabase::addApplicationFont > http://doc.trolltech.com/4.2/qfontdatabase.html#addApplicationFont Maybe this one would work. Anyway, if anybody can check whether WinXP behaves as Win2k, it seems to be a Vista related problem. -- Enrico
Re: Status of LyX 1.5.0?
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: Enrico> It seems that once you have used AddFontResource to add a font Enrico> file, you have no choice and cannot move them from the Enrico> original position, otherwise they will not be found. I am Enrico> really disgusted. Until you reboot, right? Might it be that we do not remove the font where we should? With Qt4.2, we can also use QFontDatabase::addApplicationFont http://doc.trolltech.com/4.2/qfontdatabase.html#addApplicationFont JMarc
Re: Status of LyX 1.5.0?
On Wed, Jul 04, 2007 at 01:08:18PM +0200, Enrico Forestieri wrote: > On Wed, Jul 04, 2007 at 06:53:10AM +0200, Peter Kümmel wrote: > > As JMarc suggested, does it work when you rename the font file, and > > remove the _LyX from the patch? > > No, as I already tried to say. What is worse is that AddFontResource > and AddFontResourceEx don't seem working with Qt4. Everything is ok > only when the fonts are actually installed, otherwise they are not found. > It puzzles me that in Qt3 it works alright, as demonstrated by LyX 1.4.4. Now let me tell this story about this 32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition, often referred to as Windows. I tried LyX 1.4.5svn and, like 1.5.0svn, it was not able to find both eufm10 and wasy10. The only difference with 1.4.4 was that I was running it in place, but I had created the fonts dir in the source lib directory and populated it with the bakoma fonts, so it should have found them. So, I had a horrible suspect and in 1.5.0svn sources hardcoded the path to the bakoma fonts to the installed LyX 1.4.4 system directory. Well, you guess what, it worked. The fonts are used and the patch by Peter (without _LyX) works, too. I get the correct \kappa even with the other files named as the bakoma ones installed in the system font directory. It seems that once you have used AddFontResource to add a font file, you have no choice and cannot move them from the original position, otherwise they will not be found. I am really disgusted. So, all in all Peter, your patch works (take away _LyX), but the fonts cannot be moved from their original position! I think this is a problem when updating to a newer version on native Windows and the path changes from "C:\Program Files\LyX14" to "C:\Program Files\LyX15". Maybe the fonts should be installed to a fixed location, say "C:\Program Files\Common Files\fonts" or something like that. -- Enrico
Re: Status of LyX 1.5.0?
On Wed, Jul 04, 2007 at 06:53:10AM +0200, Peter Kümmel wrote: > Enrico Forestieri wrote: > > On Tue, Jul 03, 2007 at 09:46:54PM +0200, Peter Kümmel wrote: > > > >> Ok, here with the changes for cygwin, BUT I couldn't test it. > > > > And here is the result of my tests. I uninstalled the bakoma fonts > >>from the Windows fonts dir and reinstalled the same fonts that were > > giving problems with \kappa (with these fonts installed, I get a > > hollow square instead of \kappa). > > > > Without the patch, \kappa was again a hollow square. However, after > > applying the patch, \kappa is still a hollow square. So the patch > > doesn't seem to be working. > > > > Initially, I thought that the problem was the addition of "_LyX" > > to the file names, so I removed it but nothing changed. I also > > ascertained that AddFontResourceEx rather than AddFontResource > > was being called and even tried rebooting. > > > > Just to be 100% sure, I also tried a mingw build and obtained the > > same result. > > > > As JMarc suggested, does it work when you rename the font file, and > remove the _LyX from the patch? No, as I already tried to say. What is worse is that AddFontResource and AddFontResourceEx don't seem working with Qt4. Everything is ok only when the fonts are actually installed, otherwise they are not found. It puzzles me that in Qt3 it works alright, as demonstrated by LyX 1.4.4. This is what I get when using -dbg font in LyX 1.4.4: Looking for font family eufm10 ... raw: eufm10 alleged fi family: eufm10 got it normal! Looking for font family cmsy10 ... raw: cmsy10 alleged fi family: cmsy10 got it normal! Looking for font family cmmi10 ... raw: cmmi10 alleged fi family: cmmi10 got it normal! Looking for font family cmr10 ... raw: cmr10 alleged fi family: cmr10 got it normal! Looking for font family cmex10 ... raw: cmex10 alleged fi family: cmex10 got it normal! Looking for font family msam10 ... raw: msam10 alleged fi family: msam10 got it normal! Looking for font family msbm10 ... raw: msbm10 alleged fi family: msbm10 got it normal! Looking for font family wasy10 ... raw: wasy10 alleged fi family: wasy10 got it normal! and this is the result with 1.5.0svn: Looking for font family eufm10 ... got: MS Shell Dlg 2 Trying Eufm10 ... got: MS Shell Dlg 2 Trying -*-eufm10-medium-*-*-*-*-*-*-*-*-*-*-* ... got: MS Shell Dlg 2 FAILED :-( Looking for font family cmsy10 ... got: cmsy10 got it normal! Looking for font family cmmi10 ... got: cmmi10 got it normal! Looking for font family cmr10 ... got: cmr10 got it normal! Looking for font family cmex10 ... got: cmex10 got it normal! Looking for font family msam10 ... got: msam10 got it normal! Looking for font family msbm10 ... got: msbm10 got it normal! Looking for font family wasy10 ... got: MS Shell Dlg 2 Trying Wasy10 ... got: MS Shell Dlg 2 Trying -*-wasy10-medium-*-*-*-*-*-*-*-*-*-*-* ... got: MS Shell Dlg 2 FAILED :-( Looking for font family esint10 ... got: MS Shell Dlg 2 Trying Esint10 ... got: MS Shell Dlg 2 Trying -*-esint10-medium-*-*-*-*-*-*-*-*-*-*-* ... got: MS Shell Dlg 2 FAILED :-( Note that cmsy10, cmmi10, cmr10, cmex10, msam10, and msbm10 are *not* the bakoma fonts and they are installed in the Windows font directory. The fonts eufm10 and wasy10 are not installed but are added through AddFontResource, while esint10 doesn't exist. Qt3 is able to find and use eufm10 and wasy10, while Qt4 does not, apparently. -- Enrico
Re: Status of LyX 1.5.0?
> "Joost" == Joost Verburg <[EMAIL PROTECTED]> writes: Joost> Peter Kümmel wrote: >>> 3) In any case, I think that the proper windows way is to use >>> AddFontResourceEx and, if it returns an error message (win9x), use >>> AddFontResource instead. There is no need for explicit testing. >> >> I assume LyX will crash, because there is not such function on >> win9x, or couldn't it even start then? Joost> You're right. LyX won't even start because the function does Joost> not exist. The only solution is to load it dynamically using Joost> LoadLibrary. I thought that there was special support for this in windows and that the function would just return 0. But it seems I was wrong... JMarc
Re: Status of LyX 1.5.0?
On Wed, 4 Jul 2007, Abdelrazak Younes wrote: [EMAIL PROTECTED] wrote: On Tue, 3 Jul 2007, Jean-Marc Lasgouttes wrote: > > > > > > "Abdelrazak" == Abdelrazak Younes > > > > > > <[EMAIL PROTECTED]> writes: > > Abdelrazak> Some of those regressions are 'fixedintrunk'. > Abdelrazak> Unfortunately, bugzilla does not allow to filter upon two > Abdelrazak> keyboards. One way to get a correct list would be to set > Abdelrazak> the target milestone to 1.4.x for those bugs. > > What about the advanced boolean cghart at the bottom of the chart? > > http://bugzilla.lyx.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=anywords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&namedcmd=1.4.5+bugs&newqueryname=&order=Reuse+same+sort+as+last+time&field0-0-0=keywords&type0-0-0=substring&value0-0-0=regression&field0-1-0=keywords&type0-1-0=notsubstring&value0-1-0=fixedintrunk > Do we want an 'and' or an 'or' between the keywords? We want an 'and' in this case: (regression) and !(fixedintrunk) Wait, maybe I should just ask: Abdel, does Jean-Marc's search produce the result you want? It seems yes... haven't checked all the entries though. I was going to modify the wiki page, but it seems it already referred to 'notsubstring' 'fixedintrunk'. So I hope the list shown in the wiki page already does what you want... /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Status of LyX 1.5.0?
[EMAIL PROTECTED] wrote: On Tue, 3 Jul 2007, Jean-Marc Lasgouttes wrote: "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> Some of those regressions are 'fixedintrunk'. Abdelrazak> Unfortunately, bugzilla does not allow to filter upon two Abdelrazak> keyboards. One way to get a correct list would be to set Abdelrazak> the target milestone to 1.4.x for those bugs. What about the advanced boolean cghart at the bottom of the chart? http://bugzilla.lyx.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=anywords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&namedcmd=1.4.5+bugs&newqueryname=&order=Reuse+same+sort+as+last+time&field0-0-0=keywords&type0-0-0=substring&value0-0-0=regression&field0-1-0=keywords&type0-1-0=notsubstring&value0-1-0=fixedintrunk Do we want an 'and' or an 'or' between the keywords? We want an 'and' in this case: (regression) and !(fixedintrunk) Wait, maybe I should just ask: Abdel, does Jean-Marc's search produce the result you want? It seems yes... haven't checked all the entries though. Abdel.
Re: Status of LyX 1.5.0?
On Tue, 3 Jul 2007, Jean-Marc Lasgouttes wrote: "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> Some of those regressions are 'fixedintrunk'. Abdelrazak> Unfortunately, bugzilla does not allow to filter upon two Abdelrazak> keyboards. One way to get a correct list would be to set Abdelrazak> the target milestone to 1.4.x for those bugs. What about the advanced boolean cghart at the bottom of the chart? http://bugzilla.lyx.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=anywords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&namedcmd=1.4.5+bugs&newqueryname=&order=Reuse+same+sort+as+last+time&field0-0-0=keywords&type0-0-0=substring&value0-0-0=regression&field0-1-0=keywords&type0-1-0=notsubstring&value0-1-0=fixedintrunk Do we want an 'and' or an 'or' between the keywords? Wait, maybe I should just ask: Abdel, does Jean-Marc's search produce the result you want? /C -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Status of LyX 1.5.0?
Bo Peng wrote: And what is the problem that the middle mouse button doesn't pste on Windows? It is not only windows. Abdel's patch disables persistent selection on all platforms. Jurgen was able to paste because of his desktop manager. Are you really sure of that? As far as I see this is a X11 feature and it is independent of the desktop manager. If X11 doesn't request a "SelectionClear", the selectionBuffer will not be cleared in CutAndPaste.cpp. AFAIU, the only way this could happen is when you left-click in some other application. If you stay within LyX, I think persistent selection should still work after my fix. Please confirm or infirm that as I cannot test myself. Abdel.
Re: Status of LyX 1.5.0?
Peter Kümmel wrote: 3) In any case, I think that the proper windows way is to use AddFontResourceEx and, if it returns an error message (win9x), use AddFontResource instead. There is no need for explicit testing. I assume LyX will crash, because there is not such function on win9x, or couldn't it even start then? You're right. LyX won't even start because the function does not exist. The only solution is to load it dynamically using LoadLibrary. Joost
Re: Status of LyX 1.5.0?
Bo Peng wrote: > or, you are not using the patched lyx. as said, it used to work with all versions of LyX I ever used. THis piece of code is platform independent, Abdel, could you test there? As I said in the comment my commit did disable the middle-mouse pasting under Windows. So there is nothing to test here... Abdel.
Re: Status of LyX 1.5.0?
Enrico Forestieri wrote: On Tue, Jul 03, 2007 at 10:36:22PM +0200, Jean-Marc Lasgouttes wrote: 2) I thought we already had abandonned hope of running under windows 98? That was with Qt3, Qt4 is supposed to work with ME and 98. And I got some report a while ago that it actually works under WinME. Abdel.
Re: Status of LyX 1.5.0?
Bo Peng wrote: I do not see that behaviour. I'll test tomorrow under linux. Here, I select from firefox/gmail a long piece of code, paste to gnome-multi-terminal, and only about 1/3 is pasted. I'd prefer (if possible) 4. Do 1. for now and fix the bug properly as soon as possible. There is actually a proper solution: copy selection to a buffer only when the selection is cleared, and paste from an active selection when a selection is active. In this way, consecutive text selection will be saved only once. If you agree with this solution, I will see if there is an easy implementation. I agree personally that this is the right solution and it should not be very hard actually. The way it was implemented up to my fix (with data copying at each selection change) was not good. Otherwise, I propose that we replace Abdel's fix with this 10 paragraph limit and postpone 3877 to 1.5.1. IMHO, disabling this feature because 3877 does not make sense. I don't have a strong opinion either way. But bug 3877 is important IMO and should be fixed. Abdel.
Re: Status of LyX 1.5.0?
Bo Peng wrote: > and you are disabling a feature that is in Wait, I just disabled the formatting preservation, not the persistent selection as Jurgen has reported. No. You are disabling the whole thing. On Windows and Mac yes. Abdel.
Re: Status of LyX 1.5.0?
> >I do not see that behaviour. I'll test tomorrow under linux. > > Here, I select from firefox/gmail a long piece of code, paste to > gnome-multi-terminal, and only about 1/3 is pasted. i tried it here with ~100 pages-book in firefox + Eterm and nothing is lost. actually - even if the loss is there i would consider it as a bug. 10 paragraph limit would mean strange defects for users using it regularly (i do) - its possible that this loss wouldnt be noticed which is much more worse than have 3877 unfixed. pavel
Re: Status of LyX 1.5.0?
Enrico Forestieri wrote: > On Tue, Jul 03, 2007 at 09:46:54PM +0200, Peter Kümmel wrote: > >> Ok, here with the changes for cygwin, BUT I couldn't test it. > > And here is the result of my tests. I uninstalled the bakoma fonts >>from the Windows fonts dir and reinstalled the same fonts that were > giving problems with \kappa (with these fonts installed, I get a > hollow square instead of \kappa). > > Without the patch, \kappa was again a hollow square. However, after > applying the patch, \kappa is still a hollow square. So the patch > doesn't seem to be working. > > Initially, I thought that the problem was the addition of "_LyX" > to the file names, so I removed it but nothing changed. I also > ascertained that AddFontResourceEx rather than AddFontResource > was being called and even tried rebooting. > > Just to be 100% sure, I also tried a mingw build and obtained the > same result. > As JMarc suggested, does it work when you rename the font file, and remove the _LyX from the patch? -- Peter Kümmel
Re: Status of LyX 1.5.0?
Jean-Marc Lasgouttes wrote: >> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes: > > Peter> Jürgen Spitzmüller wrote: >>> Abdelrazak Younes wrote: 3962 cri (Math) Font problems on Windows This one is a packaging issue right? >>> No, AFAIU you need to replace AddFontRessource and >>> RemoveFontRessourse in support/os_win32.spp with AddFontResourceEx >>> and RemoveFontResourceEx. > > > Peter> Does attached patch solve the problem? > > Peter> Both functions are not supported by older Window versions. > Peter> Therefore we have to decides at runtime which function to call. > > 1) I do not think that you need to rename the fonts and add _LyX when > using AddFontResourceEx with FR_PRIVATE flag. > > 2) I thought we already had abandonned hope of running under windows > 98? > > 3) In any case, I think that the proper windows way is to use > AddFontResourceEx and, if it returns an error message (win9x), use > AddFontResource instead. There is no need for explicit testing. I assume LyX will crash, because there is not such function on win9x, or couldn't it even start then? > > JMarc > -- Peter Kümmel
Re: Status of LyX 1.5.0?
On Tuesday 03 July 2007 11:34:35 [EMAIL PROTECTED] wrote: > I looked at the wiki page > http://wiki.lyx.org/Devel/BuglistsForLyX150 > > and saw the following: > > * 3 critical issues > * 29 regression issues > * 10 major issues > * 25 other issues > > /Christian I am sorry to say that I have been drowned reviewing more than 3000 questions from my students exams. :-) After resurfacing again I will be out for the rest of the week in Lisbon: http://apfa6.dmq.eg.iscte.pt/ So please take your time to consider all the patches that should go before 1.5.0. I am considering a release next week (Monday or Tuesday)... Best regards, -- José Abílio
Re: Status of LyX 1.5.0?
On Tue, Jul 03, 2007 at 10:36:22PM +0200, Jean-Marc Lasgouttes wrote: > > "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes: > > Peter> Jürgen Spitzmüller wrote: > >> Abdelrazak Younes wrote: > >>> 3962 cri (Math) Font problems on Windows > >>> This one is a packaging issue right? > >> > >> No, AFAIU you need to replace AddFontRessource and > >> RemoveFontRessourse in support/os_win32.spp with AddFontResourceEx > >> and RemoveFontResourceEx. > > > Peter> Does attached patch solve the problem? > > Peter> Both functions are not supported by older Window versions. > Peter> Therefore we have to decides at runtime which function to call. > > 1) I do not think that you need to rename the fonts and add _LyX when > using AddFontResourceEx with FR_PRIVATE flag. That flag doesn't seem to do what the documentation says. I don't know whether Qt4 or Windows is to be blamed, but the patch by Peter doesn't work. > 2) I thought we already had abandonned hope of running under windows > 98? That was with Qt3, Qt4 is supposed to work with ME and 98. -- Enrico
Re: Status of LyX 1.5.0?
And what is the problem that the middle mouse button doesn't pste on Windows? It is not only windows. Abdel's patch disables persistent selection on all platforms. Jurgen was able to paste because of his desktop manager. Bo
Re: Status of LyX 1.5.0?
On Tue, Jul 03, 2007 at 09:46:54PM +0200, Peter Kümmel wrote: > Ok, here with the changes for cygwin, BUT I couldn't test it. And here is the result of my tests. I uninstalled the bakoma fonts from the Windows fonts dir and reinstalled the same fonts that were giving problems with \kappa (with these fonts installed, I get a hollow square instead of \kappa). Without the patch, \kappa was again a hollow square. However, after applying the patch, \kappa is still a hollow square. So the patch doesn't seem to be working. Initially, I thought that the problem was the addition of "_LyX" to the file names, so I removed it but nothing changed. I also ascertained that AddFontResourceEx rather than AddFontResource was being called and even tried rebooting. Just to be 100% sure, I also tried a mingw build and obtained the same result. -- Enrico
Re: Status of LyX 1.5.0?
> So you are facing three choices: > > 1. disable this feature like what Abdel does. > 2. with this 10 paragraph limit. This looks like a good compromise to > me. After all, middle button paste is not supposed to paste huge text. > 3. without this limit but with bug 3877 WONTFIX. Please consider those who use often large documents. Personally I often have to copy large text parts to other documents and vice versa (preparing reports from texts your collegues sent you, etc.) Therefore people suffer a lot from bug 3877, so personally I'm happy that this has been fixed ans I strongly oppose to unfix bug 3877 or postpone it. About your 10 paragraph limit: I don't know what this would be the advantage, as JMarc said this seems to be similar to a dataloss when selecting more than 10 paragraphs. (Due to bug 3877 I switched back to LyX 1.4.4 for the copy actions as described above.) regards Uwe
Re: Status of LyX 1.5.0?
> Could you please test the attached patch? It limits the copied > paragraphs to 10 so the cost of copySelection is constant when > selecting large pieces of texts. But Georg opposed to this: http://bugzilla.lyx.org/show_bug.cgi?id=3877#c4 And what is the problem that the middle mouse button doesn't pste on Windows? This is a clear consequence of Abdels patch but it doesn't harm since on Windows no program I know does paste via via the middle mouse button. I also don't think that we need to have "Unix feeling" on Windows. regards Uwe
Re: Status of LyX 1.5.0?
Peter Kümmel wrote: Both functions are not supported by older Window versions. Therefore we have to decides at runtime which function to call. LyX only supports Windows 2000 and later, so there is no need to add these additional hacks. Joost
Re: Status of LyX 1.5.0?
I do not see that behaviour. I'll test tomorrow under linux. Here, I select from firefox/gmail a long piece of code, paste to gnome-multi-terminal, and only about 1/3 is pasted. I'd prefer (if possible) 4. Do 1. for now and fix the bug properly as soon as possible. There is actually a proper solution: copy selection to a buffer only when the selection is cleared, and paste from an active selection when a selection is active. In this way, consecutive text selection will be saved only once. If you agree with this solution, I will see if there is an easy implementation. Otherwise, I propose that we replace Abdel's fix with this 10 paragraph limit and postpone 3877 to 1.5.1. IMHO, disabling this feature because 3877 does not make sense. Bo
Re: Status of LyX 1.5.0?
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes: >> Unfortunately this is not acceptable. We cannot afford to select >> only part of what the user thinks he has selected. This is a recipe >> for data loss. Bo> As I have said in the patch, this is what firefox/linux/xterm Bo> does. I am not sure who is responsible for this behavior though. I do not see that behaviour. I'll test tomorrow under linux. Bo> So you are facing three choices: Bo> 1. disable this feature like what Abdel does. Bo> 2. with this 10 paragraph limit. This looks like a good compromise Bo> to me. After all, middle button paste is not supposed to paste Bo> huge text. Bo> 3. without this limit but with bug 3877 WONTFIX. I'd prefer (if possible) 4. Do 1. for now and fix the bug properly as soon as possible. JMarc
Re: Status of LyX 1.5.0?
Unfortunately this is not acceptable. We cannot afford to select only part of what the user thinks he has selected. This is a recipe for data loss. As I have said in the patch, this is what firefox/linux/xterm does. I am not sure who is responsible for this behavior though. So you are facing three choices: 1. disable this feature like what Abdel does. 2. with this 10 paragraph limit. This looks like a good compromise to me. After all, middle button paste is not supposed to paste huge text. 3. without this limit but with bug 3877 WONTFIX. Maybe you want some lyxrc item select_size_limit=0, that can be changed to something like 10 if someone has a slow computer? Bo
Re: Status of LyX 1.5.0?
> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes: Peter> Jürgen Spitzmüller wrote: >> Abdelrazak Younes wrote: >>> 3962 cri (Math) Font problems on Windows >>> This one is a packaging issue right? >> >> No, AFAIU you need to replace AddFontRessource and >> RemoveFontRessourse in support/os_win32.spp with AddFontResourceEx >> and RemoveFontResourceEx. Peter> Does attached patch solve the problem? Peter> Both functions are not supported by older Window versions. Peter> Therefore we have to decides at runtime which function to call. 1) I do not think that you need to rename the fonts and add _LyX when using AddFontResourceEx with FR_PRIVATE flag. 2) I thought we already had abandonned hope of running under windows 98? 3) In any case, I think that the proper windows way is to use AddFontResourceEx and, if it returns an error message (win9x), use AddFontResource instead. There is no need for explicit testing. JMarc
Re: Status of LyX 1.5.0?
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes: Bo> Could you please test the attached patch? It limits the copied Bo> paragraphs to 10 so the cost of copySelection is constant when Bo> selecting large pieces of texts. Unfortunately this is not acceptable. We cannot afford to select only part of what the user thinks he has selected. This is a recipe for data loss. JMarc
Re: Status of LyX 1.5.0?
Enrico Forestieri wrote:
> On Tue, Jul 03, 2007 at 08:13:42PM +0200, Peter Kümmel wrote:
>
>> Peter Kümmel wrote:
>>> Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
>> 3962 cri (Math) Font problems on Windows
> This one is a packaging issue right?
No, AFAIU you need to replace AddFontRessource and RemoveFontRessourse in
support/os_win32.spp with AddFontResourceEx and RemoveFontResourceEx.
>>>
>>> Does attached patch solve the problem?
>>>
>>> Both functions are not supported by older Window versions.
>>> Therefore we have to decides at runtime which function to call.
>>>
>> Compiles also with Qt 4.1:
>> http://doc.trolltech.com/4.1/qsysinfo.html
>
> Please, could you also take care of that in os_cygwin.cpp, or do
> you prefer that I do it?
>
Ok, here with the changes for cygwin, BUT I couldn't test it.
--
Peter Kümmel
Index: src/support/os_cygwin.cpp
===
--- src/support/os_cygwin.cpp (revision 18974)
+++ src/support/os_cygwin.cpp (working copy)
@@ -19,7 +19,13 @@
#include "debug.h"
+
+// compile with Windows > Win98 API, but guard >Win98 API calls
+// only needed for AddFontResourceEx
+#define _WIN32_WINNT 0x0500
+#define WIN32_LEAN_AND_MEAN
#include
+
#include
#include
#include
@@ -27,6 +33,9 @@
#include
+#include
+
+
using std::endl;
using std::string;
@@ -331,10 +340,17 @@
string const fonts_dir =
addPath(package().system_support().absFilename(), "fonts");
for (int i = 0 ; i < num_fonts_truetype ; ++i) {
- string const font_current = to_local8bit(from_utf8(convert_path(
- addName(fonts_dir, win_fonts_truetype[i] + ".ttf"),
- PathStyle(windows;
- AddFontResource(font_current.c_str());
+ if (QSysInfo::WindowsVersion < QSysInfo::WV_NT ) {
+ string const font_current =
to_local8bit(from_utf8(convert_path(
+ addName(fonts_dir, win_fonts_truetype[i] +
".ttf"),
+ PathStyle(windows;
+ AddFontResource(font_current.c_str());
+ } else {
+ string const font_current =
to_local8bit(from_utf8(convert_path(
+ addName(fonts_dir, win_fonts_truetype[i] +
"_LyX.ttf"),
+ PathStyle(windows;
+ AddFontResourceEx(font_current.c_str(), FR_PRIVATE, 0);
+ }
}
#endif
}
@@ -347,10 +363,17 @@
string const fonts_dir =
addPath(package().system_support().absFilename(), "fonts");
for(int i = 0 ; i < num_fonts_truetype ; ++i) {
- string const font_current = to_local8bit(from_utf8(convert_path(
- addName(fonts_dir, win_fonts_truetype[i] + ".ttf"),
- PathStyle(windows;
- RemoveFontResource(font_current.c_str());
+ if (QSysInfo::WindowsVersion < QSysInfo::WV_NT ) {
+ string const font_current =
to_local8bit(from_utf8(convert_path(
+ addName(fonts_dir, win_fonts_truetype[i] +
".ttf"),
+ PathStyle(windows;
+ RemoveFontResource(font_current.c_str());
+ } else {
+ string const font_current =
to_local8bit(from_utf8(convert_path(
+ addName(fonts_dir, win_fonts_truetype[i] +
"_LyX.ttf"),
+ PathStyle(windows;
+ RemoveFontResourceEx(font_current.c_str(), FR_PRIVATE,
0);
+ }
}
#endif
}
Index: src/support/os_win32.h
===
--- src/support/os_win32.h (revision 18974)
+++ src/support/os_win32.h (working copy)
@@ -42,6 +42,10 @@
# define _WIN32_IE 0x0500
#endif
+// compile with Windows > Win98 API, but guard >Win98 API calls
+// only needed for AddFontResourceEx
+#define _WIN32_WINNT 0x0500
+#define WIN32_LEAN_AND_MEAN
#include
Index: src/support/os_win32.cpp
===
--- src/support/os_win32.cpp(revision 18974)
+++ src/support/os_win32.cpp(working copy)
@@ -30,6 +30,8 @@
#include
#include
+#include
+
/* The GetLongPathName macro may be defined on the compiling machine,
* but we must use a bit of trickery if the resulting executable is
* to run on a Win95 machine.
@@ -409,9 +411,14 @@
string const fonts_dir =
addPath(package().system_support().absFilename(), "fonts");
for (int i = 0 ; i < num_fonts_truetype ; ++i) {
- string const font_current =
- addName(fonts_dir, win_fonts_truetype[i] + ".ttf");
-
AddFontResource(to_local8bit(from_utf8(external_path(font_current))).c_str
Re: Status of LyX 1.5.0?
On Tue, Jul 03, 2007 at 08:13:42PM +0200, Peter Kümmel wrote: > Peter Kümmel wrote: > > Jürgen Spitzmüller wrote: > >> Abdelrazak Younes wrote: > 3962 cri (Math) Font problems on Windows > >>> This one is a packaging issue right? > >> No, AFAIU you need to replace AddFontRessource and RemoveFontRessourse in > >> support/os_win32.spp with AddFontResourceEx and RemoveFontResourceEx. > > > > > > Does attached patch solve the problem? > > > > Both functions are not supported by older Window versions. > > Therefore we have to decides at runtime which function to call. > > > > Compiles also with Qt 4.1: > http://doc.trolltech.com/4.1/qsysinfo.html Please, could you also take care of that in os_cygwin.cpp, or do you prefer that I do it? -- Enrico
Re: Status of LyX 1.5.0?
On 7/3/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Bo Peng wrote:
>> Yes, that's exactly what I proposed in my solution 2. Hopefully for
>> 1.5.1. I mean, 1.5.0 was supposed to be released yesterday...
>
> It should not be that hard,
Be my guest ;-)
Abdel,
Could you please test the attached patch? It limits the copied
paragraphs to 10 so the cost of copySelection is constant when
selecting large pieces of texts.
Cheers,
Bo
Index: src/CutAndPaste.cpp
===
--- src/CutAndPaste.cpp (revision 18975)
+++ src/CutAndPaste.cpp (working copy)
@@ -353,7 +353,7 @@
void copySelectionHelper(Buffer const & buf, ParagraphList & pars,
pit_type startpit, pit_type endpit,
- int start, int end, textclass_type tc, CutStack & cutstack)
+ int start, int end, textclass_type tc, CutStack & cutstack, int sizelimit = 0)
{
BOOST_ASSERT(0 <= start && start <= pars[startpit].size());
BOOST_ASSERT(0 <= end && end <= pars[endpit].size());
@@ -361,7 +361,10 @@
// Clone the paragraphs within the selection.
ParagraphList copy_pars(boost::next(pars.begin(), startpit),
-boost::next(pars.begin(), endpit + 1));
+boost::next(pars.begin(),
+sizelimit > 0 ? std::min(endpit + 1, startpit + sizelimit) : endpit + 1));
+ if (sizelimit > 0 && endpit + 1 > startpit + sizelimit)
+ end = copy_pars.back().size();
// Remove the end of the last paragraph; afterwards, remove the
// beginning of the first paragraph. Keep this order - there may only
@@ -596,7 +599,7 @@
namespace {
-void copySelectionToStack(Cursor & cur, CutStack & cutstack)
+void copySelectionToStack(Cursor & cur, CutStack & cutstack, int sizelimit = 0)
{
// this doesn't make sense, if there is no selection
if (!cur.selection())
@@ -622,7 +625,7 @@
++pos;
copySelectionHelper(cur.buffer(), pars, par, cur.selEnd().pit(),
- pos, cur.selEnd().pos(), cur.buffer().params().textclass, cutstack);
+ pos, cur.selEnd().pos(), cur.buffer().params().textclass, cutstack, sizelimit);
dirtyTabularStack(false);
}
@@ -676,15 +679,14 @@
<< to_utf8(cur.selectionAsString(true)) << "'."
<< endl;
- // FIXME: The two lines below would allow middle-mouse
- // pasting that preserves the LyX formatting when the selection
- // is internal. They would also allow to use the feature on
- // Windows and Mac. In the future, we may want to optionally enable
- // this feature via a rc setting.
- /*
+ // Copy selection to an internal buffer can be a big burden to lyx when
+ // the selection is large (bug 3877). This is why we only save the
+ // first 10 paragraphs of the selected text. This is not a problem when
+ // this feature is used normally (mouse-select small pieces of
+ // text and middle button paste) and is consistent with other applications
+ // (e.g. select a large piece of text from firefox and paste).
if (cur.selection())
- copySelectionToStack(cur, selectionBuffer);
- */
+ copySelectionToStack(cur, selectionBuffer, 10);
// tell X whether we now have a valid selection
theSelection().haveSelection(cur.selection());
Re: Status of LyX 1.5.0?
Peter Kümmel wrote: > Jürgen Spitzmüller wrote: >> Abdelrazak Younes wrote: 3962 cri (Math) Font problems on Windows >>> This one is a packaging issue right? >> No, AFAIU you need to replace AddFontRessource and RemoveFontRessourse in >> support/os_win32.spp with AddFontResourceEx and RemoveFontResourceEx. > > > Does attached patch solve the problem? > > Both functions are not supported by older Window versions. > Therefore we have to decides at runtime which function to call. > Compiles also with Qt 4.1: http://doc.trolltech.com/4.1/qsysinfo.html Peter
Re: Status of LyX 1.5.0?
Yes, this is what I already said Sorry that I did not follow this thread closely. : it does not preserve formatting, it's just good old Unix middle mouse behaviour. Then, in general, Abdel's patch disables this feature. Bo
Re: Status of LyX 1.5.0?
Bo Peng wrote: > There is an easy way to test: can you persistently paste lyx format > (tables etc)? If not, your desktop manager holds a text version of the > selection for you. Yes, this is what I already said: it does not preserve formatting, it's just good old Unix middle mouse behaviour. Jürgen
Re: Status of LyX 1.5.0?
Jürgen Spitzmüller wrote:
> Abdelrazak Younes wrote:
>>> 3962 cri (Math) Font problems on Windows
>> This one is a packaging issue right?
>
> No, AFAIU you need to replace AddFontRessource and RemoveFontRessourse in
> support/os_win32.spp with AddFontResourceEx and RemoveFontResourceEx.
Does attached patch solve the problem?
Both functions are not supported by older Window versions.
Therefore we have to decides at runtime which function to call.
--
Peter Kümmel
Index: src/support/os_win32.h
===
--- src/support/os_win32.h (revision 18974)
+++ src/support/os_win32.h (working copy)
@@ -42,6 +42,9 @@
# define _WIN32_IE 0x0500
#endif
+// compile with Windows > Win98 API, but guard >Win98 API calls
+// only needed for AddFontResourceEx
+#define _WIN32_WINNT 0x0500
#include
Index: src/support/os_win32.cpp
===
--- src/support/os_win32.cpp(revision 18974)
+++ src/support/os_win32.cpp(working copy)
@@ -30,6 +30,8 @@
#include
#include
+#include
+
/* The GetLongPathName macro may be defined on the compiling machine,
* but we must use a bit of trickery if the resulting executable is
* to run on a Win95 machine.
@@ -402,16 +404,20 @@
to_local8bit(from_utf8(filename)).c_str(), NULL, NULL, 1)) > 32;
}
-
void addFontResources()
{
// Windows only: Add BaKoMa TrueType font resources
string const fonts_dir =
addPath(package().system_support().absFilename(), "fonts");
for (int i = 0 ; i < num_fonts_truetype ; ++i) {
- string const font_current =
- addName(fonts_dir, win_fonts_truetype[i] + ".ttf");
-
AddFontResource(to_local8bit(from_utf8(external_path(font_current))).c_str());
+ if (QSysInfo::WindowsVersion < QSysInfo::WV_NT ) {
+ string const font_current = addName(fonts_dir,
win_fonts_truetype[i] + ".ttf");
+
AddFontResource(to_local8bit(from_utf8(external_path(font_current))).c_str());
+ } else {
+ string const font_current = addName(fonts_dir,
win_fonts_truetype[i] + "_LyX.ttf");
+
AddFontResourceEx(to_local8bit(from_utf8(external_path(font_current))).c_str(),
+ FR_PRIVATE, 0);
+ }
}
}
@@ -422,9 +428,14 @@
string const fonts_dir =
addPath(package().system_support().absFilename(), "fonts");
for(int i = 0 ; i < num_fonts_truetype ; ++i) {
- string const font_current =
- addName(fonts_dir, win_fonts_truetype[i] + ".ttf");
-
RemoveFontResource(to_local8bit(from_utf8(external_path(font_current))).c_str());
+ if (QSysInfo::WindowsVersion < QSysInfo::WV_NT ) {
+ string const font_current = addName(fonts_dir,
win_fonts_truetype[i] + ".ttf");
+
RemoveFontResource(to_local8bit(from_utf8(external_path(font_current))).c_str());
+ } else {
+ string const font_current = addName(fonts_dir,
win_fonts_truetype[i] + "_LyX.ttf");
+
RemoveFontResourceEx(to_local8bit(from_utf8(external_path(font_current))).c_str(),
+ FR_PRIVATE, 0);
+ }
}
}
Re: Status of LyX 1.5.0?
as said, it used to work with all versions of LyX I ever used. There is an easy way to test: can you persistently paste lyx format (tables etc)? If not, your desktop manager holds a text version of the selection for you. Bo
Re: Status of LyX 1.5.0?
> or, you are not using the patched lyx. as said, it used to work with all versions of LyX I ever used. THis piece of code is platform independent, Abdel, could you test there? Bo
Re: Status of LyX 1.5.0?
Bo Peng wrote: > It should not. copySelectionToStack(cur, selectionBuffer) is the only > place we put selection to a buffer. If your lyx works, you must be > using some external persistent selection buffer (what desktop manger > are you using?), KDE. > or, you are not using the patched lyx. as said, it used to work with all versions of LyX I ever used. Jürgen
Re: Status of LyX 1.5.0?
On 7/3/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote: Bo Peng wrote: > No. You are disabling the whole thing. I do not know how Jurgen tested > your patch but here, selection, left click, middle button click does > not paste. It surely does on Unix. It should not. copySelectionToStack(cur, selectionBuffer) is the only place we put selection to a buffer. If your lyx works, you must be using some external persistent selection buffer (what desktop manger are you using?), or, you are not using the patched lyx. Bo
Re: Status of LyX 1.5.0?
Bo Peng wrote: > No. You are disabling the whole thing. I do not know how Jurgen tested > your patch but here, selection, left click, middle button click does > not paste. It surely does on Unix. Jürgen
Re: Status of LyX 1.5.0?
> and you are disabling a feature that is in Wait, I just disabled the formatting preservation, not the persistent selection as Jurgen has reported. No. You are disabling the whole thing. I do not know how Jurgen tested your patch but here, selection, left click, middle button click does not paste. Bo
Re: Status of LyX 1.5.0?
Bo Peng wrote: Yes, that's exactly what I proposed in my solution 2. Hopefully for 1.5.1. I mean, 1.5.0 was supposed to be released yesterday... It should not be that hard, Be my guest ;-) and you are disabling a feature that is in Wait, I just disabled the formatting preservation, not the persistent selection as Jurgen has reported. 1.5.0rc1 and rc2 and you have not changed announcement. Did we ever put this feature in the announcement file? Abdel.
Re: Status of LyX 1.5.0?
Yes, that's exactly what I proposed in my solution 2. Hopefully for 1.5.1. I mean, 1.5.0 was supposed to be released yesterday... It should not be that hard, and you are disabling a feature that is in 1.5.0rc1 and rc2 and you have not changed announcement. Bo
Re: Status of LyX 1.5.0?
Bo Peng wrote: Jürgen> to be more precise: if the feature really costs that much, it Jürgen> is obviously not yet ready. Then I vote for commenting it out Jürgen> and explain the situation in the code. I apologize but what 'cost' are you talking about? Is it slow page up/down with selection? Exactly. If so, the easiest method is to, just like the case of xterm, limit the size of internal selection buffer so that excessive selection will not be stored. Yes, that's exactly what I proposed in my solution 2. Hopefully for 1.5.1. I mean, 1.5.0 was supposed to be released yesterday... Abdel.
Re: Status of LyX 1.5.0?
Bo Peng wrote: > I apologize but what 'cost' are you talking about? http://bugzilla.lyx.org/show_bug.cgi?id=3877 Jürgen
Re: Status of LyX 1.5.0?
Jürgen> to be more precise: if the feature really costs that much, it Jürgen> is obviously not yet ready. Then I vote for commenting it out Jürgen> and explain the situation in the code. I apologize but what 'cost' are you talking about? Is it slow page up/down with selection? If so, the easiest method is to, just like the case of xterm, limit the size of internal selection buffer so that excessive selection will not be stored. Bo
Re: Status of LyX 1.5.0?
Jean-Marc Lasgouttes wrote: "Jürgen" == Jürgen Spitzmüller <[EMAIL PROTECTED]> writes: Jürgen> Jürgen Spitzmüller wrote: Obviously, I wouldn't miss the feature. Jürgen> to be more precise: if the feature really costs that much, it Jürgen> is obviously not yet ready. Then I vote for commenting it out Jürgen> and explain the situation in the code. +1 I've done that. Abdel. Author: younes Date: Tue Jul 3 19:11:05 2007 New Revision: 18975 URL: http://www.lyx.org/trac/changeset/18975 Log: Fix bug 3877. Modified: lyx-devel/trunk/src/CutAndPaste.cpp Modified: lyx-devel/trunk/src/CutAndPaste.cpp URL: http://www.lyx.org/trac/file/lyx-devel/trunk/src/CutAndPaste.cpp?rev=18975 == --- lyx-devel/trunk/src/CutAndPaste.cpp (original) +++ lyx-devel/trunk/src/CutAndPaste.cpp Tue Jul 3 19:11:05 2007 @@ -676,8 +676,16 @@ << to_utf8(cur.selectionAsString(true)) << "'." << endl; + // FIXME: The two lines below would allow middle-mouse + // pasting that preserves the LyX formatting when the selection + // is internal. They would also allow to use the feature on + // Windows and Mac. In the future, we may want to optionally enable + // this feature via a rc setting. + /* if (cur.selection()) copySelectionToStack(cur, selectionBuffer); + */ + // tell X whether we now have a valid selection theSelection().haveSelection(cur.selection()); }
Re: Status of LyX 1.5.0?
Bo Peng wrote: I do not know what patch Abdel wants to commit and why it is relevant to r17022. r17022 enables persistent selection, which I am 99.9% sure *not* available in 1.4.x. Also, r17022 is the result of long discussions (Abdel should remember) and is related to some later patches. I mean, it is *not* easy to revert r17022 and even it is, we should not do that at this time. Yes, I remember and I of course didn't revert all of r17022. Abdel.
Re: Status of LyX 1.5.0?
> "Jürgen" == Jürgen Spitzmüller <[EMAIL PROTECTED]> writes: Jürgen> Jürgen Spitzmüller wrote: >> Obviously, I wouldn't miss the feature. Jürgen> to be more precise: if the feature really costs that much, it Jürgen> is obviously not yet ready. Then I vote for commenting it out Jürgen> and explain the situation in the code. +1 JMarc
Re: Status of LyX 1.5.0?
Jürgen Spitzmüller wrote: > Obviously, I wouldn't miss the feature. to be more precise: if the feature really costs that much, it is obviously not yet ready. Then I vote for commenting it out and explain the situation in the code. Jürgen
Re: Status of LyX 1.5.0?
I do not know what patch Abdel wants to commit and why it is relevant to r17022. r17022 enables persistent selection, which I am 99.9% sure *not* available in 1.4.x. Also, r17022 is the result of long discussions (Abdel should remember) and is related to some later patches. I mean, it is *not* easy to revert r17022 and even it is, we should not do that at this time. Bo
Re: Status of LyX 1.5.0?
Jürgen Spitzmüller wrote: Abdelrazak Younes wrote: Are you sure that formatting is preserved? No, it's not (I wasn't aware of that feature). But I suspect that the answer is going to be _no_, in which case we will have to make a decision how what we want. I can see two solution: 1) we remove the code: this means that the normal X-selection buffer is used and not the internal selection stack, this also means that formatting will not be preserved on Unix for LyX internal pasting. 2) we keep the code but we limit the size of the stack: this means that formatting will be preserved for small selection but not for big ones. This also means that the pasting will work on windows only if it is small selection. I personally think that 1) is the right choice for now... Opinions? Obviously, I wouldn't miss the feature. Maybe others will but I think we have no choice right now. In the future, we may allow this with a user rc settings for example. So I am going to comment out this code with appropriate comments. Abdel.
Re: Status of LyX 1.5.0?
Abdelrazak Younes wrote: > Are you sure that formatting is preserved? No, it's not (I wasn't aware of that feature). > But I suspect that the answer is going to be _no_, in which case we will > have to make a decision how what we want. I can see two solution: > > 1) we remove the code: this means that the normal X-selection buffer is > used and not the internal selection stack, this also means that > formatting will not be preserved on Unix for LyX internal pasting. > > 2) we keep the code but we limit the size of the stack: this means that > formatting will be preserved for small selection but not for big ones. > This also means that the pasting will work on windows only if it is > small selection. > > I personally think that 1) is the right choice for now... > > Opinions? Obviously, I wouldn't miss the feature. Jürgen
Re: Status of LyX 1.5.0?
Abdelrazak Younes wrote: Jürgen Spitzmüller wrote: Abdelrazak Younes wrote: I think there's a misunderstanding here. Persistent selection is when you: 1) select something (mouse or keyboard) 2) left-click somewhere: selection is gone) 3) middle-click somewhere: the selected text in 1) is pasted 4) left-click somewhere else. 5) middle-click somewhere else: the selected text in 1) is pasted Does that work with or without my patch? with and without and in 1.4. Are you sure that formatting is preserved? So that means that the removed code is not needed at all! 'svn blame' tells me that Bo has introduced it at revision 17022: http://www.lyx.org/trac/changeset/17022 Bo, do you remember why you added this code and do you understand why it is not needed now? And the answer is Windows: This code let users use the middle-mouse pasting mechanism on Windows. Jurgen, if you answer yes to my question above, I will commit because I don't all users should pay for Windows middle-mouse pasting. But I suspect that the answer is going to be _no_, in which case we will have to make a decision how what we want. I can see two solution: 1) we remove the code: this means that the normal X-selection buffer is used and not the internal selection stack, this also means that formatting will not be preserved on Unix for LyX internal pasting. 2) we keep the code but we limit the size of the stack: this means that formatting will be preserved for small selection but not for big ones. This also means that the pasting will work on windows only if it is small selection. I personally think that 1) is the right choice for now... Opinions? Abdel.
Re: Status of LyX 1.5.0?
Jürgen Spitzmüller wrote: Abdelrazak Younes wrote: I think there's a misunderstanding here. Persistent selection is when you: 1) select something (mouse or keyboard) 2) left-click somewhere: selection is gone) 3) middle-click somewhere: the selected text in 1) is pasted 4) left-click somewhere else. 5) middle-click somewhere else: the selected text in 1) is pasted Does that work with or without my patch? with and without and in 1.4. So that means that the removed code is not needed at all! 'svn blame' tells me that Bo has introduced it at revision 17022: http://www.lyx.org/trac/changeset/17022 Bo, do you remember why you added this code and do you understand why it is not needed now? Abdel.
Re: Status of LyX 1.5.0?
Abdelrazak Younes wrote: > I think there's a misunderstanding here. Persistent selection is when you: > > 1) select something (mouse or keyboard) > 2) left-click somewhere: selection is gone) > 3) middle-click somewhere: the selected text in 1) is pasted > 4) left-click somewhere else. > 5) middle-click somewhere else: the selected text in 1) is pasted > > Does that work with or without my patch? with and without and in 1.4. Jürgen
Re: Status of LyX 1.5.0?
Jean-Marc Lasgouttes wrote: "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> Some of those regressions are 'fixedintrunk'. Abdelrazak> Unfortunately, bugzilla does not allow to filter upon two Abdelrazak> keyboards. One way to get a correct list would be to set Abdelrazak> the target milestone to 1.4.x for those bugs. What about the advanced boolean cghart at the bottom of the chart? I had never notice them :-0 Weird, I thought I have seen some 'fixedintrunk' items in this list... Anyway, forget about it. Abdel.
Re: Status of LyX 1.5.0?
Jürgen Spitzmüller wrote: Bo Peng wrote: Persistent selection also means that you can paste even if the selection is cleared. For example, select, left button click (selection cleared), middle button paste. I can't remember that this ever _didn't_ work here, actually. I think there's a misunderstanding here. Persistent selection is when you: 1) select something (mouse or keyboard) 2) left-click somewhere: selection is gone) 3) middle-click somewhere: the selected text in 1) is pasted 4) left-click somewhere else. 5) middle-click somewhere else: the selected text in 1) is pasted Does that work with or without my patch? Abdel.
Re: Status of LyX 1.5.0?
Bo Peng wrote: > Persistent selection > also means that you can paste even if the selection is cleared. For > example, select, left button click (selection cleared), middle button > paste. I can't remember that this ever _didn't_ work here, actually. Jürgen
Re: Status of LyX 1.5.0?
Hm, what you describe seems to work here (linux) with and without Abdel's patch (however, it also works with 1.4, so I probably still miss the point). Strange, I do not think it is backported to 1.4. Persistent selection also means that you can paste even if the selection is cleared. For example, select, left button click (selection cleared), middle button paste. Bo
Re: Status of LyX 1.5.0?
Bo Peng wrote: > When you select, you can paste with middle button many times, across > multiple windows and multiple buffers. Previously, middle button paste > only pastes a current selection. Hm, what you describe seems to work here (linux) with and without Abdel's patch (however, it also works with 1.4, so I probably still miss the point). I didn't find any drawback with Abdel's patch, but I guess things are differently on Windows. Jürgen
Re: Status of LyX 1.5.0?
Yes. Could you tell me once more what "persistent selection" is supposed to be? When you select, you can paste with middle button many times, across multiple windows and multiple buffers. Previously, middle button paste only pastes a current selection. This also works under windows. Cheers, Bo
Re: Status of LyX 1.5.0?
Abdelrazak Younes wrote: > > 3962 cri (Math) Font problems on Windows > > This one is a packaging issue right? No, AFAIU you need to replace AddFontRessource and RemoveFontRessourse in support/os_win32.spp with AddFontResourceEx and RemoveFontResourceEx. > > 3404 maj lyx2lyx adds too many \end_layout tokens > > 3764 maj Implicit \author field in .lyx files > > 3877 maj Highlighting text slows down LyX extremely > > Could you test the patch that I posted there and report if it doesn't > remove any functionality under X11 (except persistent selection of course)? Yes. Could you tell me once more what "persistent selection" is supposed to be? Jürgen
Re: Status of LyX 1.5.0?
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> Some of those regressions are 'fixedintrunk'. Abdelrazak> Unfortunately, bugzilla does not allow to filter upon two Abdelrazak> keyboards. One way to get a correct list would be to set Abdelrazak> the target milestone to 1.4.x for those bugs. What about the advanced boolean cghart at the bottom of the chart? http://bugzilla.lyx.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=anywords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&namedcmd=1.4.5+bugs&newqueryname=&order=Reuse+same+sort+as+last+time&field0-0-0=keywords&type0-0-0=substring&value0-0-0=regression&field0-1-0=keywords&type0-1-0=notsubstring&value0-1-0=fixedintrunk JMarc
Re: Status of LyX 1.5.0?
Jürgen Spitzmüller wrote: Abdelrazak Younes wrote: Why don't we release now 1.5.0? IMO at least those bugs should be fixed (for some, there are patches available). 3313 cri unicode error when invoking lyx2lyx 3962 cri (Math) Font problems on Windows This one is a packaging issue right? 3404 maj lyx2lyx adds too many \end_layout tokens 3764 maj Implicit \author field in .lyx files 3877 maj Highlighting text slows down LyX extremely Could you test the patch that I posted there and report if it doesn't remove any functionality under X11 (except persistent selection of course)? Abdel. Index: CutAndPaste.cpp === --- CutAndPaste.cpp (revision 18939) +++ CutAndPaste.cpp (working copy) @@ -676,8 +676,6 @@ << to_utf8(cur.selectionAsString(true)) << "'." << endl; - if (cur.selection()) - copySelectionToStack(cur, selectionBuffer); // tell X whether we now have a valid selection theSelection().haveSelection(cur.selection()); }
Re: Status of LyX 1.5.0?
> "Jürgen" == Jürgen Spitzmüller <[EMAIL PROTECTED]> writes: Jürgen> 3764 maj Implicit \author field in .lyx files I am working on this one. JMarc
Re: Status of LyX 1.5.0?
Abdelrazak Younes wrote: > Why don't we release now 1.5.0? IMO at least those bugs should be fixed (for some, there are patches available). 3313 cri unicode error when invoking lyx2lyx 3962 cri (Math) Font problems on Windows 3404 maj lyx2lyx adds too many \end_layout tokens 3764 maj Implicit \author field in .lyx files 3877 maj Highlighting text slows down LyX extremely 3958 maj lyx2lyx reversion to 1.4 fails for UserGuide and, if possible 3561 cri crash when changing document encoding Jürgen
Re: Status of LyX 1.5.0?
[EMAIL PROTECTED] wrote: I looked at the wiki page http://wiki.lyx.org/Devel/BuglistsForLyX150 and saw the following: * 3 critical issues * 29 regression issues Some of those regressions are 'fixedintrunk'. Unfortunately, bugzilla does not allow to filter upon two keyboards. One way to get a correct list would be to set the target milestone to 1.4.x for those bugs. Why don't we release now 1.5.0? Abdel.
