Re: 1.5.X Patch Candidate List #1
Richard Heck wrote: Abdelrazak Younes wrote: Richard Heck wrote: Michael Gerz wrote: Approved by Jürgen -- http://www.lyx.org/trac/changeset/19867 - InsetCollapsable::setStatus(): remove the Buffer::changed() signal emission I'll put this one in shortly. Very simple. OK, I'll let you the honor ;-) Just saving you some work. And it's about all the time I can spare now. Thanks for the help Richard, it is very welcome (not sure this is what you understood from my mail). Abdel.
Re: ERT in title bug
Martin Vermeer wrote: On Tue, Sep 11, 2007 at 11:06:55PM +0200, Abdelrazak Younes wrote: Martin Vermeer wrote: I don't get this effect at all. Tried with article (AMS) and title layout. The title is in small caps, and no matter what I do, the ERT inset content is in lower case, standard size, typewriter LaTeX red text, just as it is supposed to be. What should I do to see the bug? Use 1.5 ;-) But then Dov's speculations are irrelevant. Indeed. Abdel.
Re: Lyx/branch crashes during exit.
> I will compile with gcc 4 and try again. Gcc4 + Qt 422 crashes. Gcc4 + Qt 4.0 (or 4.11? not sure) does not. Have not tested Gcc 3 + Qt 4.0, but it is likely a Qt 422 problem. Bo
Re: Lyx/branch crashes during exit.
> I should have said, using Qt 4.2.1, so this code is being compiled. Then this might be another gcc 3 / signals problem. :-) I will compile with gcc 4 and try again. Bo
Re: Lyx/branch crashes during exit.
On Tue, 2007-09-11 at 22:50 -0500, Bo Peng wrote: > #2 points to > GuiFontLoader::~GuiFontLoader() > { > #if QT_VERSION >= 0x040200 > for (int i = 0 ; i < num_math_fonts; ++i) { > if (fontID[i] >= 0) > QFontDatabase::removeApplicationFont(fontID[i]); > } > > delete [] fontID; > #endif > } I should have said, using Qt 4.2.1, so this code is being compiled. Have fun, Darren
Re: Lyx/branch crashes during exit.
On Tue, 2007-09-11 at 22:50 -0500, Bo Peng wrote: > On linux, simply start and quit lyx. r20206 didn't do this. I just built r20235 and tried. Sorry but following your procedure I don't get a crash. OpenSUSE 10.2. Have fun, Darren
Lyx/branch crashes during exit.
On linux, simply start and quit lyx. Backtrace: #0 0x003412512838 in FcConfigSetFonts () from /usr/lib64/libfontconfig.so.1 #1 0x002a95c67267 in QFontDatabase::removeApplicationFont (handle=0) at text/qfontdatabase_x11.cpp:1959 #2 0x0086a7a6 in ~GuiFontLoader (this=0xf13cb8) at src/frontends/qt4/GuiFontLoader.cpp:235 #3 0x00863ed9 in ~GuiApplication (this=0xf13bb0) at /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../include/c++/3.4.6/bits/stl_tree.h:558 #4 0x00445aa1 in boost::scoped_ptr::reset (this=0xf0e2b8, p=0x0) at boost/boost/checked_delete.hpp:34 #5 0x0042d15a in lyx::LyX::prepareExit (this=0x7fb380) at boost/boost/scoped_ptr.hpp:93 #2 points to GuiFontLoader::~GuiFontLoader() { #if QT_VERSION >= 0x040200 for (int i = 0 ; i < num_math_fonts; ++i) { if (fontID[i] >= 0) QFontDatabase::removeApplicationFont(fontID[i]); } delete [] fontID; #endif }
Re: [Patch] Bug 3527 - Basic PDF support via hyperref
On 9/11/07, Pavel Sanda <[EMAIL PROTECTED]> wrote: > > 1. "PDF support" may not be the best name. I am thinking of "Document > > Properties", but "Hyperref Support" may be clearer. > > users with a little knowledge of latex will not understand Hyperref Support. > Document Properties is too general. we can change the naming, but still > i think that the keyword "pdf" should be incorporated somehow. PDF Properties? > > 3. pagebackref, pageref, bookmark etc should be more verbal. > > suggestions ? (there are already more verbal tooltips) Something like "Add backlink to bibliographic items", "Generate bookmark links" etc. Cheers, Bo
Re: ERT in title bug
On Tue, Sep 11, 2007 at 11:06:55PM +0200, Abdelrazak Younes wrote: > Martin Vermeer wrote: > > > >I don't get this effect at all. Tried with article (AMS) and title > >layout. The title is in small caps, and no matter what I do, the ERT > >inset content is in lower case, standard size, typewriter LaTeX red > >text, just as it is supposed to be. > > > >What should I do to see the bug? > > Use 1.5 ;-) But then Dov's speculations are irrelevant. - Martin
Re: [Patch] Bug 3527 - Basic PDF support via hyperref
> 1. "PDF support" may not be the best name. I am thinking of "Document > Properties", but "Hyperref Support" may be clearer. users with a little knowledge of latex will not understand Hyperref Support. Document Properties is too general. we can change the naming, but still i think that the keyword "pdf" should be incorporated somehow. > 2. This page should be put before preamble, which means the *last* and > ultimate method of customization. I am thinking of "Document > Properties" after "Document class" or "Hyperref Support" after > Bibliography. yep. > 3. pagebackref, pageref, bookmark etc should be more verbal. suggestions ? (there are already more verbal tooltips) pavel
Re: [Patch] Bug 3527 - Basic PDF support via hyperref
> http://wiki.lyx.org/uploads/DevelDoc/pdfsupport.gif > that is the current state on my local branch. still receiving additional > requests :) Nice dialog. I think 1. "PDF support" may not be the best name. I am thinking of "Document Properties", but "Hyperref Support" may be clearer. 2. This page should be put before preamble, which means the *last* and ultimate method of customization. I am thinking of "Document Properties" after "Document class" or "Hyperref Support" after Bibliography. 3. pagebackref, pageref, bookmark etc should be more verbal. Cheers, Bo
Re: [Patch] Bug 3527 - Basic PDF support via hyperref
> Probably there should just be a "use hyperref" checkbox to turn this on > and off. You could then check that and get basic hyperref support > without actually having to fill out any of the fields. That is: You'd > just get \usepackage{hyperref}. As for other checkboxes, we should have > ones for backref and pagebackref, etc. http://wiki.lyx.org/uploads/DevelDoc/pdfsupport.gif that is the current state on my local branch. still receiving additional requests :) pavel
question about language preference option auto_begin/end
Can anybody explain me what does the option "auto end" do that is in the preferences dialog under Language settings? The only code reference I found is this: if (!lyxrc.language_auto_end && !params().language->babel().empty()) { os << from_utf8(subst(lyxrc.language_command_end, "$$lang", params().language->babel())) << '\n'; texrow().newline(); } But what is the difference to the case when auto_end is activated? thanks and regards Uwe
Re: Importing {\tiny ... }
Helge Hafting ha scritto: Select the tiny text Edit->Text STyle->Customized... You get a dialog - change to whatever size you need. Oops, you're right ! I opened that dialog so many times, without seeing what was just there !! On a related note, I have a similar issue with a \textsl{} within every cell of a table. This time, whatever I choose from the Text Style dialog, it is added within the \textsl{} command, that remains there. Any clue ? Thanx, bye, T.
Re: Build of lyx-1.5.1 on FreeBSD 6.2. fails in src/support/tests/test_filetools
On Tuesday 11 September 2007 22:48:50 Ullrich Franke wrote: > My system is: > FreeBSD fbsd.Amnesiac.unsernet 6.2-STABLE FreeBSD 6.2-STABLE #0: Wed Jun 27 > 12:25:02 CEST 2007 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CKERN6 i386 Thank you for the report. This test fails on linux too (Fedora 7 here) with the same error, FWIW. In this case it is a matter of understanding if the test makes sense at all. We should rework this in 1.6 where I would like to see more (meaningful) tests. Regards, -- José Abílio
Build of lyx-1.5.1 on FreeBSD 6.2. fails in src/support/tests/test_filetools
Hi, I'm currently in the process of porting lyx-1.5.1 to FreeBSD. The build-process however fails on src/support/tests/test_filetools. In #lyx (on irc.debian.org) ps told me to contact the mailinglist about this problem. I've attached the relevant build logs. My system is: FreeBSD fbsd.Amnesiac.unsernet 6.2-STABLE FreeBSD 6.2-STABLE #0: Wed Jun 27 12:25:02 CEST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CKERN6 i386 Qt4 is installed as followes: qt4-corelib-4.3.1 Qt core library qt4-gui-4.3.1 Qt graphical user interface library qt4-moc-4.3.1 Qt meta object compiler qt4-qmake-4.3.1 The build utility of the Qt project qt4-rcc-4.3.1 Qt resource compiler qt4-uic-4.3.1 Qt user interface compiler ===> Building for lyx-1.5.1 Making all in config gmake[1]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/config' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/config' Making all in development gmake[1]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/development' gmake[2]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/development' gmake[2]: Nothing to be done for `all-am'. gmake[2]: Leaving directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/development' gmake[1]: Leaving directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/development' Making all in intl gmake[1]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/intl' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/intl' Making all in po gmake[1]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/po' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/po' Making all in src gmake[1]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src' gmake all-recursive gmake[2]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src' Making all in mathed gmake[3]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/mathed' gmake all-am gmake[4]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/mathed' gmake[4]: Nothing to be done for `all-am'. gmake[4]: Leaving directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/mathed' gmake[3]: Leaving directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/mathed' Making all in insets gmake[3]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/insets' gmake all-am gmake[4]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/insets' gmake[4]: Nothing to be done for `all-am'. gmake[4]: Leaving directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/insets' gmake[3]: Leaving directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/insets' Making all in graphics gmake[3]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/graphics' gmake all-am gmake[4]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/graphics' gmake[4]: Nothing to be done for `all-am'. gmake[4]: Leaving directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/graphics' gmake[3]: Leaving directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/graphics' Making all in support gmake[3]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/support' gmake all-recursive gmake[4]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/support' Making all in . gmake[5]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/support' gmake[5]: Leaving directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/support' Making all in tests gmake[5]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/support/tests' gmake all-am gmake[6]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/support/tests' gmake[6]: Nothing to be done for `all-am'. gmake[6]: Leaving directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/support/tests' gmake[5]: Leaving directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/support/tests' gmake[4]: Leaving directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/support' gmake[3]: Leaving directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/support' Making all in frontends gmake[3]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/frontends' gmake all-recursive gmake[4]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/frontends' Making all in controllers gmake[5]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/frontends/controllers' gmake all-recursive gmake[6]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/frontends/controllers' Making all in tests gmake[7]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/frontends/controllers/tests' gmake all-am gmake[8]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/frontends/controllers/tests' gmake[8]: Nothing to be done for `all-am'. gmake[8]: Leaving directory `/usr/p
includes
Could people please try to keep an eye on unneeded includes? I just had two almost-full-recompiles just because BufferParams.h happened to include frontend_helper.h for no good reason... Thank you. Andre'
Re: [Patch] Bug 3527 - Basic PDF support via hyperref
Uwe Stöhr wrote: > And if you're working on thisthe URL inset should become an \href inset. (There are a billion > bugs about this.) I also opted for this often in the past, but you need to take care then of several issues. Take for example the Algorithm floats: The EmbeddedObjects manual describes a lot of Preamle hooks that are needed when hyperref is used. There are a lot other cases where this is problematic, just search in the EmbeddedObjects manual for "hyperref". It might be that, if we load hyperref at the right point---and obviously, we have to figure out when that is---these sorts of issues will go away. The problem, at present, is that you can only load it manually now, so it gets loaded late. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: 1.5.X Patch Candidate List #1
Abdelrazak Younes wrote: Richard Heck wrote: Michael Gerz wrote: Approved by Jürgen -- http://www.lyx.org/trac/changeset/19867 - InsetCollapsable::setStatus(): remove the Buffer::changed() signal emission I'll put this one in shortly. Very simple. OK, I'll let you the honor ;-) Just saving you some work. And it's about all the time I can spare now. rh -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [Patch] Bug 3527 - Basic PDF support via hyperref
> And if you're working on thisthe URL inset should become an \href inset. (There are a billion > bugs about this.) I also opted for this often in the past, but you need to take care then of several issues. Take for example the Algorithm floats: The EmbeddedObjects manual describes a lot of Preamle hooks that are needed when hyperref is used. There are a lot other cases where this is problematic, just search in the EmbeddedObjects manual for "hyperref". regards Uwe
Re: ERT in title bug
Martin Vermeer wrote: I don't get this effect at all. Tried with article (AMS) and title layout. The title is in small caps, and no matter what I do, the ERT inset content is in lower case, standard size, typewriter LaTeX red text, just as it is supposed to be. What should I do to see the bug? Use 1.5 ;-) Abdel.
Re: [Patch] Bug 3527 - Basic PDF support via hyperref
Pavel Sanda wrote: Probably there should just be a "use hyperref" checkbox to turn this on and off. You could then check that and get basic hyperref support without actually having to fill out any of the fields. That is: You'd just get \usepackage{hyperref}. have never used this plain version. does it anything useful ? Yes: It activates links to the bibliography and such. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: ERT in title bug
Neal Becker wrote: In my title I tried to insert: Revision ERT{\input{build_id}} On the screen, it says: \INPUT{BUILD_ID} because I'm using ams art, and title is caps. I chose 'view source', it says: \title{SCMA Design Document\\ Revision \input{build_id}} \maketitle OK, fine. Just a screen buglet. Wait, no! Which version is that? Abdel.
Re: [Patch] Bug 3527 - Basic PDF support via hyperref
> Probably there should just be a "use hyperref" checkbox to turn this on and > off. You could then check that and get basic hyperref support without > actually having to fill out any of the fields. That is: You'd just get > \usepackage{hyperref}. have never used this plain version. does it anything useful ? >As for other checkboxes, we should have ones for backref and pagebackref, etc. ok, i go read the manual :) pavel
Re: ERT in title bug
On Tue, Sep 11, 2007 at 10:11:42PM +0300, Dov Feldstern wrote: > Jürgen Spitzmüller wrote: > >Neal Becker wrote: > >>In my title I tried to insert: > >> > >>Revision ERT{\input{build_id}} > >> > >>On the screen, it says: \INPUT{BUILD_ID} > >> > >>because I'm using ams art, and title is caps. > >> > >>I chose 'view source', it says: > >>\title{SCMA Design Document\\ > >>Revision \input{build_id}} > >> > >>\maketitle > >> > >>OK, fine. Just a screen buglet. Wait, no! > >> > >>lyx --export pdf > >>! LaTeX Error: File `BUILD_ID.tex' not found. > > > >With ERT, you're on your own. > >Try ERT{\MakeLowercase{\input{build_id}}} > > > >Jürgen > > > > Actually, I'm pretty sure this is a regression, which is due to the > current_font text->cursor move. What happens is, ERT font used to be set > explicitly, but now since there's no place to set it, it just takes the > font from the surrounding text. So in an AMS title you'll apparently get > all-caps, in an emph environment the text will all be emph, in a > non-latin language you can't type latin text at all, which means ERT is > useless in this context. > > See the thread http://permalink.gmane.org/gmane.editors.lyx.devel/93458. > Something really should be done about this, but I'm not sure what the > correct way to deal with this is... I suggested one approach in that > message, but it's just an idea, I don't know if it would work in practice... > > Dov I don't get this effect at all. Tried with article (AMS) and title layout. The title is in small caps, and no matter what I do, the ERT inset content is in lower case, standard size, typewriter LaTeX red text, just as it is supposed to be. What should I do to see the bug? - Martin
Re: 1.5.X Patch Candidate List #1
> http://www.lyx.org/trac/changeset/20195 - unicodesymbols: workaround fix for an encoding bug in > teTeX 3 /TeXLive 2005 This is in now. regards Uwe
Re: 1.5.X Patch Candidate List #1
Richard Heck wrote: Michael Gerz wrote: Approved by Jürgen -- http://www.lyx.org/trac/changeset/19867 - InsetCollapsable::setStatus(): remove the Buffer::changed() signal emission I'll put this one in shortly. Very simple. OK, I'll let you the honor ;-) Abdel.
Re: 1.5.X Patch Candidate List #1
Michael Gerz wrote: Hi, thanks for clearing the list. This is what is left: Approved by Jürgen -- Update to Boost 1.34.1 http://www.lyx.org/trac/changeset/19638 - redoParagraph() simplify the changed calculation On second thought I don't think I will backport this one because I am pretty sure it will have side effects. As there is text drawing problem in 1.5 I prefer to not touch it. http://www.lyx.org/trac/changeset/19868 - TextMetrics::redoParagraph(): we need to check the returned value of Inset::metrics() http://www.lyx.org/trac/changeset/19838 - Bug fix: correctly redraw a Row containing and inset which Dimension slightly changed http://www.lyx.org/trac/changeset/20016 - optimization: avoid some font copying http://www.lyx.org/trac/changeset/20021 - enable some non-rtl optimization Those four are in now. http://www.lyx.org/trac/changeset/19867 - InsetCollapsable::setStatus(): remove the Buffer::changed() signal emission Richard will take care of that one. New --- http://www.lyx.org/trac/changeset/19919 - Fix DEPM crash within inset. always clear the full text_metrics_ when doing a full update. This one is in. Abdel.
Re: [Patch] Bug 3527 - Basic PDF support via hyperref
> > 2) can somebody review this code and comment what should be done > >otherwise and mainly what i forgot to do. > > I have a quick look at the patch, and have one question though: why do > you use separate file for PDFOptions.h|cpp? I guess it can be merged basically because i mimic some other class ;) when the code will not increase, i'll merge it. pavel
Re: 1.5.X Patch Candidate List #1
Richard Heck wrote: Michael Gerz wrote: Approved by Jürgen -- http://www.lyx.org/trac/changeset/19867 - InsetCollapsable::setStatus(): remove the Buffer::changed() signal emission I'll put this one in shortly. Very simple. This is in now. I didn't add anything to status.15x because it's more of a technical fix and didn't go with a bug number. rh -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: 1.5.X patch candidates - next iteration
Jürgen Spitzmüller wrote: Just to keep track, here are the fixes you still need to backport (and have OK to do so). No need to hurry, though: http://www.lyx.org/trac/changeset/19868 - TextMetrics::redoParagraph(): we need to check the returned value of Inset::metrics() http://www.lyx.org/trac/changeset/19838 - Bug fix: correctly redraw a Row containing and inset which Dimension slightly changed I committed those two (in one commit because they are related). Abdel.
Re: 1.5.X patch candidates - next iteration
Abdelrazak Younes wrote: Jürgen Spitzmüller wrote: Abdelrazak Younes wrote: http://www.lyx.org/trac/changeset/19919 - Fix DEPM crash within inset. always clear the full text_metrics_ when doing a full update. Applicable to branch? In theory yes but this will have side effects within insets. What kind of side effects? I am not sure... maybe crashes, maybe cleared out text... In trunk, the only side effect (besides fixing the DEPM crash) was that I had to force full repaint in tabular cells. But a full repaint occurred anyway so no harm done. I'll tell you what, I'll produce a patch and let you test it and decide if it is safe or not. Well, I verified that there is no apparent side effect and I cannot see how it could have anyway so I just committed it. The patch is short so it can be reverted easily in case of problems but I really don't expect any. I didn't put an entry in status.15x because I don't know what to put... Abdel. Author: younes Date: Tue Sep 11 22:09:36 2007 New Revision: 20220 URL: http://www.lyx.org/trac/changeset/20220 Log: BufferView: Be on the safe side: clear out all of text_metrics_ when doing a full update. Modified: lyx-devel/branches/BRANCH_1_5_X/src/BufferView.cpp Modified: lyx-devel/branches/BRANCH_1_5_X/src/BufferView.cpp URL: http://www.lyx.org/trac/file/lyx-devel/branches/BRANCH_1_5_X/src/BufferView.cpp?rev=20220 == --- lyx-devel/branches/BRANCH_1_5_X/src/BufferView.cpp (original) +++ lyx-devel/branches/BRANCH_1_5_X/src/BufferView.cpp Tue Sep 11 22:09:36 2007 @@ -1097,9 +1097,6 @@ width_ = width; height_ = height; - // The complete text metrics will be redone. - text_metrics_.clear(); - if (buffer_) resize(); } @@ -1464,7 +1461,6 @@ void BufferView::updateMetrics(bool singlepar) { Text & buftext = buffer_->text(); - TextMetrics & tm = textMetrics(&buftext); pit_type size = int(buftext.paragraphs().size()); if (anchor_ref_ > int(buftext.paragraphs().size() - 1)) { @@ -1478,8 +1474,11 @@ // Clear out paragraph metrics to avoid having invalid metrics // in the cache from paragraphs not relayouted below - tm.clear(); - } + // The complete text metrics will be redone. + text_metrics_.clear(); + } + + TextMetrics & tm = textMetrics(&buftext); // If the paragraph metrics has changed, we can not // use the singlepar optimisation.
Re: [Patch] Bug 3527 - Basic PDF support via hyperref
Bo Peng wrote: 2) can somebody review this code and comment what should be done otherwise and mainly what i forgot to do. I have a quick look at the patch, and have one question though: why do you use separate file for PDFOptions.h|cpp? I guess it can be merged to BufferParams. Yes, I think that would be preferable, unless this got a lot larger. Pavel: Note that the point is that the definitions and code can all go into BufferParams.{h,cpp}. It's fine to have this class. Probably there should just be a "use hyperref" checkbox to turn this on and off. You could then check that and get basic hyperref support without actually having to fill out any of the fields. That is: You'd just get \usepackage{hyperref}. As for other checkboxes, we should have ones for backref and pagebackref, etc. As Bo said, well done. And if you're working on thisthe URL inset should become an \href inset. (There are a billion bugs about this.) This would be very easy to do, and it's probably what people really want from hyperref. The only significant work will be the lyx2lyx. The \url command can be handled via CharStyles (and there's in fact already a module in lib/layouts that does this). Any (old) URL inset that didn't declare the name field---if it does, maybe it should be left an href---would get converted to a URL charstyle (or flex inset, as they're now called), with \usepackage{url} added to the preamble. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [Patch] Bug 3527 - Basic PDF support via hyperref
> i have basic working skeleton for bug 3527; now there is only minimal set of > supported features, but i'll add others, when you won't opose the general > construction of this code. i would like to ask : Nice work! > 1) is it possible to add hyperref support to 1.6 series (Jose?) As long as you can complete the feature before 1.6 is released, so I guess the answer is yes. > 2) can somebody review this code and comment what should be done >otherwise and mainly what i forgot to do. I have a quick look at the patch, and have one question though: why do you use separate file for PDFOptions.h|cpp? I guess it can be merged to BufferParams. > 3) what features you would like to have from hyperref ? Have not tried your patch... > 3) is there something needed for lyx2lyx support ? Remove these options with back conversion. > 4) adding others things like keywords, checkboxes for working bookmarks and > references. I guess I also want 'fullscreen' mode for presentation. Cheers, Bo
[Patch] Bug 3527 - Basic PDF support via hyperref
hi, i have basic working skeleton for bug 3527; now there is only minimal set of supported features, but i'll add others, when you won't opose the general construction of this code. i would like to ask : 1) is it possible to add hyperref support to 1.6 series (Jose?) 2) can somebody review this code and comment what should be done otherwise and mainly what i forgot to do. 3) what features you would like to have from hyperref ? from my point of view these things need to be resolved: 1) afaiu strings entered into gui are in utf8; now they are pasted to output .tex via from_utf8, but i'm not sure how it works with current encodings. whats the best solution for this ? 2) i know from my previous experience with hyperref, that there are options, which are just fine for pdflatex, but when i try to render it through ps2pdf, the whole compilation fails. howto treat these cases ? is it possible to generate different code for a different targets ? 3) is there something needed for lyx2lyx support ? 4) adding others things like keywords, checkboxes for working bookmarks and references. any comments welcomed pavel diff --git a/src/Buffer.cpp b/src/Buffer.cpp index 9115877..60abd48 100644 --- a/src/Buffer.cpp +++ b/src/Buffer.cpp @@ -55,6 +55,7 @@ #include "Undo.h" #include "version.h" #include "EmbeddedFiles.h" +#include "PDFOptions.h" #include "insets/InsetBibitem.h" #include "insets/InsetBibtex.h" @@ -459,6 +460,7 @@ int Buffer::readHeader(Lexer & lex) params().footskip.erase(); params().listings_params.clear(); params().clearLayoutModules(); + params().pdfoptions().clear(); for (int i = 0; i < 4; ++i) { params().user_defined_bullet(i) = ITEMIZE_DEFAULTS[i]; diff --git a/src/BufferParams.cpp b/src/BufferParams.cpp index e566cdd..cfcfa30 100644 --- a/src/BufferParams.cpp +++ b/src/BufferParams.cpp @@ -37,6 +37,7 @@ #include "Spacing.h" #include "TexRow.h" #include "VSpace.h" +#include "PDFOptions.h" #include "frontends/alert.h" #include "insets/InsetListingsParams.h" @@ -290,6 +291,7 @@ public: * and for detached paragraphs in "indented" documents. */ VSpace defskip; + PDFOptions pdfoptions; }; @@ -435,6 +437,16 @@ Spacing const & BufferParams::spacing() const return pimpl_->spacing; } +PDFOptions & BufferParams::pdfoptions() +{ + return pimpl_->pdfoptions; +} + + +PDFOptions const & BufferParams::pdfoptions() const +{ + return pimpl_->pdfoptions; +} VSpace const & BufferParams::getDefSkip() const { @@ -633,6 +645,12 @@ string const BufferParams::readToken(Lexer & lex, string const & token) spacing().set(spacetranslator().find(nspacing), tmp_val); } else if (token == "\\float_placement") { lex >> float_placement; + } else if (token == "\\pdf_author") { + lex >> pdfoptions().author; + } else if (token == "\\pdf_title") { + lex >> pdfoptions().title; + } else if (token == "\\pdf_subject") { + lex >> pdfoptions().subject; } else { lyxerr << "BufferParams::readToken(): Unknown token: " << token << endl; @@ -694,6 +712,7 @@ void BufferParams::writeFile(ostream & os) const os << "\\paperfontsize " << fontsize << '\n'; spacing().writeFile(os); + pdfoptions().writeFile(os); os << "\\papersize " << string_papersize[papersize] << "\n\\use_geometry " << convert(use_geometry) @@ -939,6 +958,19 @@ bool BufferParams::writeLaTeX(odocstream & os, LaTeXFeatures & features, os << "}\n"; texrow.newline(); } + + // PDF support + if (!pdfoptions().empty()) { + os << "\\usepackage[\n"; +if (!pdfoptions().author.empty()) + os << "pdfauthor={" << from_utf8(pdfoptions().author) << "},\n"; +if (!pdfoptions().title.empty()) + os << "pdftitle={" << from_utf8(pdfoptions().title) << "},\n"; +if (!pdfoptions().subject.empty()) + os << "pdfsubject={" << from_utf8(pdfoptions().subject) << "},\n"; + os << "]{hyperref}"; + } + if (use_geometry || nonstandard_papersize) { os << "\\usepackage{geometry}\n"; texrow.newline(); diff --git a/src/BufferParams.h b/src/BufferParams.h index 620b78e..2745f66 100644 --- a/src/BufferParams.h +++ b/src/BufferParams.h @@ -42,6 +42,7 @@ class Spacing; class TexRow; class VSpace; class Language; +class PDFOptions; /** Buffer parameters. * This class contains all the parameters for this buffer's use. Some @@ -292,6 +293,10 @@ public: /// void setCiteEngine(biblio::CiteEngine const); + /// options for pdf output + PDFOptions & pdfoptions(); + PDFOptions const & pdfoptions() const; + pri
Re: [Bug 3974] crash with user defined external templates
Jean-Marc Lasgouttes schrieb: [EMAIL PROTECTED] (Jürgen Spitzmüller) writes: Jean-Marc Lasgouttes wrote: I lost the patch. Where is it? http://bugzilla.lyx.org/attachment.cgi?id=1959&action=view I have not see this patch before actually. Does the new libFileSearch have to build a vector>? We do not really care about "user_lyxdir" and such identifiers, IMO. This used is only for the message. insist on keeping this, a map would make more sense. That was also my first thought when i implemented this method, but with that approach we lose the order of the entries, which is essential for the logic. Other than that, this new function looks useful. So the new behaviour would be to merge the three template files (BTW, I am not sure the notion of build_dir is useful anymore, I don't know that either but i added it because it is used in the other libFileSearch method too. separate discussion). The code as it is written makes sense, but I do not like outputting error messages to the console. They should be turned into debug messages (if we keep them). Instead we could mark in the GUI where each template comes from. I think we need some kind of information for the user what is happening in this case, because if there is a problem because of one template hides another one the user should be able to find a hint about what's going on. bernhard
Re: 1.5.X Patch Candidate List #1
Michael Gerz wrote: Approved by Jürgen -- http://www.lyx.org/trac/changeset/19867 - InsetCollapsable::setStatus(): remove the Buffer::changed() signal emission I'll put this one in shortly. Very simple. ??? http://www.lyx.org/trac/changeset/20153 - Fix crash when layout file cannot be read due to failure to call makeTextClass() in that case. Not needed. This is for modules. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: ERT in title bug
Jürgen Spitzmüller wrote: Neal Becker wrote: In my title I tried to insert: Revision ERT{\input{build_id}} On the screen, it says: \INPUT{BUILD_ID} because I'm using ams art, and title is caps. I chose 'view source', it says: \title{SCMA Design Document\\ Revision \input{build_id}} \maketitle OK, fine. Just a screen buglet. Wait, no! lyx --export pdf ! LaTeX Error: File `BUILD_ID.tex' not found. With ERT, you're on your own. Try ERT{\MakeLowercase{\input{build_id}}} Jürgen Actually, I'm pretty sure this is a regression, which is due to the current_font text->cursor move. What happens is, ERT font used to be set explicitly, but now since there's no place to set it, it just takes the font from the surrounding text. So in an AMS title you'll apparently get all-caps, in an emph environment the text will all be emph, in a non-latin language you can't type latin text at all, which means ERT is useless in this context. See the thread http://permalink.gmane.org/gmane.editors.lyx.devel/93458. Something really should be done about this, but I'm not sure what the correct way to deal with this is... I suggested one approach in that message, but it's just an idea, I don't know if it would work in practice... Dov
Re: [Patch] partial support for units
On Tue, Sep 11, 2007 at 07:41:29PM +0300, Martin Vermeer wrote: > On Tue, Sep 11, 2007 at 05:37:32PM +0200, Andre Poenitz wrote: > > On Tue, Sep 11, 2007 at 10:50:56AM +0300, Martin Vermeer wrote: > > > Here's a better one. > > > > Not really ;-) > > > > > Index: src/mathed/InsetMathFrac.cpp > > > === > > > --- src/mathed/InsetMathFrac.cpp (revision 20193) > > > +++ src/mathed/InsetMathFrac.cpp (working copy) > > > @@ -48,9 +48,11 @@ > > > bool InsetMathFrac::metrics(MetricsInfo & mi, Dimension & dim) const > > > { > > >FracChanger dummy(mi.base); > > > + if (kind_ == UNITFRAC) > > > + ShapeChanger dummy2(mi.base.font, Font::UP_SHAPE); > > >cell(0).metrics(mi); > > >cell(1).metrics(mi); > > > > The ShapeChanger changes the Shape back to the original state when it is > > destructed, i.e. the end of its scope. In this particular piece of code > > the scope of 'dummy2' is the 'if' branch, i.e. the shape will already be > > restored before cell(0).metrics() is called. > > > > I am not sure that changing the shape is needed at all. Is the resulting > > metrics visually different? > > Perhaps not, but would it be wise to count on that? *shrug* If it walks likes a duck... Andre'
Re: [Patch] partial support for units
On Tue, Sep 11, 2007 at 05:58:56PM +0200, Jean-Marc Lasgouttes wrote: > Andre Poenitz <[EMAIL PROTECTED]> writes: > > > The ShapeChanger changes the Shape back to the original state when it is > > destructed, i.e. the end of its scope. In this particular piece of code > > the scope of 'dummy2' is the 'if' branch, i.e. the shape will already be > > restored before cell(0).metrics() is called. > > It would maybe be more useful to have a FontSaver, then, like: > >FontSaver dummy(mi.base.font); >if (whatever) > mi.base.font.setShape(Font::UP_SHAPE); > > and mi.base.font would be restored on scope exit. Actually, a generic > Saver class would be enough to solve all needs and seems much simpler > to me than all the hand-made FooChanger classes. It used to be shorter for common cases. Of course it is not forbidden to copy the whole font. Andre'
Re: 1.5.X Patch Candidate List #1
Michael Gerz wrote: > thanks for clearing the list. This is what is left: > http://www.lyx.org/trac/changeset/20016 - optimization: avoid some font > copying > http://www.lyx.org/trac/changeset/20021 - enable some non-rtl optimization These two are in. Jürgen
1.5.X Patch Candidate List #1
Hi, thanks for clearing the list. This is what is left: Approved by Jürgen -- Update to Boost 1.34.1 http://www.lyx.org/trac/changeset/19638 - redoParagraph() simplify the changed calculation http://www.lyx.org/trac/changeset/19868 - TextMetrics::redoParagraph(): we need to check the returned value of Inset::metrics() http://www.lyx.org/trac/changeset/19838 - Bug fix: correctly redraw a Row containing and inset which Dimension slightly changed http://www.lyx.org/trac/changeset/20016 - optimization: avoid some font copying http://www.lyx.org/trac/changeset/20021 - enable some non-rtl optimization http://www.lyx.org/trac/changeset/19867 - InsetCollapsable::setStatus(): remove the Buffer::changed() signal emission http://www.lyx.org/trac/changeset/20195 - unicodesymbols: workaround fix for an encoding bug in teTeX 3 /TeXLive 2005 New --- http://www.lyx.org/trac/changeset/19919 - Fix DEPM crash within inset. always clear the full text_metrics_ when doing a full update. ??? http://www.lyx.org/trac/changeset/20153 - Fix crash when layout file cannot be read due to failure to call makeTextClass() in that case. Regards, Michael
Re: Importing {\tiny ... }
Tommaso Cucinotta wrote: After importing a LaTeX doc with a {\tiny some text} command within a table caption, the caption text is shown on LyX tiny, but there is no way (AFAICS) to change it to standard size. What is the LyX way of setting/unsetting \tiny, \small, \big, etc ? Using LyX 1.5.1 for Linux. T. Select the tiny text Edit->Text STyle->Customized... You get a dialog - change to whatever size you need. Helge Hafting
Re: Idea: print via PDF preference
Jürgen Spitzmüller wrote: Helge Hafting wrote: Good idea, if only for "print as file". I definitely meant "print to printer", not "print to file". Those who want a file can still use File->export->pdflatex. Why? We have "print to file", which should provide at least these two options. (else, we should get rid of "print to file" completely). Sure, we could get rid of "print to file" because LyX have all that functionality and much more on "File->Export" The only reason I can see for having "print to file" is that people coming over from other word processors are used to having it. But that reason isn't very strong all the time the export menu is just as easy to get at. Well, you get to choose the filename which is useful occationally. Not only is this noticeably faster, but it also support printing documents using the microtype package. Modern LaTeX distributions use pdflatex also for DVI output. Nice - that means the problem will go away. But what latex distributions are considered "new"? I am using texlive from debian unstable, which is usually recent enough. TeXLive 2007 has it, I think teTeX 3 as well. I can't remember when the change happened. Hm. My texlive is version 2007, but view->dvi still produces a lot more hyphenations than view->PDF does, when I have \usepackage{microtype} in the preamble. Still, view->pdf and view->dvi comes up different when microtype is in use. I think some microtypographic features are disabled in pdftex's dvi mode. Ok, so there is a difference and it is not going away. Unless this disabling is configurable. Then I need File->print->printer to use the pdflatex way, so my printouts won't typeset differently from my PDFs. I use microtype in most documents. The current workaround is to export or view PDF, and then print the PDF from the command line or from the viewer. It'd sure be nice to just "print" it. The future will likely bring document classes (or .layouts) that specify microtype. Simpler users probably won't understand why File->Print doesn't match their PDF. I understand that many people still will need the postscript print, due to pstricks and such. So the question is how to implement this. I have some ideas: * A setting in "preferences" deciding what kind of export should be used (dvips/pdflatex) when producing a file to chuck at the printer. Of course this will decide the type of file produced by "print to file" if that option is kept. This way assumes that people rarely needs to make a change, and so the print dialog doesn't get cluttered with it. * A combobox in the "print" dialog. This assumes people find it useful to switch back and forth, for example people who utilize both microtype and pstricks - although not at the same time. Again, the combobox can decide the output type for the "print to file" too - assuming it isn't removed. * The document can contain information abot what kind of print capability is necessary. (I.e. LyX supporting microtype, and makes sure such documents prints using pdflatex. LyX could also support pstricks, at the very least by ensuring that printing happens via dvips. This is more userfriendly, as people won't _have_ to make sure they print the "correct" way. I hope to add microtype support later, it'd be nice to have such documents print correctly in one way or another. Helge Hafting
Re: [Patch] partial support for units
On Tue, Sep 11, 2007 at 05:58:56PM +0200, Jean-Marc Lasgouttes wrote: > Andre Poenitz <[EMAIL PROTECTED]> writes: > > > The ShapeChanger changes the Shape back to the original state when it is > > destructed, i.e. the end of its scope. In this particular piece of code > > the scope of 'dummy2' is the 'if' branch, i.e. the shape will already be > > restored before cell(0).metrics() is called. > > It would maybe be more useful to have a FontSaver, then, like: > >FontSaver dummy(mi.base.font); >if (whatever) > mi.base.font.setShape(Font::UP_SHAPE); > > and mi.base.font would be restored on scope exit. Actually, a generic > Saver class would be enough to solve all needs and seems much simpler > to me than all the hand-made FooChanger classes. Not a bad idea actually. - Martin
Re: [Patch] partial support for units
On Tue, Sep 11, 2007 at 05:37:32PM +0200, Andre Poenitz wrote: > On Tue, Sep 11, 2007 at 10:50:56AM +0300, Martin Vermeer wrote: > > Here's a better one. > > Not really ;-) > > > Index: src/mathed/InsetMathFrac.cpp > > === > > --- src/mathed/InsetMathFrac.cpp (revision 20193) > > +++ src/mathed/InsetMathFrac.cpp (working copy) > > @@ -48,9 +48,11 @@ > > bool InsetMathFrac::metrics(MetricsInfo & mi, Dimension & dim) const > > { > >FracChanger dummy(mi.base); > > + if (kind_ == UNITFRAC) > > + ShapeChanger dummy2(mi.base.font, Font::UP_SHAPE); > >cell(0).metrics(mi); > >cell(1).metrics(mi); > > The ShapeChanger changes the Shape back to the original state when it is > destructed, i.e. the end of its scope. In this particular piece of code > the scope of 'dummy2' is the 'if' branch, i.e. the shape will already be > restored before cell(0).metrics() is called. > > I am not sure that changing the shape is needed at all. Is the resulting > metrics visually different? Perhaps not, but would it be wise to count on that? > If so, something like > > bool InsetMathFrac::metrics(MetricsInfo & mi, Dimension & dim) const > { > FracChanger dummy(mi.base); > std::auto_ptr dummy2; > if (kind_ == UNITFRAC) > dummy2.reset(new ShapeChanger(mi.base.font, Font::UP_SHAPE)); > cell(0).metrics(mi); > cell(1).metrics(mi); > > might help. I this case the ShapeChanger will be destroyed at the > end of the function body. I was looking for something like this, but decided for another approach. > Andre' - Martin
Re: Embedding feature slows down updateLabels() very significantly!
> I am not quite sure what is > the best way to do this though. With a patch that I just submitted for review, this is the last major problem that needs to be resolved. Basically, I need to call EmbeddedFiles::update() (or emit embeddingChanged() signal) when an inset that has embedded files is created/removed/modified. Do you have any good idea? I am not against the idea of an 'update' button that forces the update. This will be most efficient. Cheers, Bo
Re: Embedding feature slows down updateLabels() very significantly!
On 9/11/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote: > I think... I have not done any profiling but this is possible. Because EmbeddedFiles now saves inset pointers (not ParConstIterator), EmbeddedFiles::update() should be moved out of updateLabels() and iscalled with inset addition and removal. I am not quite sure what is the best way to do this though. Cheers, Bo
[Embedding PATCH] update insets after the embedding status is changed
The attached patch 1. add Inset::updateEmbeddedFile, that will be called after the embedding status of a file is changed. A typical use is +void InsetGraphics::updateEmbeddedFile(Buffer const & buf, + EmbeddedFile const & file) +{ + params_.filename.set(file.availableFile(&buf), buf.filePath()); +} The problem here is that even if the underlying filename is changed, the Graphic dialog is not updated. Does anyone know how to do this? 2. add EmbeddedFile::updateInsets(Buffer&) and EmbeddedFiles::updateInsets() to update related insets. +void EmbeddedFile::updateInsets(Buffer const * buf) const +{ + vector::const_iterator it = inset_list_.begin(); + vector::const_iterator it_end = inset_list_.end(); + for (; it != it_end; ++it) + const_cast(*it)->updateEmbeddedFile(*buf, *this); +} + 3. call updateInsets at appropriate times. Such as when embedding is enabled, and when a file embedding status is changed. Because stored inset pointers are not guranteed to be up to date, EmbeddedFiles::update() is called before such calls. This adds another virtual function to Inset, so I need at least one OK. Jose? Bo Index: src/insets/InsetGraphics.h === --- src/insets/InsetGraphics.h (revision 20211) +++ src/insets/InsetGraphics.h (working copy) @@ -80,6 +80,8 @@ bool getStatus(Cursor &, FuncRequest const &, FuncStatus &) const; /// all graphics can be embedded void registerEmbeddedFiles(Buffer const &, EmbeddedFiles &) const; + /// + void updateEmbeddedFile(Buffer const &, EmbeddedFile const &); protected: InsetGraphics(InsetGraphics const &); /// Index: src/insets/InsetGraphics.cpp === --- src/insets/InsetGraphics.cpp (revision 20211) +++ src/insets/InsetGraphics.cpp (working copy) @@ -239,6 +239,20 @@ } +void InsetGraphics::updateEmbeddedFile(Buffer const & buf, + EmbeddedFile const & file) +{ + BOOST_ASSERT(buf.embeddedFiles().enabled()); + LYXERR(Debug::FILES) << "Update InsetGraphics file from " + << params_.filename.toFilesystemEncoding() << std::endl; + params_.filename.set(file.availableFile(&buf), buf.filePath()); + LYXERR(Debug::FILES) << " to " + << params_.filename.toFilesystemEncoding() << std::endl; + // FIXME: graphics dialog is not updated even if the underlying + // filename is updated. What should I do? +} + + void InsetGraphics::edit(Cursor & cur, bool) { InsetGraphicsMailer(*this).showDialog(&cur.bv()); Index: src/insets/Inset.h === --- src/insets/Inset.h (revision 20211) +++ src/insets/Inset.h (working copy) @@ -49,6 +49,7 @@ class ParIterator; class Text; class TocList; +class EmbeddedFile; class EmbeddedFiles; @@ -441,6 +442,8 @@ virtual void addToToc(TocList &, Buffer const &, ParConstIterator const &) const {} /// report files that can be embedded with the lyx file virtual void registerEmbeddedFiles(Buffer const &, EmbeddedFiles &) const {}; + /// use embedded or external file after the embedding status of a file is changed + virtual void updateEmbeddedFile(Buffer const &, EmbeddedFile const &) {} /// Fill keys with BibTeX information virtual void fillWithBibKeys(Buffer const &, BiblioInfo &, InsetIterator const &) const { return; } Index: src/EmbeddedFiles.cpp === --- src/EmbeddedFiles.cpp (revision 20212) +++ src/EmbeddedFiles.cpp (working copy) @@ -225,6 +225,15 @@ } +void EmbeddedFile::updateInsets(Buffer const * buf) const +{ + vector::const_iterator it = inset_list_.begin(); + vector::const_iterator it_end = inset_list_.end(); + for (; it != it_end; ++it) + const_cast(*it)->updateEmbeddedFile(*buf, *this); +} + + bool EmbeddedFiles::enabled() const { return buffer_->params().embedded; @@ -241,6 +250,8 @@ // if operation is successful buffer_->markDirty(); buffer_->params().embedded = flag; + if (flag) + updateInsets(); } } @@ -468,4 +479,14 @@ } +void EmbeddedFiles::updateInsets() const +{ + EmbeddedFiles::EmbeddedFileList::const_iterator it = begin(); + EmbeddedFiles::EmbeddedFileList::const_iterator it_end = end(); + for (; it != it_end; ++it) + if (it->valid() && it->refCount() > 0) + it->updateInsets(buffer_); } + + +} Index: src/frontends/controllers/ControlEmbeddedFiles.cpp === --- src/frontends/controllers/ControlEmbeddedFiles.cpp (revision 20213) +++ src/frontends/controllers/ControlEmbeddedFiles.cpp (working copy) @@ -89,6 +89,7 @@ item.updateFromExternalFile(&buffer()); else item.extract(&buffer()); + item.updateInsets(&buffer()); } } Index: src/EmbeddedFiles.h === --- src/EmbeddedFiles.h (revision 20212) +++ src/EmbeddedFiles.h (working copy) @@ -155,6 +155,1
Embedding feature slows down updateLabels() very significantly!
I think... Abdel.
Re: [Patch] partial support for units
Andre Poenitz <[EMAIL PROTECTED]> writes: > The ShapeChanger changes the Shape back to the original state when it is > destructed, i.e. the end of its scope. In this particular piece of code > the scope of 'dummy2' is the 'if' branch, i.e. the shape will already be > restored before cell(0).metrics() is called. It would maybe be more useful to have a FontSaver, then, like: FontSaver dummy(mi.base.font); if (whatever) mi.base.font.setShape(Font::UP_SHAPE); and mi.base.font would be restored on scope exit. Actually, a generic Saver class would be enough to solve all needs and seems much simpler to me than all the hand-made FooChanger classes. JMarc
Re: bug in lyx 1.5.1? notation* environment in book (AMS) documentclass
Jürgen Spitzmüller wrote: > Thanks for the report, I added it here: > http://bugzilla.lyx.org/show_bug.cgi?id=4078#c15 The fix, btw, is simple. Just change in amsmaths.inc, here: Style Notation* CopyStyle Remark* LatexName notation* LabelString "Notation." Preamble \theoremstyle{remark} \newtheorem*{notation*}[thm]{Notation} EndPreamble End the preamble definition to Preamble \theoremstyle{remark} \newtheorem*{notation*}{Notation} EndPreamble Jürgen
Re: Compiling with --enable-shared leads to errors.
On Tue, Sep 11, 2007 at 12:32:52PM +0100, José Matos wrote: > On Friday 07 September 2007 21:37:33 Tommaso Cucinotta wrote: > > Hi all, > > > > when compiling with --enable-shared (that would seem a good > > switch to enable at a first glance), > > On Linux yes, on other systems no. We tried this last month and result was > not good. And, you know, not being able to compile is not the way to ask > people test the new versions. > > > linking fails due to a double > > inclusion of Dialog.o. Details follow (version from SVN). > > > > T. > > OK, after André last fix it works now. The next problem is due to the fact > that I am compiling using share and without included boost. > > Make fails in the end by not linking with boost. (I am using the autotools*) --enable-shared is for people that do not ask questions ;-) > I can improved the situation by adding -lboost_regex and -lboost_filesystem I > get this: > > g++ -g -O -o .libs/lyx main.o ASpell.o ISpell.o SpellBase.o Box.o Dimension.o > PrinterParams.o > Thesaurus.o ./.libs/liblyxcore.so ./.libs/liblyxmathed.so > ./.libs/liblyxinsets.so > frontends/.libs/liblyxfrontends.so > frontends/qt4/.libs/liblyxqt4.so -L/usr/X11R6/lib > frontends/controllers/.libs/liblyxcontrollers.so ./.libs/liblyxgraphics.so > support/.libs/liblyxsupport.so -lboost_signals -lAiksaurus -laspell -lSM > -lICE -lz -lX11 -lQtGui -lQtCore -lboost_regex-mt -lboost_filesystem-mt > -Wl,--rpath -Wl,/usr/local/lib/lyx-1.6.0svn > /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libboost_regex-mt.so: undefined > reference to `u_digit_3_7' > /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libboost_regex-mt.so: undefined > reference to `u_isblank_3_7' > /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libboost_regex-mt.so: undefined > reference to `u_isspace_3_7' > /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libboost_regex-mt.so: undefined > reference to `u_tolower_3_7' > /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libboost_regex-mt.so: undefined > reference to `u_charFromName_3_7' > /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libboost_regex-mt.so: undefined > reference to `u_charType_3_7' > collect2: ld returned 1 exit status Do we use --without-included-boost regularily? Andre'
Re: bug in lyx 1.5.1? notation* environment in book (AMS) documentclass
Kai Johannes Keller wrote: > When I try to use the Notation*-environment within the book (AMS) > documentclass and want to view DVI, I get the following error message > from latex: Thanks for the report, I added it here: http://bugzilla.lyx.org/show_bug.cgi?id=4078#c15 Jürgen
Re: [Patch] partial support for units
On Tue, Sep 11, 2007 at 10:50:56AM +0300, Martin Vermeer wrote: > Here's a better one. Not really ;-) > Index: src/mathed/InsetMathFrac.cpp > === > --- src/mathed/InsetMathFrac.cpp (revision 20193) > +++ src/mathed/InsetMathFrac.cpp (working copy) > @@ -48,9 +48,11 @@ > bool InsetMathFrac::metrics(MetricsInfo & mi, Dimension & dim) const > { >FracChanger dummy(mi.base); > + if (kind_ == UNITFRAC) > + ShapeChanger dummy2(mi.base.font, Font::UP_SHAPE); >cell(0).metrics(mi); >cell(1).metrics(mi); The ShapeChanger changes the Shape back to the original state when it is destructed, i.e. the end of its scope. In this particular piece of code the scope of 'dummy2' is the 'if' branch, i.e. the shape will already be restored before cell(0).metrics() is called. I am not sure that changing the shape is needed at all. Is the resulting metrics visually different? If so, something like bool InsetMathFrac::metrics(MetricsInfo & mi, Dimension & dim) const { FracChanger dummy(mi.base); std::auto_ptr dummy2; if (kind_ == UNITFRAC) dummy2.reset(new ShapeChanger(mi.base.font, Font::UP_SHAPE)); cell(0).metrics(mi); cell(1).metrics(mi); might help. I this case the ShapeChanger will be destroyed at the end of the function body. Andre'
Re: r20202 [1/2] - in /lyx-devel/trunk/src/frontends: Dialogs...
On Tue, Sep 11, 2007 at 08:37:12AM +0200, Abdelrazak Younes wrote: > [EMAIL PROTECTED] wrote: > >Author: poenitz > >Date: Tue Sep 11 00:32:59 2007 > >New Revision: 20202 > > > >URL: http://www.lyx.org/trac/changeset/20202 > >Log: > >shuffle some frontend stuff around. merge controller(base) and "Kernel". > >Make frontend::Dialog pure virtual > > Good move. I think you should also move Dialog.{cpp,h} to frontends/ I am on the way... Andre'
Re: [PATCH[ New LFUN: layout-reload
Richard Heck <[EMAIL PROTECTED]> writes: > Whenever we reload the class, we do the "update layout" routine from > CutAndPaste, which is what is used for any change of classes. So > basically we're treating layout reload like change of class. The same > thing gets done on loading of modules. So, basically, if the layout > file can't be read, then you get switched to some other document > class. I see. Thanks. JMarc
bug in lyx 1.5.1? notation* environment in book (AMS) documentclass
Hi, is this a bug in lyx 1.5.1? I checked on bugzilla.lyx.org but found nothing corresponding, so I decided to post this to the developers list. When I try to use the Notation*-environment within the book (AMS) documentclass and want to view DVI, I get the following error message from latex: --- LaTeX Error: Missing \begin{document} \newtheorem*{notation*}[t hm]{Notation} You're in trouble here. Try typing to proceed. If that doesn't work, type X to quit. --- Isn't just the counter argument [thm] too much for the *-environment creator \newtheorem*? By the way, I'm really a fan of lyx, and lyx 1.5.1 is just great. I like especially the new sidebar for the contents menu, makes working with big documents so much easier... Greets Kai PS: Would be great if you could respond to ALL (including [EMAIL PROTECTED]), cause I'm not a member of the list.
Re: 1.5.X patch candidates - next iteration
Alfredo Braunstein wrote: > > Good. Alfredo, you can apply then. > > Err, these went in some days ago (you said ok if IMO they were safe). > So, in already. Right, I remember now. You really need to fix the mailing list issue ... Jürgen
Re: [Patch] partial support for units
On Tue, 11 Sep 2007 10:50:56 +0300 Martin Vermeer <[EMAIL PROTECTED]> wrote: > On Tue, 11 Sep 2007 08:15:11 +0300 > Martin Vermeer <[EMAIL PROTECTED]> wrote: > > > On Mon, Sep 10, 2007 at 10:42:32PM +0200, Andre Poenitz wrote: > > > On Mon, Sep 10, 2007 at 10:44:01PM +0300, Martin Vermeer wrote: > > > > OK for trunk? > > Here's a better one. > > - Martin Grmf. Not my day. Here is one that actually, verifiedly, works (and not only for a units fraction). - Martin Index: src/mathed/InsetMathFrac.h === --- src/mathed/InsetMathFrac.h (revision 20193) +++ src/mathed/InsetMathFrac.h (working copy) @@ -27,7 +27,8 @@ FRAC, OVER, ATOP, - NICEFRAC + NICEFRAC, + UNITFRAC }; /// Index: src/mathed/MathFactory.cpp === --- src/mathed/MathFactory.cpp (revision 20193) +++ src/mathed/MathFactory.cpp (working copy) @@ -370,6 +370,8 @@ return MathAtom(new InsetMathFrac(InsetMathFrac::OVER)); if (s == "nicefrac") return MathAtom(new InsetMathFrac(InsetMathFrac::NICEFRAC)); + if (s == "unitfrac") + return MathAtom(new InsetMathFrac(InsetMathFrac::UNITFRAC)); //if (s == "infer") // return MathAtom(new MathInferInset); if (s == "atop") Index: src/mathed/InsetMathFrac.cpp === --- src/mathed/InsetMathFrac.cpp (revision 20193) +++ src/mathed/InsetMathFrac.cpp (working copy) @@ -54,6 +54,11 @@ dim.wid = cell(0).width() + cell(1).width() + 5; dim.asc = cell(0).height() + 5; dim.des = cell(1).height() - 5; + } else if (kind_ == UNITFRAC) { + ShapeChanger dummy2(mi.base.font, Font::UP_SHAPE); + dim.wid = cell(0).width() + cell(1).width() + 5; + dim.asc = cell(0).height() + 5; + dim.des = cell(1).height() - 5; } else { dim.wid = std::max(cell(0).width(), cell(1).width()) + 2; dim.asc = cell(0).height() + 2 + 5; @@ -77,16 +82,24 @@ y - cell(0).descent() - 5); cell(1).draw(pi, x + cell(0).width() + 5, y + cell(1).ascent() / 2); - pi.pain.line(x + cell(0).width(), -y + dim_.des - 2, -x + cell(0).width() + 5, -y - dim_.asc + 2, Color::math); + } else if (kind_ == UNITFRAC) { + ShapeChanger dummy2(pi.base.font, Font::UP_SHAPE); + cell(0).draw(pi, x + 2, +y - cell(0).descent() - 5); + cell(1).draw(pi, x + cell(0).width() + 5, +y + cell(1).ascent() / 2); } else { cell(0).draw(pi, m - cell(0).width() / 2, y - cell(0).descent() - 2 - 5); cell(1).draw(pi, m - cell(1).width() / 2, y + cell(1).ascent() + 2 - 5); } + if (kind_ == NICEFRAC || kind_ == UNITFRAC) { + pi.pain.line(x + cell(0).width(), +y + dim_.des - 2, +x + cell(0).width() + 5, +y - dim_.asc + 2, Color::math); + } if (kind_ == FRAC || kind_ == OVER) pi.pain.line(x + 1, y - 5, x + dim_.wid - 2, y - 5, Color::math); @@ -111,7 +124,7 @@ cell(0).drawT(pain, m - cell(0).width() / 2, y - cell(0).descent() - 1); cell(1).drawT(pain, m - cell(1).width() / 2, y + cell(1).ascent()); // ASCII art: ignore niceties - if (kind_ == FRAC || kind_ == OVER || kind_ == NICEFRAC) + if (kind_ == FRAC || kind_ == OVER || kind_ == NICEFRAC || kind_ == UNITFRAC) pain.horizontalLine(x, y, dim_.width()); } @@ -128,6 +141,7 @@ break; case FRAC: case NICEFRAC: + case UNITFRAC: InsetMathNest::write(os); break; } @@ -143,6 +157,8 @@ return from_ascii("over"); case NICEFRAC: return from_ascii("nicefrac"); + case UNITFRAC: + return from_ascii("unitfrac"); case ATOP: return from_ascii("atop"); } @@ -183,8 +199,8 @@ void InsetMathFrac::validate(LaTeXFeatures & features) const { - if (kind_ == NICEFRAC) - features.require("nicefrac"); + if (kind_ == NICEFRAC || kind_ == UNITFRAC) + features.require("units"); InsetMathNest::validate(features); } Index: src/LaTeXFeatures.cpp === --- src/LaTeXFeatures.cpp (revision 20193) +++ src/LaTeXFeatures.cpp (working copy) @@ -405,7 +405,7 @@ "dvipost", "fancybox", "calc", - "nicefrac", + "units", "tipa", "framed", "pdfcolmk", Index: lib/ui/stdtoolbars.inc === --- lib/ui/stdtoolbars.inc (revision 20175) +++ lib/ui/stdtoolbars.inc (working copy) @@ -273,7 +273,8 @@ Toolbar "frac-square" "Fractions" Item "Standard \\frac" "math-insert \frac" Item "No hor. line \\atop" "math-insert \atop" - Item "Nice \\nicefrac" "math-insert \nicefrac" + Item "Nice (3/4) \\nicefrac" "math-insert \nicefrac" + Item "Units (km/h) \\unitfrac" "math-insert \unitfrac" Item "Text frac (amsmath) \\tfrac" "math-insert \tfrac" Item "Display frac (amsmath) \\dfrac" "math-insert \dfrac" Item "Binomial \\choose" "math-insert \choose"
Re: [PATCH[ New LFUN: layout-reload
Jean-Marc Lasgouttes wrote: Richard Heck <[EMAIL PROTECTED]> writes: Oh, it's not as bad as that, really. If the layout file can't be read, LyX will switch to something else, like Article (SGML), which is kind of a hassle. But it's not a critical error, and anyone who's editing their layouts shouldn't simultaneously be doing any serious work. So there isn't any real risk, I think, of data loss, and an appropriate warning could be issued. That said, since we do have a "Save All..." LFUN (we do now, right?) that could simply be called right before layout-reload does its actual work. I am not sure I understand how it works: each paragraph has a Layout pointer, right? How is this kept working after reloading the class? Whenever we reload the class, we do the "update layout" routine from CutAndPaste, which is what is used for any change of classes. So basically we're treating layout reload like change of class. The same thing gets done on loading of modules. So, basically, if the layout file can't be read, then you get switched to some other document class. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: 1.5.X patch candidates - next iteration
Jürgen Spitzmüller <[EMAIL PROTECTED]> writes: > > > Alfredo asked for some expert review. After that, it can go in. > > > (I've already approved that) > > > > They are safe IMHO. > > Good. Alfredo, you can apply then. Err, these went in some days ago (you said ok if IMO they were safe). So, in already. A/
Importing {\tiny ... }
After importing a LaTeX doc with a {\tiny some text} command within a table caption, the caption text is shown on LyX tiny, but there is no way (AFAICS) to change it to standard size. What is the LyX way of setting/unsetting \tiny, \small, \big, etc ? Using LyX 1.5.1 for Linux. T.
Re: Notifying users during long tasks.
Abdelrazak Younes ha scritto: Yes, and this doesn't have to change to do what you envision. I had once a patch that used the forkedcall mechanism that is used for graphics conversion (and for instant preview). As you probably know, graphics are converted asynchronously before they are shown on screen. I had once a patch that did exactly that but I can't seem to find it :-( Ok, infact the mechanism needs to be similar. Where are the points in the code where the graphics displaying activities are started and terminated/joined ? 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: Notifying users during long tasks.
Tommaso Cucinotta wrote: Helge Hafting ha scritto: If you di this - please make that a progress bar (or similiar) inside the main window - _not_ a popup thing. :-) Ok, guess smth. besides (or embedded into) the status bar. Despite the appearence, I guess the main problem is that LyX has a single thread design. Yes, and this doesn't have to change to do what you envision. I had once a patch that used the forkedcall mechanism that is used for graphics conversion (and for instant preview). As you probably know, graphics are converted asynchronously before they are shown on screen. I had once a patch that did exactly that but I can't seem to find it :-( So, if you have a long activity to be run externally to the current doc (let's say compiling a LaTeX/PS/PDF), it is safe to let the user keep modifying the doc. On the other hand, if the activity needs access to the doc, user activities should be inhibited (this is perfectly done by a very long Gui callback, even though it is not good to see), No, only the export to latex needs be synchronous because this is done by LyX itself; all other conversion can be asynchronous. Abdel.
Re: ERT in title bug
Neal Becker wrote: > In my title I tried to insert: > > Revision ERT{\input{build_id}} > > On the screen, it says: \INPUT{BUILD_ID} > > because I'm using ams art, and title is caps. > > I chose 'view source', it says: > \title{SCMA Design Document\\ > Revision \input{build_id}} > > \maketitle > > OK, fine. Just a screen buglet. Wait, no! > > lyx --export pdf > ! LaTeX Error: File `BUILD_ID.tex' not found. With ERT, you're on your own. Try ERT{\MakeLowercase{\input{build_id}}} Jürgen
Re: Notifying users during long tasks.
Helge Hafting ha scritto: If you di this - please make that a progress bar (or similiar) inside the main window - _not_ a popup thing. :-) Ok, guess smth. besides (or embedded into) the status bar. Despite the appearence, I guess the main problem is that LyX has a single thread design. So, if you have a long activity to be run externally to the current doc (let's say compiling a LaTeX/PS/PDF), it is safe to let the user keep modifying the doc. On the other hand, if the activity needs access to the doc, user activities should be inhibited (this is perfectly done by a very long Gui callback, even though it is not good to see), but at least there should be a way to cancel it if the user wants so (and this is not doable from within a long Gui callback). The best support for external (potentially long) activities I've ever seen within applications is the one of Eclipse, where user may even start or enqueue multiple activities, the system keeps track of dependencies among them, if any, and a progress dockable window may always be popped up by the user so to see what is not done yet and the state of advance of each activity. At last, if the user makes an operation that requires one of the activities to complete, then the user interaction is blocked until completition of that activity. But probably, I don't want to "use a cannon to shoot to a fly". 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
ERT in title bug
In my title I tried to insert: Revision ERT{\input{build_id}} On the screen, it says: \INPUT{BUILD_ID} because I'm using ams art, and title is caps. I chose 'view source', it says: \title{SCMA Design Document\\ Revision \input{build_id}} \maketitle OK, fine. Just a screen buglet. Wait, no! lyx --export pdf ! LaTeX Error: File `BUILD_ID.tex' not found. Ouch!
Re: Compiling with --enable-shared leads to errors.
On Friday 07 September 2007 21:37:33 Tommaso Cucinotta wrote: > Hi all, > > when compiling with --enable-shared (that would seem a good > switch to enable at a first glance), On Linux yes, on other systems no. We tried this last month and result was not good. And, you know, not being able to compile is not the way to ask people test the new versions. > linking fails due to a double > inclusion of Dialog.o. Details follow (version from SVN). > > T. OK, after André last fix it works now. The next problem is due to the fact that I am compiling using share and without included boost. Make fails in the end by not linking with boost. (I am using the autotools*) I can improved the situation by adding -lboost_regex and -lboost_filesystem I get this: g++ -g -O -o .libs/lyx main.o ASpell.o ISpell.o SpellBase.o Box.o Dimension.o PrinterParams.o Thesaurus.o ./.libs/liblyxcore.so ./.libs/liblyxmathed.so ./.libs/liblyxinsets.so frontends/.libs/liblyxfrontends.so frontends/qt4/.libs/liblyxqt4.so -L/usr/X11R6/lib frontends/controllers/.libs/liblyxcontrollers.so ./.libs/liblyxgraphics.so support/.libs/liblyxsupport.so -lboost_signals -lAiksaurus -laspell -lSM -lICE -lz -lX11 -lQtGui -lQtCore -lboost_regex-mt -lboost_filesystem-mt -Wl,--rpath -Wl,/usr/local/lib/lyx-1.6.0svn /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libboost_regex-mt.so: undefined reference to `u_digit_3_7' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libboost_regex-mt.so: undefined reference to `u_isblank_3_7' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libboost_regex-mt.so: undefined reference to `u_isspace_3_7' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libboost_regex-mt.so: undefined reference to `u_tolower_3_7' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libboost_regex-mt.so: undefined reference to `u_charFromName_3_7' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libboost_regex-mt.so: undefined reference to `u_charType_3_7' collect2: ld returned 1 exit status -- José Abílio
Re: 1.5.X patch candidates - next iteration
> Fixed in http://www.lyx.org/trac/changeset/20207 thanks Uwe
Re: question about PATH prefix under Linux and Mac
Richard Heck schrieb: On Linux, I would say something like the following: On *nix systems, the PATH will need to be set only if there are external programs you wish to use that are not in your normal system path ($PATH). Thanks for the infos, I'll add this today. regards Uwe
Re: Idea: print via PDF preference
Helge Hafting wrote: > > Good idea, if only for "print as file". > > > > I definitely meant "print to printer", not "print to file". > Those who want a file can still use File->export->pdflatex. Why? We have "print to file", which should provide at least these two options. (else, we should get rid of "print to file" completely). > >> Not only is this noticeably faster, but it also > >> support printing documents using the microtype package. > >> > > > > Modern LaTeX distributions use pdflatex also for DVI output. > > > > Nice - that means the problem will go away. But what latex > distributions are considered "new"? I am using texlive from > debian unstable, which is usually recent enough. TeXLive 2007 has it, I think teTeX 3 as well. I can't remember when the change happened. > Still, view->pdf and view->dvi comes up different when microtype > is in use. I think some microtypographic features are disabled in pdftex's dvi mode. Jürgen
Re: Notifying users during long tasks.
Tommaso Cucinotta wrote: Hi all, I'd like to know what is the most suitable way to notify users of the progress made during possibly long tasks, in LyX. The standard way would be to create a new thread, so to exit the Qt callback that started the long task, adding a progress bar or similar and updating it periodically, and a Cancel button that allows to stop the batch activity. Is there any reusable LyX component/code snippet for managing such situations ? If you di this - please make that a progress bar (or similiar) inside the main window - _not_ a popup thing. :-) Helge Hafting
Re: Idea: print via PDF preference
Jürgen Spitzmüller wrote: Helge Hafting wrote: The way I understand LyX printing, is that LyX basically do an "export->postscript" and then pass the resulting file to external printer software. I propose to implement another printing preference, that allows switching the printing to use an "export->pdflatex" instead. Good idea, if only for "print as file". I definitely meant "print to printer", not "print to file". Those who want a file can still use File->export->pdflatex. Not only is this noticeably faster, but it also support printing documents using the microtype package. Modern LaTeX distributions use pdflatex also for DVI output. Nice - that means the problem will go away. But what latex distributions are considered "new"? I am using texlive from debian unstable, which is usually recent enough. Still, view->pdf and view->dvi comes up different when microtype is in use. Helge Hafting
Re: 1.5.X patch candidates - next iteration
José Matos wrote: > If other title translations are added to doc_toc.py that should be reported > in status.15x. This patch is just an internal fix and since this does not > change any output, I have not filled any new entry to status.15x. > > I hope this is OK. :-) Fine with me. Jürgen
Re: 1.5.X patch candidates - next iteration
On Tuesday 11 September 2007 10:31:55 Jürgen Spitzmüller wrote: > Yes, please. Done. http://www.lyx.org/trac/changeset/20210 If other title translations are added to doc_toc.py that should be reported in status.15x. This patch is just an internal fix and since this does not change any output, I have not filled any new entry to status.15x. I hope this is OK. :-) > Jürgen -- José Abílio
Re: Figure scaling in LyX display
Darren Freeman <[EMAIL PROTECTED]> writes: > Hi all, > > how does LyX know how to scale an EPS figure when viewing it on-screen? > It's set to 100% and on my 16cm wide figure, it's more like 12.5cm. I'm > used to my 16cm-wide PNG figures requiring a 30% scaling in the LyX > display to end up with something much bigger. What DPI and zoom setting do you have in preferences? JMarc
Re: [Bug 3974] crash with user defined external templates
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes: > Jean-Marc Lasgouttes wrote: >> I lost the patch. Where is it? > > http://bugzilla.lyx.org/attachment.cgi?id=1959&action=view I have not see this patch before actually. Does the new libFileSearch have to build a vector>? We do not really care about "user_lyxdir" and such identifiers, IMO. If we insist on keeping this, a map would make more sense. Other than that, this new function looks useful. So the new behaviour would be to merge the three template files (BTW, I am not sure the notion of build_dir is useful anymore, but this is a separate discussion). The code as it is written makes sense, but I do not like outputting error messages to the console. They should be turned into debug messages (if we keep them). Instead we could mark in the GUI where each template comes from. JMarc
Re: 1.5.X patch candidates - next iteration
José Matos wrote: > The change is safe may I apply it to the stable branch? Yes, please. Jürgen
Re: 1.5.X patch candidates - next iteration
On Tuesday 11 September 2007 10:11:58 Jürgen Spitzmüller wrote: > How about branch? The change is safe may I apply it to the stable branch? > Jürgen -- José Abílio
Re: 1.5.X patch candidates - next iteration
José Matos wrote: > > doc_toc.py is nevertheless broken in trunk and branch when handling > > non-ascii characters. > > Fixed in http://www.lyx.org/trac/changeset/20207 How about branch? Jürgen
Re: 1.5.X patch candidates - next iteration
On Monday 10 September 2007 21:30:11 Uwe Stöhr wrote: > > http://www.lyx.org/trac/changeset/20173 - doc_toc.py: remove non-ascii > character since LyX.py can't encode it at the moment > > This is not a fix but a workaround. This problem was trunk only. > > doc_toc.py is nevertheless broken in trunk and branch when handling > non-ascii characters. Fixed in http://www.lyx.org/trac/changeset/20207 > regards Uwe -- José Abílio
Re: lyx2lyx or toc building is broken after user's guide update.
On Sunday 09 September 2007 17:15:28 Bo Peng wrote: > One of the problems is the title "Índice general LyX documentation" > can not be encoded at line 279 of LyX.py. This should be a unicode string. I changed all strings in that position to be unicode even although only the Spanish (for the moment) needs that distinction. In python a unicode string is a string that starts with an u. :-) Example: u"Olá" In python 3.0+ this distinction will disappear in the sense that all strings will be unicode. :-) I will commit the fix to trunk. > Bo -- José Abílio
Figure scaling in LyX display
Hi all, how does LyX know how to scale an EPS figure when viewing it on-screen? It's set to 100% and on my 16cm wide figure, it's more like 12.5cm. I'm used to my 16cm-wide PNG figures requiring a 30% scaling in the LyX display to end up with something much bigger. My display is 90DPI according to my calibration in Gimp. So it could be rendering at 70DPI by default and displaying 1:1 pixel wise. Or is it the PNG which displays wrong? They were 600DPI and if the figure size matadata were being ignored, instead using 1:1 pixel scaling, it would be huge and require scaling in LyX. Have fun, Darren
Re: [Bug 3974] crash with user defined external templates
Jean-Marc Lasgouttes wrote: > I lost the patch. Where is it? http://bugzilla.lyx.org/attachment.cgi?id=1959&action=view Jürgen
Re: [Bug 3974] crash with user defined external templates
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes: > Again, my opinion is that your patch does the right thing (preference of > user_lyxdir over build_lyxdir over system_lyxdir). > > Any objections? If not, I'd say put your fix in branch and trunk. I lost the patch. Where is it? JMarc
Re: [Embedding PATCH] Add manifest to .lyx file itself.
On Monday 10 September 2007 19:58:29 Bo Peng wrote: > Latest patch attached. Can I apply? OK. > Cheers, > Bo -- José Abílio
Re: 1.5.X patch candidates - next iteration
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes: > Michael Gerz wrote: >> http://www.lyx.org/trac/changeset/19473 - more verbose message > > I have backported this now What happened to using documentation for such large explanations? Somebody thinks that configure --help is not unreadable enough? ;) Seriously, all help message would be candidate for the ame obfuscation. I do not really understand why boost has this special treatment. JMarc
Re: [PATCH[ New LFUN: layout-reload
Richard Heck <[EMAIL PROTECTED]> writes: > Oh, it's not as bad as that, really. If the layout file can't be read, > LyX will switch to something else, like Article (SGML), which is kind > of a hassle. But it's not a critical error, and anyone who's editing > their layouts shouldn't simultaneously be doing any serious work. So > there isn't any real risk, I think, of data loss, and an appropriate > warning could be issued. That said, since we do have a "Save All..." > LFUN (we do now, right?) that could simply be called right before > layout-reload does its actual work. I am not sure I understand how it works: each paragraph has a Layout pointer, right? How is this kept working after reloading the class? JMarc
Re: [Patch] partial support for units
On Tue, 11 Sep 2007 08:15:11 +0300 Martin Vermeer <[EMAIL PROTECTED]> wrote: > On Mon, Sep 10, 2007 at 10:42:32PM +0200, Andre Poenitz wrote: > > On Mon, Sep 10, 2007 at 10:44:01PM +0300, Martin Vermeer wrote: > > > OK for trunk? Here's a better one. - Martin Index: src/mathed/InsetMathFrac.h === --- src/mathed/InsetMathFrac.h (revision 20193) +++ src/mathed/InsetMathFrac.h (working copy) @@ -27,7 +27,8 @@ FRAC, OVER, ATOP, - NICEFRAC + NICEFRAC, + UNITFRAC }; /// Index: src/mathed/MathFactory.cpp === --- src/mathed/MathFactory.cpp (revision 20193) +++ src/mathed/MathFactory.cpp (working copy) @@ -370,6 +370,8 @@ return MathAtom(new InsetMathFrac(InsetMathFrac::OVER)); if (s == "nicefrac") return MathAtom(new InsetMathFrac(InsetMathFrac::NICEFRAC)); + if (s == "unitfrac") + return MathAtom(new InsetMathFrac(InsetMathFrac::UNITFRAC)); //if (s == "infer") // return MathAtom(new MathInferInset); if (s == "atop") Index: src/mathed/InsetMathFrac.cpp === --- src/mathed/InsetMathFrac.cpp (revision 20193) +++ src/mathed/InsetMathFrac.cpp (working copy) @@ -48,9 +48,11 @@ bool InsetMathFrac::metrics(MetricsInfo & mi, Dimension & dim) const { FracChanger dummy(mi.base); + if (kind_ == UNITFRAC) + ShapeChanger dummy2(mi.base.font, Font::UP_SHAPE); cell(0).metrics(mi); cell(1).metrics(mi); - if (kind_ == NICEFRAC) { + if (kind_ == NICEFRAC || kind_ == UNITFRAC) { dim.wid = cell(0).width() + cell(1).width() + 5; dim.asc = cell(0).height() + 5; dim.des = cell(1).height() - 5; @@ -72,7 +74,9 @@ setPosCache(pi, x, y); int m = x + dim_.wid / 2; FracChanger dummy(pi.base); - if (kind_ == NICEFRAC) { + if (kind_ == UNITFRAC) + ShapeChanger dummy2(pi.base.font, Font::UP_SHAPE); + if (kind_ == NICEFRAC || kind_ == UNITFRAC) { cell(0).draw(pi, x + 2, y - cell(0).descent() - 5); cell(1).draw(pi, x + cell(0).width() + 5, @@ -111,7 +115,7 @@ cell(0).drawT(pain, m - cell(0).width() / 2, y - cell(0).descent() - 1); cell(1).drawT(pain, m - cell(1).width() / 2, y + cell(1).ascent()); // ASCII art: ignore niceties - if (kind_ == FRAC || kind_ == OVER || kind_ == NICEFRAC) + if (kind_ == FRAC || kind_ == OVER || kind_ == NICEFRAC || kind_ == UNITFRAC) pain.horizontalLine(x, y, dim_.width()); } @@ -128,6 +132,7 @@ break; case FRAC: case NICEFRAC: + case UNITFRAC: InsetMathNest::write(os); break; } @@ -143,6 +148,8 @@ return from_ascii("over"); case NICEFRAC: return from_ascii("nicefrac"); + case UNITFRAC: + return from_ascii("unitfrac"); case ATOP: return from_ascii("atop"); } @@ -183,8 +190,8 @@ void InsetMathFrac::validate(LaTeXFeatures & features) const { - if (kind_ == NICEFRAC) - features.require("nicefrac"); + if (kind == NICEFRAC || kind_ == UNITFRAC) + features.require("units"); InsetMathNest::validate(features); } Index: src/LaTeXFeatures.cpp === --- src/LaTeXFeatures.cpp (revision 20193) +++ src/LaTeXFeatures.cpp (working copy) @@ -405,7 +405,7 @@ "dvipost", "fancybox", "calc", - "nicefrac", + "units", "tipa", "framed", "pdfcolmk", Index: lib/ui/stdtoolbars.inc === --- lib/ui/stdtoolbars.inc (revision 20175) +++ lib/ui/stdtoolbars.inc (working copy) @@ -273,7 +273,8 @@ Toolbar "frac-square" "Fractions" Item "Standard \\frac" "math-insert \frac" Item "No hor. line \\atop" "math-insert \atop" - Item "Nice \\nicefrac" "math-insert \nicefrac" + Item "Nice (3/4) \\nicefrac" "math-insert \nicefrac" + Item "Units (km/h) \\unitfrac" "math-insert \unitfrac" Item "Text frac (amsmath) \\tfrac" "math-insert \tfrac" Item "Display frac (amsmath) \\dfrac" "math-insert \dfrac" Item "Binomial \\choose" "math-insert \choose"
Re: 1.5.X patch candidates - next iteration
On Tue, 11 Sep 2007 07:58:09 +0200 [EMAIL PROTECTED] (Jürgen Spitzmüller) wrote: > > http://www.lyx.org/trac/changeset/20104 - Better error signaling > > Not applicable, I think. Martin? Not relevant, relates to inset configurability which is not in 1.5 - Martin
[patch] Re: Upgrading boost in branch
Jürgen Spitzmüller wrote: > Does anybody feel confident enough to do this task? I'm a bit reluctant > doing this myself. Since nobody stepped forward, I had a go myself and just copied the boost directory just after Lars' update in rev. 19398 ("Update to latest from boost 1.34.x branch") to branch. Attached is what I came up with. Compiles fine here and looks sensible, AFAICT. Have I missed something obvious? If not I'm gonna commit that. Jürgen boost.diff.gz Description: GNU Zip compressed data
Re: 1.5.X patch candidates - next iteration
Jürgen Spitzmüller wrote: Abdelrazak Younes wrote: http://www.lyx.org/trac/changeset/19919 - Fix DEPM crash within inset. always clear the full text_metrics_ when doing a full update. Applicable to branch? In theory yes but this will have side effects within insets. What kind of side effects? I am not sure... maybe crashes, maybe cleared out text... In trunk, the only side effect (besides fixing the DEPM crash) was that I had to force full repaint in tabular cells. But a full repaint occurred anyway so no harm done. I'll tell you what, I'll produce a patch and let you test it and decide if it is safe or not. OTOH, that may solve some of the not easily reproducible crashes that have been reported. Which ones? Bo reported some crash IIRC. There were also problems with cursor positioning in table IIRC that may be solved by this. Abdel.
Re: Fwd: [Bug 4173] Middle-button paste between apps sometimes uses old selection.
Darren Freeman wrote: > There is a patch floating around which still applies cleanly. I just > haven't had a chance to verify the corner cases. Please go on without > me :) Make sure it's in branch. It turned out this patch was superseded by some alternative approach. Jürgen