[patch] tiny cosmetics
this is really just to make the paragraph dialog look a little bit more compact, i.e. I reduced the ugly whitespace on the bottom, no other change. OK to commit? Jürgen Index: src/frontends/qt4/ui/ParagraphUi.ui === --- src/frontends/qt4/ui/ParagraphUi.ui (Revision 19033) +++ src/frontends/qt4/ui/ParagraphUi.ui (Arbeitskopie) @@ -9,7 +9,7 @@ x0/x y0/y width488/width -height334/height +height286/height /rect /property property name=sizePolicy @@ -36,52 +36,6 @@ property name=spacing number6/number /property - item row=4 column=0 -spacer - property name=orientation - enumQt::Vertical/enum - /property - property name=sizeHint - size - width20/width - height31/height - /size - /property -/spacer - /item - item row=2 column=0 -layout class=QHBoxLayout - property name=margin - number0/number - /property - property name=spacing - number6/number - /property - item - widget class=QCheckBox name=indentCB - property name=text -stringIndent amp;Paragraph/string - /property - /widget - /item - item - spacer - property name=orientation -enumQt::Horizontal/enum - /property - property name=sizeType -enumQSizePolicy::Expanding/enum - /property - property name=sizeHint -size - width20/width - height20/height -/size - /property - /spacer - /item -/layout - /item item row=5 column=0 layout class=QHBoxLayout property name=margin @@ -151,61 +105,64 @@ /item /layout /item - item row=0 column=0 -layout class=QHBoxLayout - property name=margin - number0/number + item row=4 column=0 +spacer + property name=orientation + enumQt::Vertical/enum /property - property name=spacing - number6/number + property name=sizeHint + size + width20/width + height16/height + /size /property - item - widget class=QLabel name=linespacingL - property name=text -stringLamp;ine spacing:/string - /property - property name=buddy -cstringlinespacing/cstring - /property - /widget - /item - item - widget class=QComboBox name=linespacing - item -property name=text - stringDefault/string +/spacer + /item + item row=3 column=0 +widget class=QGroupBox name=labelwidthGB + property name=enabled + boolfalse/bool + /property + property name=sizePolicy + sizepolicy + hsizetype5/hsizetype + vsizetype1/vsizetype + horstretch0/horstretch + verstretch0/verstretch + /sizepolicy + /property + property name=title + stringLabel Width/string + /property + layout class=QGridLayout + property name=margin + number9/number + /property + property name=spacing + number6/number + /property + item row=0 column=1 + widget class=QLineEdit name=labelWidth +property name=toolTip + stringThis text defines the width of the paragraph label/string /property - /item - item -property name=text - stringSingle/string + /widget + /item + item row=0 column=0 + widget class=QLabel name=TextLabel2 +property name=toolTip + stringThis text defines the width of the paragraph label/string /property - /item - item property name=text - string1.5/string + stringamp;Longest label/string /property - /item - item -property name=text - stringDouble/string +property name=buddy + cstringlabelWidth/cstring /property - /item - item -property name=text - stringCustom/string -/property - /item - /widget - /item - item - widget class=QLineEdit name=linespacingValue - property name=enabled -boolfalse/bool - /property - /widget - /item -/layout + /widget + /item + /layout +/widget /item item row=1 column=0 widget class=QGroupBox name=aligmentGB @@ -273,52 +230,95 @@ /layout /widget /item - item row=3 column=0 -widget class=QGroupBox name=labelwidthGB - property name=enabled - boolfalse/bool + item row=0 column=0 +layout class=QHBoxLayout + property name=margin + number0/number /property - property name=sizePolicy - sizepolicy - hsizetype5/hsizetype - vsizetype1/vsizetype - horstretch0/horstretch - verstretch0/verstretch - /sizepolicy + property name=spacing + number6/number /property
Re: Arrival/departure dates for Bromarv?
On Tue, Jul 10, 2007 at 11:25:14PM +0200, [EMAIL PROTECTED] wrote: On Tue, 10 Jul 2007, Andre Poenitz wrote: ... I've now booked my flight, I arrive in Helsinki 14:00, you at 14:45 and Jean-Marc at 14:50. So I'll just have a late lunch while waiting. All on thursday 9th? Then perhaps we should just pick you up by car. I'll talk to the CEO about it ;-) Both should be enough to reach the regular bus to/from Bromarv. Ok. Is there anybody else coming btw? I don't think so... Martin? Lars was planning to come by bike. And then Jose and Susana... Jose? Anything special to bring? We have bedlinen and towels and all... but do bring as many laptops as you can, with ethernet cables / wireless cards, and a spare hub or ADSL modem if you have one. Last Saturday we had the thunderstorm of the century - phone dead, internet dead. Two working days, said Sonera. We'll see. I have some contingency plans for that... A yes, bring swimming clothes. Nice sand beach close by. Should I bring a laptop? I can take my old Dell (300MHz,256MB) which probably isn't too useful, or my work laptop (mass=7 kg including PSU). One with a working LyX SVN local tree, and a compiler that doesn't run out of steam ;-) /C It's kind of funny that I take off and land at the same time on the way back... Hmmm... I once landed 5 min before departure. - Martin
Re: [patch] bug 1820 --- footnotes in different language
Dov == Dov Feldstern [EMAIL PROTECTED] writes:
Dov Do you know why this whole font-change mechanism was originally
Dov added?
Consider a footnote with several paragraphs and assume it is typeset
in \emph like this:
\emph{Some text\footnote{and and explanation
on several paragraphs}}
This will cause a LaTeX error because the \emph macro will not be
terminated at the end of the first paragraph. This is the reason why
noFontChange was introduced.
Note however the following comment from Inset.h:
/**
* Is this inset allowed within a font change?
*
* FIXME: noFontChange means currently that the font change is closed
* in LaTeX before the inset, and that the contents of the inset
* will be in default font. This should be changed so that the inset
* changes the font again.
*/
virtual bool noFontChange() const { return false; }
and this:
/** Needed to propagate font changes to all text cells of insets
* that are not allowed inside a font change (bug 1973).
* Must not be called if \p pos denotes an ordinary character or an
* inset that is alowed inside a font change.
* FIXME: This should be removed, see documentation of noFontChange
* in insetbase.h
*/
void setInsetFont(Buffer const buffer, pit_type pit, pos_type pos,
Font const font, bool toggleall = false);
Dov Regarding the format change: why is this a format change?
The problem is that noFontChange is used in other contexts and nobody
really knows how to clean it up (grep is your friend).
JMarc
Re: r19028 - in /lyx-devel/branches/BRANCH_1_4_X: src/fronten...
Peter Kümmel wrote: What about using my patch and to replace the QLibrary code with your native calls? I think using native calls is safer. This is the standard method that is known to work on all Windows versions. You should not use #define _WIN32_WINNT 0x0500 because it may cause other include files (like boost) to think Windows 2000 functions can be used. Joost
Re: FuncRequest/dispatch goals
Tommaso == Tommaso Cucinotta [EMAIL PROTECTED] writes: Tommaso Jean-Marc Lasgouttes ha scritto: Except if this serialization can be merged with the writing of the xml parameters once we switch to that. In this case, the thing would make more sense (and allow to define bindings to tune individual parameters). Tommaso Is it possible to have brief description of what is this Tommaso writing of XML params (or just a pointer to archived mail Tommaso or wiki page, if any) ? Basically, the main stated plan for the 1.6 branch is switching our file format to some correctly formed xml. There is already some proof-of-concept code to do that in a branch. This will force us to have a more unified way to access the parameters, and I was arguing that we could _maybe_ leverage this for dialog/kernel interaction. Since we are not very organised people, there is no wiki to see. You can try to search for XML in the archives or look at this branch: http://www.lyx.org/trac/browser/lyx-devel/branches/personal/larsbj/xml However, I relaize now that this will probably not be very useful for dialogs like search/replace which are not related to the file format. JMarc
Re: Deadline of translations?
Bo == Bo Peng [EMAIL PROTECTED] writes: There is a file, called po/LINGUAS, that is used by Makefile. If you remove some language entries from it, the build process should still work. Bo It sounds like we need a LINGUAS_dist file that will be used by Bo make dist. :-) No, just shortening LINGUAS is enough. This is what we do in 1.4. JMarc
Re: INSTALL.cmake
Peter == Peter Kümmel [EMAIL PROTECTED] writes: Peter Could we rename README.cmake into INSTALL.cmake and move it to Peter top level trunk? Here is the patch I am going to commit. Note that I took the liberty to actually distribute the cmake files :) It seems that you forgot to check the release tar files... Faulty QA! Peter It would be great if someone could also have a look at the Peter content, layout, English, formating, ... I'll leave that to someone else. JMarc
Re: INSTALL.cmake
Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Peter == Peter Kümmel [EMAIL PROTECTED] writes: Peter Could we rename README.cmake into INSTALL.cmake and move it to Peter top level trunk? Jean-Marc Here is the patch I am going to commit. Hmmph. Index: development/cmake/README.cmake === --- development/cmake/README.cmake (révision 19033) +++ development/cmake/README.cmake (copie de travail) @@ -1,82 +0,0 @@ -Building LyX with CMake - -For all builds: -- CMake 2.4 or CVS version from www.cmake.org -- install Qt 4 and make sure qmake 4 is found - (add the folder with qmake to the environment variable PATH) -- by default it builds the Qt4 frontend -- with GNUWIN32_DIR you could point to your gnuwin32 packages - (eg. -DGNUWIN32_DIR=c:\gnuwin32) by default it searches in your - program folder - -Building Visual C++ 2005 project files: -- install Visual C++ 2005 -- install Platform SDK 2005, Core and Web Workshop -- add include and library paths of the SDK to the IDE search paths, - menu: Tools-Options-VC++ directories-Library files + Include files -- install zlib (www.zlib.net) into %ProgramFiles%/GnuWin32/include+lib - or %ProgramFiles%/zlib/include+lib -- create a build directory, e.g. .../trunk/../build -- call in the build directory 'cmake ..\trunk\development\cmake' -- start lyx.sln -- Warnings: - The default warning level of the msvc cmake builds is now /W4. - The cmake option - -DDISABLEWALL=1 - switches to /W3, - -DWALL=1 - re enables /W4. - To disable a specific warning add it to MSVC_W_DISABLE of - cmake/CMakeLists.txt. To make the warning an error add it - to MSVC_W_ERROR of the same file. - -TIPS: - rename Microsoft Visual Studio 8\VC\vcpackages\feacp.dll -to disable Intellisense - - the Release build links much faster - - for the 'Debug' and 'Release' build all precompiled headers are enabled -to compile without pch (to check if all necessary headers are included) - * use 'MinSizeRel' which only precompiles the STL and Boost headers - * use 'RelWithDebInfo' which does not use any precompiled headers - - -Building with GCC/Linux: -- create a build directory, e.g. .../trunk/../build -- call in the build directory 'cmake ..\trunk\development\cmake' - -Building with GCC/Windows (Win2k only works with MSYS, XP?): -- install zlib (www.zlib.net) into %ProgramFiles%/GnuWin32/include+lib -- create a build directory, e.g. .../trunk/../build -- call: export QMAKESPEC=win32-g++ (MSYS) or set QMAKESPEC=win32-g++ (CMD) -- call in the build directory 'cmake ..\trunk\development\cmake' - -Building with Xcode/Mac: -- create a build directory, e.g. .../trunk/../build -- call in the build directory 'cmake .../trunk/development/cmake -G Xcode' -- open .../trunk/../build/lyx-qt4.xcodeproj - -TIPS: - Xcode prefers UTF8 when opening source files, though LyX usually uses -Latin1. To fix that select all source files in Xcode and click Get Info -in the context menu. Change the encoding to Latin1. - - You can run and debug LyX from Xcode. For LyX to find its resources, there -are two possibilities: - a) Put a resource directory, e.g. a link to the lib directory of the - source tree, at .../trunk/../build/bin/Resources - b) Select the lyx-qt4 executable in Xcode, click on Get Info in the - context menu and add -sysdir a_valid_LyX_resource_directory - pointing e.g. to a valid Contents/Resources of a LyX.app directory. - - LyX on Mac doesn't look for fonts in the resource directory if the -executable is not in an .app bundle. Instead you have to create a -symbolic link to the fonts directory in the place where the executable -is: ln -s .../trunk/lib/fonts .../trunk/../build/bin/Debug/ -If you don't do that math character will not show up correctly. - - CMake properly finds the Qt4 library bundles from Trolltech's binary -Qt4 package for Mac. So no need to compile Qt on your own. - - -To generate other build files call 'cmake' -which shows a list of possibilities. - - -The build process tries to find aspell on Windows -in %ProgramFiles%/GnuWin32/ and in /usr/ or in /usr/local -under Linux. If it is not found the support is disabled. Index: development/scons/scons_manifest.py === --- development/scons/scons_manifest.py (révision 19033) +++ development/scons/scons_manifest.py (copie de travail) @@ -10,6 +10,7 @@ INSTALL.MacOSX INSTALL.Win32 INSTALL.autoconf +INSTALL.cmake INSTALL.scons Makefile.am NEWS Index: development/Makefile.am === --- development/Makefile.am (révision 19033) +++ development/Makefile.am (copie de travail) @@ -4,7 +4,7 @@ SUBDIRS = MacOSX endif -EXTRA_DIST = boostworkaround.txt ChangeLog Code_rules FORMAT \
Re: Help in understanding GUI structure
Abdelrazak Younes wrote: Tommaso Cucinotta wrote: Hi, I'm not managing to figure out where, in the LyX code, it is decided where to put the GuiWorkArea instance into the main window (LyXView) layout. In GuiImplementation::newWorkArea() but this might change in the future to be put directly in LyXView. By the way, you should probably read the documentation about LyXView/WorkArea interaction and more in src/frontend/Application.h which I reproduce here: Model/View/Controller separation in LyX: 1) The Model: \c Buffer The Buffer is the in-memory representation of a LyX file format. The Buffer does not (should not) have any information on what part of it is represented on screen. There is one unique Buffer per opened LyX file. 2) The Controller: \c BufferView / \c Painter The BufferView is a tool used by the view that translates a part of the Buffer contents into drawing routines. The BufferView asks each inset of the Buffer to draw itself onto the screen using the Painter. There can be only one Buffer displayed in a BufferView. While there is the possibility to switch Buffer inside the BufferView, the goal is to instantiate a new BufferView on each Buffer switch. \todo Instantiate a new BufferView on each Buffer switch. The \c Painter is just a virtual interface to formalize each kind of drawing routines (text, line, rectangle, etc). The \c BufferView also contains a Cursor which may or may not be visible on screen. The cursor is really just a bookmark to remember where the next Buffer insertion/deletion is going to take place. 3) The View: \c WorkArea (and it's qt4 specialisation GuiWorkArea) This contains the real screen area where the drawing is done by the Painter. One WorkArea holds one unique \c BufferView. While it could be possible that multiple WorkArea share one BufferView, this is not possible right now. The WorkArea also provide a scrollbar which position is translated into scrolling command to the inner \c BufferView. The WorkArea use the BufferView to translate each keyboard or mouse events into terms that the Buffer can understand: - insert/delete char - select char - etc. 4) The Window: \c LyXView (and its qt4 specialisation \c GuiView) This is a full window containing a menubar, toolbars, a tabbar and a WorkArea. One LyXView could in theory contain multiple WorkArea (ex: with split window) but this number is limited to one only for now. In any case, there would be only one WorkArea that gets the focus at a time. Now, concerning the TabBar versus TabWidget issue. Right now, there is only one WorkArea and the TabBar just used to tell the BufferView inside the WorkArea to switch to this another Buffer. With a TabWidget, each Tab would own its own \c WorkArea. Clicking on a tab would switch a WorkArea instead of a Buffer.
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: FuncRequest/dispatch goals
Jean-Marc Lasgouttes ha scritto: Basically, the main stated plan for the 1.6 branch is switching our file format to some correctly formed xml. There is already some proof-of-concept code to do that in a branch. This will force us to What about the OO OpenDocument xml format ? Would it be too complex for LyX ? Also, reading about these ideas to have an all-in-one container file format, I'm wondering if, at the end, you won't end up into an xml spec that is someway similar to that. Plus, what about maths ? Would they be represented as smth. like MathML instead of plain LaTeX that you have now ? T. -- Tommaso Cucinotta, Computer Engineering PhD, Researcher ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy Tel +39 050 882 024, Fax +39 050 882 003 http://feanor.sssup.it/~tommaso
Re: r19028 - in /lyx-devel/branches/BRANCH_1_4_X: src/fronten...
On Wed, Jul 11, 2007 at 09:14:27AM +0200, Joost Verburg wrote:
Peter Kümmel wrote:
What about using my patch and to replace the QLibrary code with your
native calls?
I think using native calls is safer. This is the standard method that is
known to work on all Windows versions. You should not use #define
_WIN32_WINNT 0x0500 because it may cause other include files (like
boost) to think Windows 2000 functions can be used.
Please, find attached your patch complemented with the changes
for cygwin.
--
Enrico
Index: src/support/os_cygwin.cpp
===
--- src/support/os_cygwin.cpp (revision 19033)
+++ src/support/os_cygwin.cpp (working copy)
@@ -40,6 +40,11 @@ using lyx::support::addName;
using lyx::support::addPath;
using lyx::support::package;
+// API definition for manually calling font functions on Windows 2000 and later
+typedef int (WINAPI *FONTAPI)(LPCSTR, DWORD, PVOID);
+#define FR_PRIVATE 0x10
+
+// Names of TrueType fonts to load
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);
@@ -330,12 +335,23 @@ void addFontResources()
// Windows only: Add BaKoMa TrueType font resources
string const fonts_dir =
addPath(package().system_support().absFilename(), fonts);
+ HMODULE hDLL = LoadLibrary(gdi32);
+ FONTAPI pAddFontResourceEx =
+ (FONTAPI) GetProcAddress(hDLL, AddFontResourceExA);
+
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 (pAddFontResourceEx) {
+ // Windows 2000 and later: Use AddFontResourceEx
+ pAddFontResourceEx(font_current.c_str(), FR_PRIVATE, 0);
+ } else {
+ // Older Windows versions: Use AddFontResource
+ AddFontResource(font_current.c_str());
+ }
}
+ FreeLibrary(hDLL);
#endif
}
@@ -346,12 +362,22 @@ void restoreFontResources()
// Windows only: Remove BaKoMa TrueType font resources
string const fonts_dir =
addPath(package().system_support().absFilename(), fonts);
+ HMODULE hDLL = LoadLibrary(gdi32);
+ FONTAPI pRemoveFontResourceEx = (FONTAPI) GetProcAddress(hDLL,
RemoveFontResourceExA);
+
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 (pRemoveFontResourceEx) {
+ // Windows 2000 and later: Use RemoveFontResourceEx
+ pRemoveFontResourceEx(font_current.c_str(), FR_PRIVATE,
0);
+ } else {
+ // Older Windows versions: Use RemoveFontResource
+ RemoveFontResource(font_current.c_str());
+ }
}
+ FreeLibrary(hDLL);
#endif
}
Index: src/support/os_win32.cpp
===
--- src/support/os_win32.cpp(revision 19033)
+++ src/support/os_win32.cpp(working copy)
@@ -74,6 +74,11 @@ using lyx::support::addName;
using lyx::support::addPath;
using lyx::support::package;
+// API definition for manually calling font functions on Windows 2000 and later
+typedef int (WINAPI *FONTAPI)(LPCSTR, DWORD, PVOID);
+#define FR_PRIVATE 0x10
+
+// Names of TrueType fonts to load
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);
@@ -408,11 +413,22 @@ void addFontResources()
// Windows only: Add BaKoMa TrueType font resources
string const fonts_dir =
addPath(package().system_support().absFilename(), fonts);
+ HMODULE hDLL = LoadLibrary(gdi32);
+ FONTAPI pAddFontResourceEx = (FONTAPI) GetProcAddress(hDLL,
AddFontResourceExA);
+
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 (pAddFontResourceEx) {
+ // Windows 2000 and later: Use AddFontResourceEx for
private font
+
pAddFontResourceEx(to_local8bit(from_utf8(external_path(font_current))).c_str(),
Re: FuncRequest/dispatch goals
Tommaso == Tommaso Cucinotta [EMAIL PROTECTED] writes: Tommaso What about the OO OpenDocument xml format ? Would it be too Tommaso complex for LyX ? The lyx document format is supposed to reflect what LyX is able to handle. I am not sure ODF is usable, since we have no plan to implement openoffice on top of LyX :) Tommaso Also, reading about these ideas to have an all-in-one Tommaso container file format, I'm wondering if, at the end, you Tommaso won't end up into an xml spec that is someway similar to Tommaso that. Maybe. Tommaso Plus, what about maths ? Would they be represented as smth. Tommaso like MathML instead of plain LaTeX that you have now ? I think there are problems related to that (latex (and lyx) LyX is more on the presentational side). JMarc
Re: FuncRequest/dispatch goals
Jean-Marc Lasgouttes wrote: Tommaso == Tommaso Cucinotta [EMAIL PROTECTED] writes: Tommaso What about the OO OpenDocument xml format ? Would it be too Tommaso complex for LyX ? The lyx document format is supposed to reflect what LyX is able to handle. I am not sure ODF is usable, since we have no plan to implement openoffice on top of LyX :) This does not mean we should not reuse the same tags as ODF. But as Lars said once, we can modify the tags later. Tommaso Plus, what about maths ? Would they be represented as smth. Tommaso like MathML instead of plain LaTeX that you have now ? I think there are problems related to that (latex (and lyx) LyX is more on the presentational side). The main problem is that mathml is bloody verbose. I think you can now embed TeX math in ODF too. Abdel.
Re: Re: [Patch] allow unicode in layout style name
Jean-Marc Lasgouttes a écrit : Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Why not? It is easier to use has a file with coherent encoding that one that uses a mixed encoding. Abdelrazak I agree with Jose. I cannot see a reason why mixed Abdelrazak encoding would be preferred. I am not sure we are discussing the same thing. Assume one has a file in 1.4 file format with contents in latin1 and some layout names in latin1 too. What do you propose to do? I see two solutions. 1/ first convert the latin1 file to utf8 in one sweep and hope that lyx2lyx will not butcher it when translating to 1.5 file format 2/ first convert to 1.5 file format. Then only the layout names should be converted in a second step. I do not think that iconv would appreciate to see UTF8 characters in a file which is supposed to be latin1. JMarc Hi, I just had time to test Abdel patch layout_name_is_unicode.patch with the latest svn: After a quick test I think it works perfectly! All my layouts (converted in UTF-8) are recognized and lyx accept to open every files created with previous versions (in fact almost: there is still a problem with old files using the tag \language frenchb and perhaps others...?) as they are (i.e. without any conversion). Thus, for me, this is probably the best solution! Thank you very much PhC
Re: r19028 - in /lyx-devel/branches/BRANCH_1_4_X: src/fronten...
On Wednesday 11 July 2007 10:25:44 Enrico Forestieri wrote: Please, find attached your patch complemented with the changes for cygwin. This can go with two OKs. I guess that Joost, Uwe, Peter or Abdel are the obvious candidates. -- Enrico -- José Abílio
Re: [patch] tiny cosmetics
On Wednesday 11 July 2007 07:31:39 Jürgen Spitzmüller wrote: this is really just to make the paragraph dialog look a little bit more compact, i.e. I reduced the ugly whitespace on the bottom, no other change. OK to commit? OK. Jürgen -- José Abílio
Re: INSTALL.cmake
On Wednesday 11 July 2007 08:30:29 Jean-Marc Lasgouttes wrote: Jean-Marc Here is the patch I am going to commit. Hmmph. OK. -- José Abílio
Re: FuncRequest/dispatch goals
On Wednesday 11 July 2007 10:30:47 Jean-Marc Lasgouttes wrote: Tommaso Plus, what about maths ? Would they be represented as smth. Tommaso like MathML instead of plain LaTeX that you have now ? I think there are problems related to that (latex (and lyx) LyX is more on the presentational side). MathML supports both methods (presentational and content) although I think you can't mix them (reasonable IMHO). JMarc -- José Abílio
Re: r19028 - in /lyx-devel/branches/BRANCH_1_4_X: src/fronten...
José Matos wrote: On Wednesday 11 July 2007 10:25:44 Enrico Forestieri wrote: Please, find attached your patch complemented with the changes for cygwin. This can go with two OKs. I guess that Joost, Uwe, Peter or Abdel are the obvious candidates. OK. Joost
Re: r19028 - in /lyx-devel/branches/BRANCH_1_4_X: src/fronten...
Joost Verburg wrote: José Matos wrote: On Wednesday 11 July 2007 10:25:44 Enrico Forestieri wrote: Please, find attached your patch complemented with the changes for cygwin. This can go with two OKs. I guess that Joost, Uwe, Peter or Abdel are the obvious candidates. OK. I don't know much about Win32 API but the code seems correct to me. I trust Enrico and Joost about this. Abdel.
Re: r19028 - in /lyx-devel/branches/BRANCH_1_4_X: src/fronten...
On Wed, Jul 11, 2007 at 10:56:07AM +0100, José Matos wrote: On Wednesday 11 July 2007 10:25:44 Enrico Forestieri wrote: Please, find attached your patch complemented with the changes for cygwin. This can go with two OKs. I guess that Joost, Uwe, Peter or Abdel are the obvious candidates. I think that this can go in, then. Indeed, this is simply an extension to cygwin of the patch by Joost which I tried and found working. Peter agreed to use this patch with the extension I made (use Joost method in his patch). So, me, Peter, and Joost are endorsing this patch. That makes 3 crossed OKs ;-) -- Enrico
Re: r19028 - in /lyx-devel/branches/BRANCH_1_4_X: src/fronten...
Enrico Forestieri wrote: On Wed, Jul 11, 2007 at 10:56:07AM +0100, José Matos wrote: On Wednesday 11 July 2007 10:25:44 Enrico Forestieri wrote: Please, find attached your patch complemented with the changes for cygwin. This can go with two OKs. I guess that Joost, Uwe, Peter or Abdel are the obvious candidates. I think that this can go in, then. Indeed, this is simply an extension to cygwin of the patch by Joost which I tried and found working. Peter agreed to use this patch with the extension I made (use Joost method in his patch). So, me, Peter, and Joost are endorsing this patch. That makes 3 crossed OKs ;-) Don't forget to close the bug :-) Abdel.
Re: r19028 - in /lyx-devel/branches/BRANCH_1_4_X: src/fronten...
On Wed, Jul 11, 2007 at 12:08:06PM +0200, Abdelrazak Younes wrote: Joost Verburg wrote: José Matos wrote: On Wednesday 11 July 2007 10:25:44 Enrico Forestieri wrote: Please, find attached your patch complemented with the changes for cygwin. This can go with two OKs. I guess that Joost, Uwe, Peter or Abdel are the obvious candidates. OK. I don't know much about Win32 API but the code seems correct to me. I trust Enrico and Joost about this. As too many cooks are working on it, I think that some coordination is needed ;-) So, please Joost go ahead and commit it. -- Enrico
Re: r19028 - in /lyx-devel/branches/BRANCH_1_4_X: src/fronten...
Enrico Forestieri wrote: On Wed, Jul 11, 2007 at 12:08:06PM +0200, Abdelrazak Younes wrote: Joost Verburg wrote: José Matos wrote: On Wednesday 11 July 2007 10:25:44 Enrico Forestieri wrote: Please, find attached your patch complemented with the changes for cygwin. This can go with two OKs. I guess that Joost, Uwe, Peter or Abdel are the obvious candidates. OK. I don't know much about Win32 API but the code seems correct to me. I trust Enrico and Joost about this. As too many cooks are working on it, I think that some coordination is needed ;-) Then you are not a good coordinator ;-). It's simpler for the last who touched the patch to commit it, so that should be you :-) Abdel.
[PATCH] remove obsolete translations (was Re: Deadline of translations?)
Bo == Bo Peng [EMAIL PROTECTED] writes: This would mean to remove the following: da fi ru sk sl nl pt wa sv Bo plus zh_CN.po Jose', is the following patch OK? JMarc Index: po/LINGUAS === --- po/LINGUAS (révision 19034) +++ po/LINGUAS (copie de travail) @@ -1,2 +1,2 @@ # The list of languages known to LyX -cs da de es eu fi fr gl hu it ja ko nl nn nb pl ro ru sk sl tr ca he pt sv wa zh_CN zh_TW +cs de es eu fr gl hu it ja ko nn nb pl ro tr ca he zh_TW
Re: [Patch] allow unicode in layout style name (was Re: Upgrade from 1.4 to 1.5)
On Tue, 10 Jul 2007, José Matos wrote: On Tuesday 10 July 2007 15:16:56 [EMAIL PROTECTED] wrote: What's the risk of embarrassing[*] bugs? (As this is just before the release of 1.5.0). There is no RC3 planned, right? Do you want a formula with deltas and epsilons? ;-) No there is not any RC3 planned. Do you think we need one? Not if you don't, it's your call. Just wanted to mention the possibility. Regarding this subject I think that this course of action is sound so I don't expect any major surprises. (Famous last words). If something does happen, your words might well make it into LyX's famous quotes :-) /C -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: [PATCH] remove obsolete translations (was Re: Deadline of translations?)
On Wednesday 11 July 2007 11:32:34 Jean-Marc Lasgouttes wrote: Jose', is the following patch OK? JMarc Yes. -- José Abílio
Re: [Patch] allow unicode in layout style name
On Tuesday 10 July 2007 15:13:49 Philippe Charpentier wrote: (in fact almost: there is still a problem with old files using the tag \language frenchb and perhaps others...?) as they are (i.e. without any conversion). lyx2lyx converts those documents coming from 1.3.x or before. Isn't that working? Thus, for me, this is probably the best solution! Thank you very much PhC -- José Abílio
Re: [Patch] allow unicode in layout style name (was Re: Upgrade from 1.4 to 1.5)
On Wednesday 11 July 2007 11:33:32 [EMAIL PROTECTED] wrote: Regarding this subject I think that this course of action is sound so I don't expect any major surprises. (Famous last words). If something does happen, your words might well make it into LyX's famous quotes :-) AFAIU the right solution implies a synchronised change for layout2layout and lyx2lyx. This also implies to distinguish between the style GUI name and the style ID, with the style ID being an ascii identifier. The amount of changes required to have this properly implemented scares me at such a late stage of the development of 1.5.0. The proper solution should then be implemented at early 1.6 development cycle. So in resume, I am aware that this is not the most elegant implementation but for the moment it is the possible due to our stability constraints. /C -- José Abílio
Re: Open Patches
On Wednesday 04 July 2007 20:44:31 Michael Gerz wrote: Hi, it seems that there are still several patches that may go into 1.5.0. Since José has left us for the rest of the week, I wonder what will happen to these patches: - RTL Justification Bug (bug3889.2.patch, 26/06/07) by Dov - Bug fix #3600 (30/06/07) by Alfredo - Image Cache Fix (3819.diff, 30/06/07) by Jürgen Georg - Unicode Bug fixes (#3313 #3498, 01/07/07) by Jürgen - Toolbar patch (01/07/07) by myself - default-encoding.2.patch (01/07/07) by Dov - Current Language (#3959, 01/07/07) by Dov - Author field fix (03/07/07) by JMarc myself - Windows font patch (03/07/07) by Peter - Include file crash fix (#3970, 05/07/07) by Abdel I think some of these patches just require a second OK by a competent developer. AFAIR most have been applied already. What are the patches from this batch that did not had any comment so far? Kind regards, Michael -- José Abílio
Re: [PATCH] compiling on Mac OS X
On Thursday 05 July 2007 08:30:13 Jean-Marc Lasgouttes wrote: So, to conclude, José, can I apply the patch below? It is quite straightforward and I think it is needed for proper pkg-config support (the only problem is that it is not completely correct with multiple frontends, but this is a problem for later IMO). OK if if I did not said this before. JMarc -- José Abílio
Re: tetex-upmethodology
On Wednesday 04 July 2007 14:53:44 Neal Becker wrote: This looks interesting. Anyone want to make a lyx conversion for this? http://www.arakhne.org/spip.php?article52 Why don't you do it? :-) -- José Abílio
Re: \selectlanguage{} inserts space.
On Tuesday 22 May 2007 06:03:17 John McCabe-Dansted wrote: This *could* be fixed on the LyX end by outputing the apparently equivalent tex code: http://www.csse.uwa.edu.au/~john/lyx/lyxbug_american2.tex (so that the selectlanguage macro is only applied to the text within environments, and not to the environments themselves). LyX could also make harder to accidentally mix english and american text. However this seems like a bug in LaTeX, should LaTeX itself be fixed? I think that you did not had an answer because this is a can of worms that no one is willing to open. :-) -- José Abílio
Re: [PATCH] remove obsolete translations
José == José Matos [EMAIL PROTECTED] writes: José On Wednesday 11 July 2007 11:32:34 Jean-Marc Lasgouttes wrote: Jose', is the following patch OK? José Yes. Applied. JMarc
Re: r19028 - in /lyx-devel/branches/BRANCH_1_4_X: src/fronten...
On Wed, Jul 11, 2007 at 12:23:18PM +0200, Abdelrazak Younes wrote: Enrico Forestieri wrote: On Wed, Jul 11, 2007 at 12:08:06PM +0200, Abdelrazak Younes wrote: Joost Verburg wrote: José Matos wrote: On Wednesday 11 July 2007 10:25:44 Enrico Forestieri wrote: Please, find attached your patch complemented with the changes for cygwin. This can go with two OKs. I guess that Joost, Uwe, Peter or Abdel are the obvious candidates. OK. I don't know much about Win32 API but the code seems correct to me. I trust Enrico and Joost about this. As too many cooks are working on it, I think that some coordination is needed ;-) Then you are not a good coordinator ;-). It's simpler for the last who touched the patch to commit it, so that should be you :-) So, in the end I did it... -- Enrico
[PATCH] bug 3862: Inconsistency of appendix with child documents
http://bugzilla.lyx.org/show_bug.cgi?id=3862
This is about numbering that is not correct when a document has an
appendix and child documents. The following patch, by Abdel and me,
solves it in a straightforward manner that could additionally be see
as a cleanup.
IMO this could go in 1.5.0, although 1.5.1 would not be a big problem
(cosmetic issue).
JMarc
Index: buffer_funcs.cpp
===
--- buffer_funcs.cpp (revision 19033)
+++ buffer_funcs.cpp (working copy)
@@ -474,16 +474,13 @@
Layout_ptr const layout = par.layout();
Counters counters = textclass.counters();
- if (it.pit() == 0) {
- par.params().appendix(par.params().startOfAppendix());
- } else {
- par.params().appendix(it.plist()[it.pit() - 1].params().appendix());
- if (!par.params().appendix()
- par.params().startOfAppendix()) {
- par.params().appendix(true);
- textclass.counters().reset();
- }
+ if (par.params().startOfAppendix()) {
+ // FIXME: only the counter corresponding to toplevel
+ // sectionning should be reset
+ counters.reset();
+ counters.appendix(true);
}
+ par.params().appendix(counters.appendix());
// Compute the item depth of the paragraph
par.itemdepth = getItemDepth(it);
@@ -697,12 +694,12 @@
void updateLabels(Buffer const buf, bool childonly)
{
+ Buffer const * const master = buf.getMasterBuffer();
// Use the master text class also for child documents
- TextClass const textclass = buf.params().getTextClass();
+ TextClass const textclass = master-params().getTextClass();
if (!childonly) {
// If this is a child document start with the master
- Buffer const * const master = buf.getMasterBuffer();
if (master != buf) {
updateLabels(*master);
return;
Index: Counters.cpp
===
--- Counters.cpp (revision 19033)
+++ Counters.cpp (working copy)
@@ -177,6 +177,7 @@
void Counters::reset()
{
+ appendix_ = false;
CounterList::iterator it = counterList.begin();
CounterList::iterator const end = counterList.end();
for (; it != end; ++it) {
Index: Counters.h
===
--- Counters.h (revision 19033)
+++ Counters.h (working copy)
@@ -82,6 +82,10 @@
/// A complete expanded label, like 2.1.4 for a subsubsection
/// according to the given format
lyx::docstring counterLabel(lyx::docstring const format);
+ ///
+ bool appendix() const { return appendix_; };
+ ///
+ void appendix(bool a) { appendix_ = a; };
private:
/// A counter label's single item, 1 for subsection number in
/// the 2.1.4 subsubsection number label.
@@ -91,6 +95,8 @@
typedef std::maplyx::docstring, Counter CounterList;
/// Instantiate.
CounterList counterList;
+ ///
+ bool appendix_;
};
Re: [PATCH] bug 3862: Inconsistency of appendix with child documents
On Wednesday 11 July 2007 13:00:33 Jean-Marc Lasgouttes wrote: IMO this could go in 1.5.0, although 1.5.1 would not be a big problem (cosmetic issue). JMarc Last time that Abdel propose this it had some problem. Has this been fixed? If yes then OK. -- José Abílio
Re: 1.5.0beta2: export Latex(plain), why must overwrite my EPS graphics files?
On Friday 29 June 2007 04:15:18 Rob wrote: It wouldn't be too much of a problem to let the export go along with the already existing eps file, would it? If so, this option should then be added here Rob. Rob could you add this to bugzilla as an enhancement? That way it will not be forgotten. :-) -- José Abílio
Slow motion while editing
Hello, I haven't closely followed the debates concerning the cursor motion speed and don't know what is the current status (some patches pending?) but as I started work 1.5rc2 the typing speed is slow and to wait when moving with cursor in text is very painful (this applies to situation when i start new document, havent experimentated more up to this moment). But what I accidentally found is, that the whole problem simply disappears in the moment I copy and paste some text. Is this known ? Bye, Pavel
Re: 1.4.4 - 1.5.0beta2: citation problem in PS and DVI output.
On Friday 29 June 2007 03:20:05 Rob wrote: Rob wrote: Hi, The upgrade from Fedora 6 to 7 confronted me with an automagically upgrade of LyX from 1.4.4 to 1.5.0beta2. So, after the Fedora upgrade, I started LyX (looks good!) and opened my 1.4.4 document. It looks alright, but the citations in the postscript and dvi output look awkward. A citation that should become like [1] (without the quotes), now looks like (author?)[1], where (author?) is in bold. Any idea why this is going wrong? Is this still the case with rc2? You can follow the same procedure as described in this thread to update to the version available in updates-testing. -- José Abílio
Re: Crashing when pressing enter...
On Tuesday 26 June 2007 14:20:49 Alexander Streit wrote: wrong pos 782, max is 710 at level 1. Trying to correct this. old: inset: 01651D90 idx: 0 par: 118 pos: 782 new: inset: 01651D90 idx: 0 par: 118 pos: 710 wrong pos 782, max is 710 at level 1. Trying to correct this. old: inset: 01651D90 idx: 0 par: 118 pos: 782 new: inset: 01651D90 idx: 0 par: 118 pos: 710 Completed. Does this happens with rc2? -alex -- José Abílio
Re: [PATCH] bug 3862: Inconsistency of appendix with child documents
José == José Matos [EMAIL PROTECTED] writes: José Last time that Abdel propose this it had some problem. Has this José been fixed? Don't you see how my proposed solution is elegant? It solves all known and unknown problems! José If yes then OK. Thanks. JMarc
Exception when opening Document-settings on Solaris
Hello, All is OK with 1.5.0rc2, but with 1.5.0-svn, when I want to edit the settings of a template document on Solaris 2.8/Qt4.3.1, I get this: Caught normal exception: locale::facet::_S_create_c_locale name not valid Program received signal SIGABRT, Aborted. 0xfdf592f0 in __sigprocmask () from /usr/lib/libthread.so.1 (gdb) bt #0 0xfdf592f0 in __sigprocmask () from /usr/lib/libthread.so.1 #1 0xfdf4e59c in _resetsig () from /usr/lib/libthread.so.1 #2 0xfdf4dd3c in _sigon () from /usr/lib/libthread.so.1 #3 0xfdf50d98 in _thrp_kill () from /usr/lib/libthread.so.1 This backtrace seems minimal, should I recompile with --enable-debug ? -- Jean-Pierre PS : locale: LANG=C LC_CTYPE=iso_8859_1 LC_NUMERIC=C LC_TIME=C LC_COLLATE=C LC_MONETARY=C LC_MESSAGES=C LC_ALL=
Re: Exception when opening Document-settings on Solaris
Jean-Pierre Chrétien wrote: Hello, All is OK with 1.5.0rc2, but with 1.5.0-svn, when I want to edit the settings of a template document on Solaris 2.8/Qt4.3.1, I get this: Caught normal exception: locale::facet::_S_create_c_locale name not valid Program received signal SIGABRT, Aborted. 0xfdf592f0 in __sigprocmask () from /usr/lib/libthread.so.1 (gdb) bt #0 0xfdf592f0 in __sigprocmask () from /usr/lib/libthread.so.1 #1 0xfdf4e59c in _resetsig () from /usr/lib/libthread.so.1 #2 0xfdf4dd3c in _sigon () from /usr/lib/libthread.so.1 #3 0xfdf50d98 in _thrp_kill () from /usr/lib/libthread.so.1 This backtrace seems minimal, should I recompile with --enable-debug ? Yes, and possibly --enable-stdlib-debug if that is not already set by default. Abdel.
Re: [Patch] allow unicode in layout style name (was Re: Upgrade from 1.4 to 1.5)
José Matos wrote: On Wednesday 11 July 2007 11:33:32 [EMAIL PROTECTED] wrote: Regarding this subject I think that this course of action is sound so I don't expect any major surprises. (Famous last words). If something does happen, your words might well make it into LyX's famous quotes :-) AFAIU the right solution implies a synchronised change for layout2layout and lyx2lyx. This also implies to distinguish between the style GUI name and the style ID, with the style ID being an ascii identifier. I disagree, IMHO supporting unicode layout names is the right solution for the user. The amount of changes required to have this properly implemented scares me at such a late stage of the development of 1.5.0. I agree with this. The proper solution should then be implemented at early 1.6 development cycle. So in resume, I am aware that this is not the most elegant implementation but for the moment it is the possible due to our stability constraints. So, shall I commit? The conversion from latin-1 to UTF-8 encodings can happen afterwards because all our layout files contains only ascii style names. Abdel.
Re: [PATCH] bug 3862: Inconsistency of appendix with child documents
José Matos wrote: On Wednesday 11 July 2007 13:00:33 Jean-Marc Lasgouttes wrote: IMO this could go in 1.5.0, although 1.5.1 would not be a big problem (cosmetic issue). JMarc Last time that Abdel propose this it had some problem. Has this been fixed? My first proposal was different and hackish. This proposal from JMarc is much better I admit :-) Abdel.
Re: [PATCH] bug 3862: Inconsistency of appendix with child documents
José == José Matos [EMAIL PROTECTED] writes: José If yes then OK. Applied. Jmarc
Re: Slow motion while editing
Pavel == Pavel Sanda [EMAIL PROTECTED] writes: Pavel Hello, I haven't closely followed the debates concerning the Pavel cursor motion speed and don't know what is the current status Pavel (some patches pending?) but as I started work 1.5rc2 the typing Pavel speed is slow and to wait when moving with cursor in text is Pavel very painful (this applies to situation when i start new Pavel document, havent experimentated more up to this moment). Pavel But what I accidentally found is, that the whole problem simply Pavel disappears in the moment I copy and paste some text. Is this Pavel known ? I do not like that... It looks like a problem with persistent selection, but I cannot reproduce it. JMarc
Re: [Patch] allow unicode in layout style name
José Abilio a écrit : On Tuesday 10 July 2007 15:13:49 Philippe Charpentier wrote: (in fact almost: there is still a problem with old files using the tag \language frenchb and perhaps others...?) as they are (i.e. without any conversion). lyx2lyx converts those documents coming from 1.3.x or before. Isn't that working? When I open some old files I obtain the following error: Traceback (most recent call last): File /usr/local/lyx-1.5-UTF-8/share/lyx/./lyx2lyx/lyx2lyx, line 101, in module sys.exit(main(sys.argv)) File /usr/local/lyx-1.5-UTF-8/share/lyx/./lyx2lyx/lyx2lyx, line 92, in main file = LyX.File(end_format, input, output, error, debug, try_hard, cjk_encoding) File /usr/local/lyx-1.5-UTF-8/share/lyx/lyx2lyx/LyX.py, line 556, in __init__ self.read() File /usr/local/lyx-1.5-UTF-8/share/lyx/lyx2lyx/LyX.py, line 242, in read self.encoding = get_encoding(self.language, self.inputencoding, self.format, self.cjk_encoding) File /usr/local/lyx-1.5-UTF-8/share/lyx/lyx2lyx/LyX.py, line 128, in get_encoding return lang[language][3] KeyError: 'frenchb' Error: Échec du script de conversion but, if I manually replace \language frenchb by \language french in the file, lyx2lyx converts it successfully... PhC
[Patch] Fix bug 3719: TOC skip-to points out of sync with document
http://bugzilla.lyx.org/show_bug.cgi?id=3719 As explained in bugzilla, the problem is that the full toc is not regenerated when creating standard (i.e unnembered) paragraph. As the TocBackEnd use ParIterator for in buffer jumps, this can get out of sync. The partial updateLabel() is my doing and comes before the TocBackend stuf. I will replace all partial with full updatelabels() as soon as I commit my other pending patch. This patch is very very safe and fixes a crash. Abdel.
Re: Slow motion while editing
Jean-Marc Lasgouttes wrote: Pavel == Pavel Sanda [EMAIL PROTECTED] writes: Pavel Hello, I haven't closely followed the debates concerning the Pavel cursor motion speed and don't know what is the current status Pavel (some patches pending?) but as I started work 1.5rc2 the typing Pavel speed is slow and to wait when moving with cursor in text is Pavel very painful (this applies to situation when i start new Pavel document, havent experimentated more up to this moment). Pavel But what I accidentally found is, that the whole problem simply Pavel disappears in the moment I copy and paste some text. Is this Pavel known ? I do not like that... It looks like a problem with persistent selection, but I cannot reproduce it. Yes and it looks like it is the same strange issue reported by Darren Freeman a while ago. I guess this is fixed with the recent selection cleanup. Pavel, could you try latest svn? Abdel.
Re: [Patch] allow unicode in layout style name
On Wednesday 11 July 2007 13:58:29 Philippe Charpentier wrote: lyx2lyx converts those documents coming from 1.3.x or before. Isn't that working? When I open some old files I obtain the following error: How old are those files? What is the file format number for those files? -- José Abílio
Re: [Patch] Fix bug 3719: TOC skip-to points out of sync with document
On Wednesday 11 July 2007 14:07:18 Abdelrazak Younes wrote: This patch is very very safe and fixes a crash. Abdel. OK. -- José Abílio
Re: [Patch] Fix bug 3719: TOC skip-to points out of sync with document
Abdelrazak Younes wrote: http://bugzilla.lyx.org/show_bug.cgi?id=3719 As explained in bugzilla, the problem is that the full toc is not regenerated when creating standard (i.e unnembered) paragraph. As the TocBackEnd use ParIterator for in buffer jumps, this can get out of sync. The partial updateLabel() is my doing and comes before the TocBackend stuf. I will replace all partial with full updatelabels() as soon as I commit my other pending patch. Here is the full patch. Abdel. Index: Text.cpp === --- Text.cpp(revision 19033) +++ Text.cpp(working copy) @@ -644,13 +644,8 @@ break; // the character couldn't be deleted physically due to change tracking } - ParIterator current_it(cur); - ParIterator last_it(cur); - ++last_it; - ++last_it; + updateLabels(cur.buffer()); - updateLabels(cur.buffer(), current_it, last_it); - // A singlePar update is not enough in this case. cur.updateFlags(Update::Force); Index: Text3.cpp === --- Text3.cpp (revision 19033) +++ Text3.cpp (working copy) @@ -375,16 +375,7 @@ recUndo(cur, pit, pit + 1); finishUndo(); std::swap(pars_[pit], pars_[pit + 1]); - - ParIterator begin(cur); - // begin.pos() (== cur.pos()) may point beyond the end of the - // paragraph referenced by begin. This would cause a crash - // in updateLabels() - begin.pos() = 0; - ++cur.pit(); - ParIterator end = boost::next(ParIterator(cur)); - updateLabels(cur.buffer(), begin, end); - + updateLabels(cur.buffer()); needsUpdate = true; break; } @@ -394,17 +385,7 @@ recUndo(cur, pit - 1, pit); finishUndo(); std::swap(pars_[pit], pars_[pit - 1]); - - ParIterator end = ParIterator(cur); - // end.pos() (== cur.pos()) may point beyond the end of the - // paragraph referenced by end. This would cause a crash - // in boost::next() - end.pos() = 0; - end = boost::next(end); - --cur.pit(); - ParIterator begin(cur); - updateLabels(cur.buffer(), begin, end); - + updateLabels(cur.buffer()); needsUpdate = true; break; }
Re: [Patch] allow unicode in layout style name (was Re: Upgrade from 1.4 to 1.5)
On Wednesday 11 July 2007 13:34:18 Abdelrazak Younes wrote: José Matos wrote: On Wednesday 11 July 2007 11:33:32 [EMAIL PROTECTED] wrote: Regarding this subject I think that this course of action is sound so I don't expect any major surprises. (Famous last words). If something does happen, your words might well make it into LyX's famous quotes :-) AFAIU the right solution implies a synchronised change for layout2layout and lyx2lyx. This also implies to distinguish between the style GUI name and the style ID, with the style ID being an ascii identifier. I disagree, IMHO supporting unicode layout names is the right solution for the user. ??? How are we disagreeing? We are discussing an implementation detail, the final result should be the same. Instead of the current: Style Anão ... End I am proposing Style Anao LyXName Anão ... End FWIW anão is dwarf. :-) So, shall I commit? The conversion from latin-1 to UTF-8 encodings can happen afterwards because all our layout files contains only ascii style names. Yes. Abdel. -- José Abílio
Re: [Patch] allow unicode in layout style name
José Abilio à écrit: lyx2lyx converts those documents coming from 1.3.x or before. Isn't that working? When I open some old files I obtain the following error: How old are those files? What is the file format number for those files? The format number of the file I tested is 221 and it was created in 2003 (I think) PhC
Re: [Patch] allow unicode in layout style name (was Re: Upgrade from 1.4 to 1.5)
José Matos wrote: On Wednesday 11 July 2007 13:34:18 Abdelrazak Younes wrote: ??? How are we disagreeing? We are discussing an implementation detail, the final result should be the same. Instead of the current: Style Anão ... End I am proposing Style Anao LyXName Anão ... End That's where we disagree, I don't see a need to force the user to double his work. We'll open the debate again when 1.6.0svn is out if you want :-) FWIW anão is dwarf. :-) So, shall I commit? The conversion from latin-1 to UTF-8 encodings can happen afterwards because all our layout files contains only ascii style names. Yes. Done. Abdel.
Re: [Patch] Fix bug 3719: TOC skip-to points out of sync with document
José Matos wrote: On Wednesday 11 July 2007 14:07:18 Abdelrazak Younes wrote: This patch is very very safe and fixes a crash. Abdel. OK. Done, with some more cleanups in buffer_funcs. Abdel.
Re: [Patch] allow unicode in layout style name
On Wednesday 11 July 2007 14:31:40 Philippe Charpentier wrote: José Abilio à écrit: lyx2lyx converts those documents coming from 1.3.x or before. Isn't that working? When I open some old files I obtain the following error: How old are those files? What is the file format number for those files? The format number of the file I tested is 221 and it was created in 2003 (I think) PhC That makes sense. Would it be possible to send me privately one of those files? It seems that the filter responsible for the convertion is failling and I would like to understand why. In this case it would be enough to study the header section (the part of the file before the real text comes)... -- José Abílio
Re: Exception when opening Document-settings on Solaris
All is OK with 1.5.0rc2, but with 1.5.0-svn, when I want to edit the settings of a template document on Solaris 2.8/Qt4.3.1, I get this: Caught normal exception: locale::facet::_S_create_c_locale name not valid could not be this somehow related to http://bugzilla.lyx.org/show_bug.cgi?id=2738 (ie does it happen before 18988 changeset) ? pavel
Re: Slow motion while editing
but I cannot reproduce it. can you try this ? 1. launch lyx 2. new file + some typing + mark text + copy 3. launch new instance (let the old one running) + new + type some text + try motion pavel
[Patch] Release notes
OK? Index: RELEASE-NOTES === --- RELEASE-NOTES (revision 19042) +++ RELEASE-NOTES (working copy) @@ -1,5 +1,5 @@ This file lists interface changes that might affect users in 1.5.0 and -also some known problems in LyX 1.5.0rc2 that did not occur in +also some known problems in LyX 1.5.0 that did not occur in 1.4.4. Note that fixes are available for many of these, but they have not yet been applied because of incomplete testing. @@ -10,9 +10,33 @@ Some of the LyX functions have changed names : -Known issues with version 1.5.0rc2 +Known issues with version 1.5.0 +- User layout files must be converted to UTF-8 + +In previous version, layout styles were allowed to use non-ASCII names +using the local encodings. LyX-1.5 now assumes that all layout files are +UTF-8 encoded. This means that non-ASCII style names are still allowed +but they nust be valid UTF-8 strings. One way of doing the conversion +is to use iconv. Using bash, the script below should work: + +cd /path/to/layouts +for l in * +do + cp $l tmp.txt + iconv -f latin1 -t utf8 tmp.txt -o $l +done +iconv -f latin1 -t utf8 tmp.txt -o $l + + +- Cursor restoration problems with Multiple-View + +When using multiple Windows to edit different parts of the +same document, the cursor position is sometimes not correctly restored +when you switch from one view to the other. + + Note: There may later be an updated list of known issues online at http://wiki.lyx.org/LyX/ReleaseNotes
Re: Slow motion while editing
Pavel, could you try latest svn? as i wrote a while before it is sometimes more tricky to make this bug happen. but i was able to reproduce it also with svn. pavel
Re: Slow motion while editing
Pavel Sanda wrote: Pavel, could you try latest svn? as i wrote a while before it is sometimes more tricky to make this bug happen. but i was able to reproduce it also with svn. Must be an X11 selection problem cause I can't reproduce under Windows. Abdel.
Re: FuncRequest/dispatch goals
What about the OO OpenDocument xml format ? Would it be too complex for LyX ? It would be discussed after 1.5.0 but ODF may be steered too much to WYSIWYG (single character and paragraph styles etc) to be used by lyx/latex. However, being able to embed figures, and having an internal exporter to ODF would be extremely helpful to lyx.. More after 1.5.0. Bo
Re: [Patch] Release notes
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak OK? OK JMarc
Re: Slow motion while editing
Must be an X11 selection problem cause I can't reproduce under Windows. The report lacks some details but I can not reproduce anything here either. (Linux). I have a fast machine though. Bo
Re: [Patch] Release notes
Abdelrazak Younes [EMAIL PROTECTED] writes: + +cd /path/to/layouts +for l in * +do + cp $l tmp.txt + iconv -f latin1 -t utf8 tmp.txt -o $l +done +iconv -f latin1 -t utf8 tmp.txt -o $l Seems that this last line should be deleted, or maybe replaced by rm tmp.txt In fact, with a set of local layouts existing in 1.4.4 and needing utf8 conversion, it's possible to copy from lyx-1.4.4/layouts to lyx-1.5.0/layouts and do the conversion at the same time (including format upgrade). A bit complicated (assumes lyx-1.4.4 and lyx-1.5.0 dirs) ? -- Jean-Pierre
Re: [Patch] Release notes
Jean-Pierre Chrétien wrote: Abdelrazak Younes [EMAIL PROTECTED] writes: + +cd /path/to/layouts +for l in * +do + cp $l tmp.txt + iconv -f latin1 -t utf8 tmp.txt -o $l +done +iconv -f latin1 -t utf8 tmp.txt -o $l Seems that this last line should be deleted, or maybe replaced by rm tmp.txt I've corrected that, thanks. In fact, with a set of local layouts existing in 1.4.4 and needing utf8 conversion, it's possible to copy from lyx-1.4.4/layouts to lyx-1.5.0/layouts and do the conversion at the same time (including format upgrade). A bit complicated (assumes lyx-1.4.4 and lyx-1.5.0 dirs) ? We could probably make this automatically yes. In Windows, that would be the job of the installer. On Linux there's the possibility to launch a post-install script IIRC. Dunno about Macs. But note that this won't take care of layouts that are along the LyX files (distributed layout). Or is this not possible? Abdel.
listings improvement
I am just trying out listings and it seems pretty good. One problem I see is I just needed to re-indent a bunch of code (happens to be python, so indent matters). I thought maybe I'd just edit the lyx file in emacs, but found out that the form of the listing in the lyx file was not very friendly to this. Since I doubt lyx will implement auto-indent or other emacs abilities (like re-indent region), it would be nice if there was a more convenient way to move back and forth between the lyx listing and an external tool.
Re: listings improvement
I am just trying out listings and it seems pretty good. One problem I see is I just needed to re-indent a bunch of code (happens to be python, so indent matters). I thought maybe I'd just edit the lyx file in emacs, but found out that the form of the listing in the lyx file was not very friendly to this. This is why I tend to use external files as listings child documents. It is easier to modify an external file than doing so within lyx. An advantage of this approach is that you can use 'firstline', 'lastline' options to include part of the file. There is also a more flexible linerange option in the latest listings package. Another advantage is that you can easily run your external script to test for errors, something you can not do to included listings source. Bo
Re: [Patch] allow unicode in layout style name
On Wednesday 11 July 2007 14:55:09 José Matos wrote: In this case it would be enough to study the header section (the part of the file before the real text comes)... OK. I found the real culprit, we don't have the definition of frenchb in lyx2lyx_lang. Adding that and it works again. I have checked also that frenchb was the only problematic language. So all is well now. :-) -- José Abílio
Re: [Patch] Release notes
Abdelrazak Younes [EMAIL PROTECTED] writes: In fact, with a set of local layouts existing in 1.4.4 and needing utf8 conversion, it's possible to copy from lyx-1.4.4/layouts to lyx-1.5.0/layouts and do the conversion at the same time (including format upgrade). A bit complicated (assumes lyx-1.4.4 and lyx-1.5.0 dirs) ? We could probably make this automatically yes. In Windows, that would be the job of the installer. On Linux there's the possibility to launch a post-install script IIRC. Dunno about Macs. But note that this won't take care of layouts that are along the LyX files (distributed layout). Or is this not possible? We can assume that the distributed layouts will be in utf8 and in the required format. Only user layouts have to be filtered. Ans it that prospect it would be nice to have subdirs in the layouts dir as we have for templates and examples (for site user layouts, I mean). I think that automation cannot be complete, unless layout2layout.py knows about it. -- Jean-Pierre
Re: [Patch] Release notes
On Jul 11, 2007, at 11:00 AM, Abdelrazak Younes wrote: In fact, with a set of local layouts existing in 1.4.4 and needing utf8 conversion, it's possible to copy from lyx-1.4.4/layouts to lyx-1.5.0/layouts and do the conversion at the same time (including format upgrade). A bit complicated (assumes lyx-1.4.4 and lyx-1.5.0 dirs) ? We could probably make this automatically yes. In Windows, that would be the job of the installer. On Linux there's the possibility to launch a post-install script IIRC. Dunno about Macs. I haven't been following this thread, but I could easily call another script from the LyX/Mac installer. Just tell me what I should do. Bennett
Re: listings improvement
On Wednesday 11 July 2007, you wrote: I am just trying out listings and it seems pretty good. One problem I see is I just needed to re-indent a bunch of code (happens to be python, so indent matters). I thought maybe I'd just edit the lyx file in emacs, but found out that the form of the listing in the lyx file was not very friendly to this. This is why I tend to use external files as listings child documents. It is easier to modify an external file than doing so within lyx. An advantage of this approach is that you can use 'firstline', 'lastline' options to include part of the file. There is also a more flexible linerange option in the latest listings package. I can't figure out how to use external file with lyx. I only see 1 kind of insert for 'program listing', and nothing in the listing options that looks like a file name.
Re: listings improvement
I can't figure out how to use external file with lyx. I only see 1 kind of insert for 'program listing', and nothing in the listing options that looks like a file name. Insert - File - Child Document - Include Type - Listing. You will have to manually enter options like firstline in the option box. I am not sure what we can do to make this easier to access... any idea? Bo
Re: Exception when opening Document-settings on Solaris
Abdelrazak Younes [EMAIL PROTECTED] writes: This backtrace seems minimal, should I recompile with --enable-debug ? Yes, and possibly --enable-stdlib-debug if that is not already set by default. Same result -- Jean-Pierre
Re: [Patch] Release notes
On Wed, 11 Jul 2007, Abdelrazak Younes wrote: OK? The text refers to LyX 1.4.4 in the beginning, should that be 1.4.5 instead? /C -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: FuncRequest/dispatch goals
On Wed, Jul 11, 2007 at 11:36:52AM +0200, Abdelrazak Younes wrote: Jean-Marc Lasgouttes wrote: Tommaso == Tommaso Cucinotta [EMAIL PROTECTED] writes: Tommaso What about the OO OpenDocument xml format ? Would it be too Tommaso complex for LyX ? The lyx document format is supposed to reflect what LyX is able to handle. I am not sure ODF is usable, since we have no plan to implement openoffice on top of LyX :) This does not mean we should not reuse the same tags as ODF. But as Lars said once, we can modify the tags later. Tommaso Plus, what about maths ? Would they be represented as smth. Tommaso like MathML instead of plain LaTeX that you have now ? I think there are problems related to that (latex (and lyx) LyX is more on the presentational side). The main problem is that mathml is bloody verbose. I think you can now embed TeX math in ODF too. Having math in 'tex' and text in 'lyx' is the only reason why text-in-math does not properly work. If 'lyx' is replaced by 'xml', math should go the same route. Andre'
Re: [Patch] Release notes
On Wednesday 11 July 2007 17:16:47 [EMAIL PROTECTED] wrote: The text refers to LyX 1.4.4 in the beginning, should that be 1.4.5 instead? /C Yes. Feel free to fix issues like this. :-) -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr -- José Abílio
Re: listings improvement
On Wednesday 11 July 2007 17:03:50 Bo Peng wrote: Insert - File - Child Document - Include Type - Listing. You will have to manually enter options like firstline in the option box. I am not sure what we can do to make this easier to access... any idea? Merge graphics, external, include and listings insets into a single interface. Not for 1.5.0 though. ;-) Bo -- José Abílio
Re: [PATCH] Fix bug 3939
Richard Heck wrote: Fix bug 3939. Don't reset all the parameters when the layout is changed, but instead: Check if the alignment is permitted; if not, issue a warning, and reset to LYX_ALIGN_LAYOUT. I tested the patch and it works. The alignment setting is now preserved over layout changes, as long as the alignment set is valid in the new layout. Very good! A couple of small issues: * Changing the layout to something that doesn't support the current alignment bothers me with a message box. (For example, when turning a right-aligned paragraph into title.) The message box hampers workflow as one have to click on ok, and the message isn't important enough to justify that. A message printed on the status bar would be much better, that is what the status bar is there for. The status bar is nice in that you don't have to _do_ anything after reading the message, the status line don't demand useless action. I'm leaving for vacation in a few minutes. Someone else, hopefully, can fix this. Or I can do it when I get back. I had a look. The problem is that we do not have access to cursor or buffer or bufferview from inside applyLayout, which is needed to send the message to the status bar. This could probably be changed by passing one of these as an argument to applyLayout, but I'm really not sure this is worth it. Anyway, Richard's patch could be committed as is, and the message thing can still be changed if it turns out to be as annoying as Helge states. Opinions? Jürgen
Re: FuncRequest/dispatch goals
Bo Peng ha scritto: It would be discussed after 1.5.0 but ODF may be steered too much to WYSIWYG (single character and paragraph styles etc) to be used by Isn't LyX already moving towards supporting custom paragraph styles ? I saw a Paragraph Settings dialog (and actually I'm a little bit concerned about the meaning of its existence: shouldn't customization of a single paragraph be forbidden, in favour of customization of a style ?). Anyway, xml2xml translation will just be a matter of writing a (guess complex) transformation stylesheet. T. -- Tommaso Cucinotta, Computer Engineering PhD, Researcher ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy Tel +39 050 882 024, Fax +39 050 882 003 http://feanor.sssup.it/~tommaso
Re: [PATCH] Fix bug 3939
On Wednesday 11 July 2007 17:26:47 Jürgen Spitzmüller wrote: Anyway, Richard's patch could be committed as is, and the message thing can still be changed if it turns out to be as annoying as Helge states. Opinions? If you think it is OK go ahead. :-) Jürgen -- José Abílio
Re: [PATCH] Fix bug 3939
José Matos wrote: If you think it is OK go ahead. :-) I did so. Jürgen
Re: Arrival/departure dates for Bromarv?
On Wed, Jul 11, 2007 at 09:49:32AM +0300, Martin Vermeer wrote: On Tue, Jul 10, 2007 at 11:25:14PM +0200, [EMAIL PROTECTED] wrote: On Tue, 10 Jul 2007, Andre Poenitz wrote: ... I've now booked my flight, I arrive in Helsinki 14:00, you at 14:45 and Jean-Marc at 14:50. So I'll just have a late lunch while waiting. All on thursday 9th? Then perhaps we should just pick you up by car. I'll talk to the CEO about it ;-) Would be nice. Both should be enough to reach the regular bus to/from Bromarv. Ok. Is there anybody else coming btw? I don't think so... Martin? Lars was planning to come by bike. And then Jose and Susana... Jose? Anything special to bring? We have bedlinen and towels and all... but do bring as many laptops as you can, with ethernet cables / wireless cards, and a spare hub or ADSL modem if you have one. In theory I have a ADSL modem, but not exactly a 'spare' one. Also, people on the airport are known to have funny ideas if they see 'unusual electronic equipment'. A 'laptop' is usually on the upper rim... Anyway, if there's no Finish modem to find I can bring mine. It has WLAN and four LAN port, I would need one of the LAN ports for my own laptop. Last Saturday we had the thunderstorm of the century - phone dead, internet dead. Two working days, said Sonera. We'll see. I have some contingency plans for that... A yes, bring swimming clothes. Nice sand beach close by. Igitt. I suppose the water will be wet, too. I was trying to avoid this this year... Should I bring a laptop? I can take my old Dell (300MHz,256MB) which probably isn't too useful, or my work laptop (mass=7 kg including PSU). One with a working LyX SVN local tree, and a compiler that doesn't run out of steam ;-) Andre'
Re: Open Patches
José Matos schrieb: On Wednesday 04 July 2007 20:44:31 Michael Gerz wrote: Hi, it seems that there are still several patches that may go into 1.5.0. Since José has left us for the rest of the week, I wonder what will happen to these patches: - RTL Justification Bug (bug3889.2.patch, 26/06/07) by Dov - Bug fix #3600 (30/06/07) by Alfredo - Image Cache Fix (3819.diff, 30/06/07) by Jürgen Georg - Unicode Bug fixes (#3313 #3498, 01/07/07) by Jürgen - Toolbar patch (01/07/07) by myself - default-encoding.2.patch (01/07/07) by Dov - Current Language (#3959, 01/07/07) by Dov - Author field fix (03/07/07) by JMarc myself - Windows font patch (03/07/07) by Peter - Include file crash fix (#3970, 05/07/07) by Abdel I think some of these patches just require a second OK by a competent developer. AFAIR most have been applied already. What are the patches from this batch that did not had any comment so far? IIRC only Alfredo's patch #3600 and the Windows font patch are not committed. Michael
Re: Open Patches
Michael Gerz schrieb: José Matos schrieb: On Wednesday 04 July 2007 20:44:31 Michael Gerz wrote: AFAIR most have been applied already. What are the patches from this batch that did not had any comment so far? José, all, there are three more patches which may be subject to discussion: [patch] fix bug 3974: crash with user defined external templates (by Bernhard) [patch] bug 1820 --- footnotes in different language (by Dov) [PATCH] bugs 3958, 3313 and 3976 lyx2lyx and unicode characters Michael
Assertion when leaving LyX
Solaris again, here is what I get when I leave LyX. Not much boring, but... Assertion failed: __pos size(), file /usr/local/lib/gcc/sparc-sun-solaris2.8/3.4.6\ /../../../../include/c++/3.4.6/bits/basic_string.h, line 643 Program received signal SIGABRT, Aborted. 0xfdf592f0 in __sigprocmask () from /usr/lib/libthread.so.1 (gdb) bt #0 0xfdf592f0 in __sigprocmask () from /usr/lib/libthread.so.1 #1 0xfdf4e59c in _resetsig () from /usr/lib/libthread.so.1 #2 0xfdf4dd3c in _sigon () from /usr/lib/libthread.so.1 #3 0xfdf50d98 in _thrp_kill () from /usr/lib/libthread.so.1 Should I suspect my local gcc ? -- Jean-Pierre
Re: Lyx 1.5.0rc2: \overset math command
Andre Poenitz wrote:
If I write \overset{def}{=} I get the preview shown in the attached
picture, that is 'def' does not appear above '=', but they both overlap.
Right.
Patch attached.
Ok to commit?
Looks much better here as well, so OK from me.
Jürgen
Re: listings improvement
On Wednesday 11 July 2007, Bo Peng wrote: I can't figure out how to use external file with lyx. I only see 1 kind of insert for 'program listing', and nothing in the listing options that looks like a file name. Insert - File - Child Document - Include Type - Listing. You will have to manually enter options like firstline in the option box. I am not sure what we can do to make this easier to access... any idea? Bo Make external file an option under listings insert would be more intuitive.
Re: Open Patches
Michael Gerz wrote: IIRC only Alfredo's patch #3600 and the Windows font patch are not committed. the font patch is in. Jürgen
[PATCH] Important Change Tracking Patch
Hi,
once again, I would like to draw your attention to the attached patch.
It fixes a serious problem with change-tracked output (text inside
deleted insets appears as unchanged text).
Could someone please have a look at the code and do some testing?
As I will not be able to do any LyX work before tomorrow evening (i.e.,
before the release of LyX 1.5.0), could someone please commit the patch
if the feedback is positive?
A thousand thanks in advance!
Michael
PS: LyX 1.5.0 will be great!
Index: src/OutputParams.h
===
--- src/OutputParams.h (Revision 19046)
+++ src/OutputParams.h (Arbeitskopie)
@@ -16,6 +16,7 @@
#include support/types.h
#include boost/shared_ptr.hpp
+#include Changes.h
namespace lyx {
@@ -120,6 +121,16 @@
*/
bool inComment;
+ /** Whether we are inside an inset that is logically deleted.
+ * A value 0 indicates a deleted inset.
+ */
+ int inDeletedInset;
+
+ /** The change information of the outermost, logically deleted inset.
+ * changeOfDeletedInset shall only be evaluated if inDeletedInset 0.
+ */
+ Change changeOfDeletedInset;
+
/** allow output of only part of the top-level paragraphs
* par_begin: beginning paragraph
*/
Index: src/Paragraph.cpp
===
--- src/Paragraph.cpp (Revision 19046)
+++ src/Paragraph.cpp (Arbeitskopie)
@@ -190,7 +190,7 @@
///
void simpleTeXSpecialChars(Buffer const , BufferParams const ,
odocstream ,
- TexRow texrow, OutputParams const ,
+ TexRow texrow, OutputParams ,
Font running_font,
Font basefont,
Font const outerfont,
@@ -661,7 +661,7 @@
BufferParams const bparams,
odocstream os,
TexRow texrow,
- OutputParams const runparams,
+ OutputParams runparams,
Font running_font,
Font basefont,
Font const outerfont,
@@ -725,6 +725,11 @@
break;
}
+ if (lookupChange(i).type == Change::DELETED) {
+ if( ++runparams.inDeletedInset == 1)
+runparams.changeOfDeletedInset = lookupChange(i);
+ }
+
if (inset-canTrackChanges()) {
column += Changes::latexMarkChange(os, bparams, running_change,
Change(Change::UNCHANGED));
@@ -779,6 +784,10 @@
} else {
column += os.tellp() - len;
}
+
+ if (lookupChange(i).type == Change::DELETED) {
+ --runparams.inDeletedInset;
+ }
}
break;
@@ -1923,7 +1932,7 @@
BufferParams const bparams,
Font const outerfont,
odocstream os, TexRow texrow,
-OutputParams const runparams) const
+OutputParams runparams) const
{
LYXERR(Debug::LATEX) SimpleTeXOnePar... this endl;
@@ -2017,7 +2026,8 @@
runparams.moving_arg);
}
- Change const change = pimpl_-lookupChange(i);
+ Change const change = runparams.inDeletedInset ? runparams.changeOfDeletedInset
+ : pimpl_-lookupChange(i);
if (bparams.outputChanges runningChange != change) {
if (open_font) {
Index: src/OutputParams.cpp
===
--- src/OutputParams.cpp (Revision 19046)
+++ src/OutputParams.cpp (Arbeitskopie)
@@ -22,7 +22,7 @@
local_font(0), encoding(enc), free_spacing(false), use_babel(false),
linelen(0), depth(0),
exportdata(new ExportData),
- inComment(false),
+ inComment(false), inDeletedInset(0), changeOfDeletedInset(Change::UNCHANGED),
par_begin(0), par_end(0),
dryrun(false)
{}
Index: src/Paragraph.h
===
--- src/Paragraph.h (Revision 19046)
+++ src/Paragraph.h (Arbeitskopie)
@@ -126,7 +126,7 @@
///
bool simpleTeXOnePar(Buffer const , BufferParams const ,
Font const outerfont, odocstream ,
- TexRow texrow, OutputParams const ) const;
+ TexRow texrow, OutputParams ) const;
/// Can we drop the standard paragraph wrapper?
bool emptyTag() const;
Re: Open Patches
Michael Gerz wrote: there are three more patches which may be subject to discussion: [patch] fix bug 3974: crash with user defined external templates (by Bernhard) an alternative fix is in (rev 19013). [patch] bug 1820 --- footnotes in different language (by Dov) [PATCH] bugs 3958, 3313 and 3976 lyx2lyx and unicode characters the lyx2lyx bugs are the most severe issues that are left IMO. But José already announced to look into them. Jürgen
Re: [patch] bug 1820 --- footnotes in different language
Jean-Marc Lasgouttes wrote:
Dov == Dov Feldstern dfeldstern-rhxOsnTko2JWk0Htik3J/[EMAIL PROTECTED]
writes:
Dov Do you know why this whole font-change mechanism was originally
Dov added?
Consider a footnote with several paragraphs and assume it is typeset
in \emph like this:
\emph{Some text\footnote{and and explanation
on several paragraphs}}
This will cause a LaTeX error because the \emph macro will not be
terminated at the end of the first paragraph. This is the reason why
noFontChange was introduced.
Hmm, yes I see. However, I think that for languages the behavior is
different, and it won't close at the end of the paragraph. That's what
was confusing me --- I saw the comments explaining what would happen
without the noFontChange, but didn't see the problem actually happen,
because I'm testing it with the languages...
So, I'll try to fix this by ignoring noFontChange for languages, but
leaving it in for everything else.
However, Georg is right: this *does* constitute a format change, and I
don't see that I'll be able to fix this, and provide a lyx2lyx fix,
within the next day or two; and I certainly don't feel that I know this
well enough to commit it just before a final release... But, it would
also be a real shame to wait with this fix until 1.6
Also, I looked at bug 3613 again, and now that I have a better
understanding of what's going on, I see that the problem there is
similar, but not exactly the same. The thing is that some fix was made
at some point, but without an accompanying lyx2lyx. So Fixing that will
also require a lyx2lyx fix.
What to do...? Is it worth even trying to work on these before 1.5.0, or
should I just forget it... :( ? Note that in the case of 3613, the
damage is already done, and currently files such as the example there
(actually, available at
http://www.lyx.org/trac/browser/lyx-devel/trunk/lib/doc/he/Intro.lyx?rev=17343)
are broken in 1.5.0
Dov
Re: listings improvement
Make external file an option under listings insert would be more intuitive. Do you mean menu items insert - program listing program file listing or something in the listings - right click dialog? The latter is difficult because file listings is not an option of a normal listing (which contains code, caption etc) and you can not somehow convert a listings inset to file listing. Bo
Re: Open Patches
Jürgen Spitzmüller wrote: Michael Gerz wrote: there are three more patches which may be subject to discussion: [patch] bug 1820 --- footnotes in different language (by Dov) As I just posted in a separate message, it turns out that (I'm pretty sure) this will require a format change in order to fix correctly; and also, now that I understand what's going on, I see that bug 3613, which is a similar issue, is actually due to a format change which happened way back when, but did not have an accompanying lyx2lyx... If possible, both these should be fixed before 1.5.0, but I don't think I can do it within a day or two :( ... Dov
UTF-8 and layouts - bugs
Hi,
yesterday I test Abdel's patch layout_name_is_unicode.patch with the
latest svn. I send a message
to lyx-devel, but as I don't see it on mail-archive.com
http://www.mail-archive.com/lyx-devel@lists.lyx.org/ I send an other
one and add some bugs I found.
Abdel's patch works perfectly with all my layouts and all my old lyx
files (with the exceptions below):
the only thing I did was to convert my layouts in UTF-8.
Thus, for me, this patch is a perfect solution for the upgrade from 1.4
to 1.5!
During my tests I found the three bugs below, I did not found in bugzilla:
* About layouts: the tag DependsOn does not works when it calls a
Style whose name contains
special characters. I cannot test everything, but I suspect that it
does not works when the name of
called Style contains an underscore ( _ )
*About lyx2lyx: it fails to convert an old lyx file containing the
command \language frenchb
* In a new document write: a word
Then change the size of the two words to small; then change the color
of a (to red for example).
Then lyx traduce it as : \textcolor{red}{\small a}{\small word} and
the space between a and
word disappear.
PhC
Re: UTF-8 and layouts - bugs
Philippe Charpentier wrote:
*About lyx2lyx: it fails to convert an old lyx file containing the
command \language frenchb
just fixed by José I think (rev. 19044).
* In a new document write: a word
Then change the size of the two words to small; then change the color
of a (to red for example).
Then lyx traduce it as : \textcolor{red}{\small a}{\small word} and
the space between a and
word disappear.
this is
http://bugzilla.lyx.org/show_bug.cgi?id=3382
Jürgen
