Re: [PATCH] bug 3537: lyx-1.5.0beta2 dumps core on freebsd-6.2 when it tries to handle strings of filenames etc.
> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes: Peter> Is it correct that this line remains untouched? Peter> #if SIZEOF_WCHAR_T != 4 && defined(__GNUC__) && Peter> defined(__GNUC_MINOR__) && __GNUC__ == 3 && __GNUC_MINOR__ < 4 No, and I do not know how I missed it. I think it should be #if ! defined(USE_WCHAR_T) && defined(__GNUC__) && defined(__GNUC_MINOR__) && __GNUC__ == 3 && __GNUC_MINOR__ < 4 JMarc
Re: [patch] Re: RTL justification bug
Am 26.06.2007 um 21:25 schrieb Dov Feldstern: Stefan Schimanski wrote: +// If the last logical character is a separator, skip it, unless +// it's in the last row of a paragraph +if (end > 0 && end < par.size() && par.isSeparator(end - 1)) +skipped_sep_vpos = bidi.log2vis(end - 1); I thought it's about the visually last (or first for rtl paragraphs) character. Take HEBREW[ english] rendered as [ english]WERBEH No? I also thought so, but then I realized that it's more subtle. The real problem is with the last *logical* position, which is usually, but not always, at one of the ends. See the attached document for an example. (This is the other manifestation of the bug that I mentioned last night). Try it with and without the patch... Ok, after rereading your previous mail I got it. Would be good to put a better documentation there like: // Spaces at line breaks in bidi text can appear visually in the middle // of a row and must be skipped during painting: // * logically "abc_[HEBREW_\nHEBREW]" // * visually "abc_[_WERBEH\nWERBEH]" Haven't tested the patch, but it looks good. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: Any last minute request?
> "Jürgen" == Jürgen Spitzmüller <[EMAIL PROTECTED]> writes: Jürgen> José Matos wrote: >> Yes. Jürgen> Thanks. I'm done with my patches now (I wait witth the one for Jürgen> bug 3915 unless Jean-Marc and I have come to a conclusion). I think the latest patch is better than what we had previously, but that it fails with windows. So it should probably wait a bit (not urgent for RC2). JMarc
Re: [patch] Re: RTL justification bug
Stefan Schimanski wrote:
Ok, after rereading your previous mail I got it. Would be good to put a
better documentation there like:
// Spaces at line breaks in bidi text can appear visually in the middle
// of a row and must be skipped during painting:
// * logically "abc_[HEBREW_\nHEBREW]"
// * visually "abc_[_WERBEH\nWERBEH]"
Haven't tested the patch, but it looks good.
Stefan
Thanks, Stefan. Attached the same patch, but better-commented...
Any other opinions?
Dov
Index: src/Text.cpp
===
--- src/Text.cpp(revision 18899)
+++ src/Text.cpp(working copy)
@@ -1718,6 +1718,12 @@
pos_type const row_pos = row.pos();
pos_type const end = row.endpos();
+ // Spaces at logical line breaks in bidi text must be skipped during
+ // cursor positioning. However, they may appear visually in the middle
+ // of a row; they must be skipped, wherever they are...
+ // * logically "abc_[HEBREW_\nHEBREW]"
+ // * visually "abc_[_WERBEH\nWERBEH]"
+ pos_type skipped_sep_vpos = -1;
if (end <= row_pos)
cursor_vpos = row_pos;
@@ -1743,7 +1749,15 @@
FontMetrics const & labelfm = theFontMetrics(
getLabelFont(buffer, par));
+ // If the last logical character is a separator, skip it, unless
+ // it's in the last row of a paragraph; see skipped_sep_vpos declaration
+ if (end > 0 && end < par.size() && par.isSeparator(end - 1))
+ skipped_sep_vpos = bidi.log2vis(end - 1);
+
for (pos_type vpos = row_pos; vpos < cursor_vpos; ++vpos) {
+ // Skip the separator which is at the logical end of the row
+ if (vpos == skipped_sep_vpos)
+ continue;
pos_type pos = bidi.vis2log(vpos);
if (body_pos > 0 && pos == body_pos - 1) {
// FIXME UNICODE
Index: src/rowpainter.cpp
===
--- src/rowpainter.cpp (revision 18899)
+++ src/rowpainter.cpp (working copy)
@@ -734,6 +734,12 @@
void RowPainter::paintText()
{
pos_type const end = row_.endpos();
+ // Spaces at logical line breaks in bidi text must be skipped during
+ // painting. However, they may appear visually in the middle
+ // of a row; they must be skipped, wherever they are...
+ // * logically "abc_[HEBREW_\nHEBREW]"
+ // * visually "abc_[_WERBEH\nWERBEH]"
+ pos_type skipped_sep_vpos = -1;
pos_type body_pos = par_.beginOfBody();
if (body_pos > 0 &&
(body_pos > end || !par_.isLineSeparator(body_pos - 1))) {
@@ -751,10 +757,21 @@
Font font;
Buffer const & buffer = *bv_.buffer();
+ // If the last logical character is a separator, don't paint it, unless
+ // it's in the last row of a paragraph; see skipped_sep_vpos declaration
+ if (end > 0 && end < par_.size() && par_.isSeparator(end - 1))
+ skipped_sep_vpos = bidi_.log2vis(end - 1);
+
for (pos_type vpos = row_.pos(); vpos < end; ) {
if (x_ > bv_.workWidth())
break;
+ // Skip the separator at the logical end of the row
+ if (vpos == skipped_sep_vpos) {
+ ++vpos;
+ continue;
+ }
+
pos_type const pos = bidi_.vis2log(vpos);
if (pos >= par_.size()) {
Re: [PATCH] Reworking of Paragraph Settings Dialog
Edwin Leuven wrote: Asger Ottar Alstrup wrote: instead? If you don't like the word Built-in, then please make it Default Alignment for Current Paragraph (Justified) to make it *extra* clear what default we are talking about. There is room enough, according to the screen shot. or even more verbose: "Use this paragraph's default alignment (Justified)" That's fine with me, though I'd suggest "the" instead of "this", as that is OK for the multi-paragraph case, too. 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
[PATCH-updated] Reworking of Paragraph Settings Dialog
An update to the previous patch, incorporating a check for a multi-paragraph selection. I'll commit after rc2, if there is no objection. I go away Thursday morning on vacation, though, so if rc2 is not out by then, someone else will have to do it for me Richard The attached patch deals with the remaining issues with the Paragraph Settings dialog, after the long discussion about how to do it. I've redesigned the dialog itself in accord with some ideas of Edwin's, adapting also some suggestions of Helge's and now a suggestion by Asger. Something even better, in the non-multi-paragraph case, might be to make it say "Default for Standard" or "Default for Itemize" or whatever. But I think doing this will involve rather more work, as the extant controller doesn't provide access to this. There are a couple "FIXME"s here that refer to the fact that LYX_ALIGN_LAYOUT isn't required to be a possible alignment. Obviously, it should be. The second patch I've attached makes this change---and another one, namely: Why should LYX_ALIGN_BLOCK be possible by default? No good reason, so far as I can see. With this, the two FIXMEs can be fixed (and I think a proper solution for some other bugs also comes into sight, but later). I'll commit this as a separate patch, however. I can commit all of this later tonight if someone tells me how to deal with the multi-paragraph bit. Or someone can fix that and commit it for me. I don't care. Either way. 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
[PATCH-updated] Reworking of Paragraph Settings Dialog
An update to the previous patch, incorporating a check for a
multi-paragraph selection. I'll commit after rc2, if there is no
objection. I go away Thursday morning on vacation, though, so if rc2 is
not out by then, someone else will have to do it for me
Richard
The attached patch deals with the remaining issues with the Paragraph
Settings dialog, after the long discussion about how to do it. I've
redesigned the dialog itself in accord with some ideas of Edwin's,
adapting also some suggestions of Helge's and now a suggestion by Asger.
Something even better, in the non-multi-paragraph case, might be to make
it say "Default for Standard" or "Default for Itemize" or whatever. But
I think doing this will involve rather more work, as the extant
controller doesn't provide access to this.
There are a couple "FIXME"s here that refer to the fact that
LYX_ALIGN_LAYOUT isn't required to be a possible alignment. Obviously,
it should be. The second patch I've attached makes this change---and
another one, namely: Why should LYX_ALIGN_BLOCK be possible by default?
No good reason, so far as I can see. With this, the two FIXMEs can be
fixed (and I think a proper solution for some other bugs also comes into
sight, but later). I'll commit this as a separate patch, however.
I can commit all of this later tonight if someone tells me how to deal
with the multi-paragraph bit. Or someone can fix that and commit it for
me. I don't care. Either way.
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
Index: src/Paragraph.cpp
===
--- src/Paragraph.cpp (revision 18905)
+++ src/Paragraph.cpp (working copy)
@@ -1781,8 +1781,13 @@
os << "\\noindent ";
column += 10;
}
+
+ LyXAlignment const curAlign = params().align();
- switch (params().align()) {
+ if (curAlign == layout()->align)
+ return column;
+
+ switch (curAlign) {
case LYX_ALIGN_NONE:
case LYX_ALIGN_BLOCK:
case LYX_ALIGN_LAYOUT:
@@ -1798,7 +1803,7 @@
break;
}
- switch (params().align()) {
+ switch (curAlign) {
case LYX_ALIGN_NONE:
case LYX_ALIGN_BLOCK:
case LYX_ALIGN_LAYOUT:
Index: src/ParagraphParameters.cpp
===
--- src/ParagraphParameters.cpp (revision 18905)
+++ src/ParagraphParameters.cpp (working copy)
@@ -279,14 +279,11 @@
// This needs to be done separately
params.labelWidthString(par.getLabelWidthString());
- // Alignment
- Layout_ptr const & layout = par.layout();
- if (params.align() == LYX_ALIGN_LAYOUT)
- params.align(layout->align);
-
ostringstream os;
params.write(os);
+ Layout_ptr const & layout = par.layout();
+
// Is alignment possible
os << "\\alignpossible " << layout->alignpossible << '\n';
Index: src/Text2.cpp
===
--- src/Text2.cpp (revision 18905)
+++ src/Text2.cpp (working copy)
@@ -649,16 +649,12 @@
params.spacing(spacing);
// does the layout allow the new alignment?
- Layout_ptr const & layout = par.layout();
-
- if (align == LYX_ALIGN_LAYOUT)
- align = layout->align;
- if (align & layout->alignpossible) {
- if (align == layout->align)
-params.align(LYX_ALIGN_LAYOUT);
- else
-params.align(align);
- }
+ //FIXME The reason we need the first check is because
+ //LYX_ALIGN_LAYOUT isn't required to be possible. It
+ //should be...and will be.
+ if ((align == LYX_ALIGN_LAYOUT) ||
+ (align & par.layout()->alignpossible))
+ params.align(align);
par.setLabelWidthString(labelwidthstring);
params.noindent(noindent);
}
Index: src/frontends/controllers/ControlParagraph.h
===
--- src/frontends/controllers/ControlParagraph.h (revision 18905)
+++ src/frontends/controllers/ControlParagraph.h (working copy)
@@ -38,6 +38,8 @@
///
ParagraphParameters const & params() const;
///
+ bool const haveMulitParSelection();
+ ///
bool inInset() const;
///
bool canIndent() const;
Index: src/frontends/controllers/ControlParagraph.cpp
===
--- src/frontends/controllers/ControlParagraph.cpp (revision 18905)
+++ src/frontends/controllers/ControlParagraph.cpp (working copy)
@@ -14,7 +14,9 @@
#include "ControlParagraph.h"
#include "Buffer.h"
#include "BufferParams.h"
+#include "BufferView.h"
#include "ButtonController.h"
+#include "Cursor.h"
#include "FuncRequest.h"
#include "Lexer.h"
#include "Paragraph.h"
@@ -150,6 +152,13 @@
}
+bool const ControlParagraph::haveMulitParSele
Re: [PATCH] bug 3537: lyx-1.5.0beta2 dumps core on freebsd-6.2 when it tries to handle strings of filenames etc.
On Tue, Jun 26, 2007 at 02:19:47PM -0500, Bo Peng wrote: > On 6/26/07, Bo Peng <[EMAIL PROTECTED]> wrote: > > > > Are you sure about the name here? Not __NETBSD__? > > > > > > > > When I google, I see a lot of > > > > defined (__FreeBSD__) || defined (__OpenBSD__) || defined(__OpenBSD__) > > Of course I meant FreeBSD, OpenBSD and NetBSD. I don't know for the others. As regards NetBSD, I have an ancient version and just checked the output of "g++ -E -dM -xc++ /dev/null". Looking at the URL provided by Peter, seems that you are right, though. -- Enrico
Re: problems to show figures in LyX
On Tue, Jun 26, 2007 at 09:38:44PM +0200, Michael Gerz wrote: > Enrico Forestieri schrieb: > > On Wed, Jun 20, 2007 at 09:44:12AM +0100, José Matos wrote: > > > >> On Wednesday 20 June 2007 00:00:06 Enrico Forestieri wrote: > >> > >>> The attached patch fixes it. José, OK to commit? > >>> > >> The patch seems right. If you someone to test this and guarantee that it > >> works (no need to be a developer) it can go in. > >> > > > > Here is an updated patch that also cures the following startup error > > on *nix/cygwin: > > > > Error returned from iconv > > EILSEQ An invalid multibyte sequence has been encountered in the input. > > When converting from UTF-8 to UCS-4LE. > > Input: 0x2f 0x74 0x6d 0x70 0x2f 0x6f 0x6c 0xe0 0x2f 0x6c 0x79 0x78 0x5f > > 0x74 0x6d 0x70 0x64 0x69 0x72 0x32 0x30 0x30 0x30 0x63 0x77 0x73 0x63 0x54 > > 0x6c 0x2f 0x6c 0x79 0x78 0x73 0x6f 0x63 0x6b 0x65 0x74 > > > > and this one on windows: > > > AFAICS, there are a couple of pending patches Uh? > Has the patch above (or a similar one) been committed in the meantime? Yes: http://www.lyx.org/trac/changeset/18893 -- Enrico
Re: Enhancement
On Tue, 2007-06-26 at 17:01 +0200, Mael Hilléreau wrote: > I have a feature request: Would it be possible to perform output > generation in a different thread so that LyX wouldn't freeze while > compiling? This would be particularly appreciated with big documents > which take a long time to come up. > > May I file an enhancement at bugzilla? (I didn't find any dealing > with this) This one is relevant but it doesn't include threading: http://bugzilla.lyx.org/show_bug.cgi?id=3601 I'm sure we discussed running this in another thread on this list but I don't think I filed it. I agree though, it would be a big improvement. Please CC me if you file it. Have fun, Darren
Blank line not cleaned up?
Hi all, I just imported a Word document and am now cleaning it up. I found a curiosity for you: after a subsection heading, there was a blank line before the next paragraph. I only noticed it because of the wrong indenting of the next paragraph. I can't create such a blank line so it's obviously not supposed to be there. I'm guessing if you have one in the LyX file though it never gets noticed. Sorry but I don't have an example file for you. Hopefully the above is enough :) Have fun, Darren
Add BibTeX database confusing
Hi all, I just added a fresh BibTeX database to a document and found the file selection dialogue to be utterly baffling. Is it meant to be like that?? Have fun, Darren
Re: [PATCH] Reworking of Paragraph Settings Dialog
Richard Heck wrote: > > "Use this paragraph's default alignment (Justified)" > > That's fine with me, though I'd suggest "the" instead of "this", as that > is OK for the multi-paragraph case, too. Oh no, please don't. Use tooltips for verbose hints (you can't imagine how long this label will be in the German translation). Jürgen
User guide inaccuracy
User guide section 5.7.2 Math Text Mode.
Footnote reads: "Moreover, math text mode outputs its contents inside a
\textrm{}, whereas and \mbox (or AMS-LaTeX's \text) might have been a
better choice"
This is wrong because LyX now uses \mbox{}.
Have fun,
Darren
Re: Mathed sub/superscripts highlighting
On Mon, 2007-05-21 at 17:21 +0200, Jean-Marc Lasgouttes wrote:
> > "Darren" == Darren Freeman <[EMAIL PROTECTED]> writes:
>
> Darren> On Mon, 2007-05-21 at 16:16 +0200, Herbert Voss wrote:
> >> {Ge}^3 is different to
> >>
> >> Ge^3 and G^3 and e^3, which have all the same vertical height.
>
> Darren> So how does one enter {Ge}^3 in LyX other than ERT?
>
> Once you have your e^3 entered, your can go in the 'e' box and add the
> G. Not very intuitive, I know...
According to the View->Source panel, these both result in $Ge^{3}$.
Did this get broken recently? I have been using this "feature" to put my
chemical elements as the nucleus of a subscript for a while and I'd hate
to think it was for nothing.
Also, shouldn't LyX refrain from outputting the curly braces on the
sub/superscript unless it's more than one char?
Have fun,
Darren
[patch] bug 3931: elsart.layout fix
http://bugzilla.lyx.org/show_bug.cgi?id=3931
A simple fix, as \ack does not use a counter (it uses \section* internally)
and is output in plural form in DVI.
This could also go in branch. OK?
Jürgen
Index: lib/layouts/elsart.layout
===
--- lib/layouts/elsart.layout (Revision 18906)
+++ lib/layouts/elsart.layout (Arbeitskopie)
@@ -430,7 +430,7 @@
LatexName ack
Labeltype Top_Environment
LabelBottomsep1
- LabelString "Acknowledgement \arabic{theorem}"
+ LabelString "Acknowledgements"
parsep0.3
LabelFont
Sizelarge
[PATCH] Bug3313 unicode error when invoking lyx2lyx
A small patch to handle characters with diaeresis (as ä and ö) where " is part of the ERT expression. Anders new-patch Description: Binary data
