Asger Ottar Alstrup wrote:
One conclusion is clear: The only sure way to get substantially faster
rendering is to draw less on the screen, as discussed earlier today,
either by introducing the old singlePar optimisation, or do some
drawing-caching scheme.
I'm of the opinion that in 1.6 we s
Hi Abdel,
as much as I know before we started on fixing bugs there I was not able
to scroll trough the UserGuide without hitting an Assert ;)
I think that this is due to the "more" metrics calculations we have to do
in order to fix all that scrolling bugs and with it the removal of the
nullpaint
Hello Asger,
I bought my tickets yesterday (Sterling: for 151€ ;)
So if nothing happens I will be there with all off you.
I will arrive Thurthday 19 October Afternoon and depart
Monday 23 October Midday.
Till then,
Jürgen
Asger Ottar Alstrup wrote:
Dear Jürgen,
It would be great if
Hello,
I may be also attending the meeting, but I have to do some
checks still :)
Greets,
Jürgen
--
**
Würth Phoenix S.r.l.
Dr. Jürgen Vigna
System Integration
Via Kravogl 4, I-39100 Bolzano
Phone: +39 0471 564111
Dir
This works! Thanks a lot! How did you discover this?
Greets,
Jürgen
Lars Gullik Bjønnes wrote:
Juergen Vigna <[EMAIL PROTECTED]> writes:
| Hello there,
|
| i tried today to build lyx on my RedHat 4 system and the build was OK,
| but when trying to run it I get a Segmentation
Hello there,
i tried today to build lyx on my RedHat 4 system and the build was OK,
but when trying to run it I get a Segmentation fault. Anyone has similar
experiences?
This is the gdb backtrace:
$ gdb src/lyx-xforms
GNU gdb Red Hat Linux (6.3.0.0-1.96rh)
Copyright 2004 Free Software Foundatio
Hello Lars,
I've seen that we have again an 100% full /var filesystem on www.lyx.org :(
It seems that blocks the mails from there.
Could you have a look please.
Best regards,
Jürgen
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE
Hello Angus,
I wish you, Emma and little William all the best.
Enjoy him till he's little that are the best years (also if sometimes tiresome
;)
Kind regards,
Jürgen
Angus Leeming wrote:
Dear all,
I'd like to announce the arrival of William who arrived on Tuesday 15
November, we
What do you mean my flight dates/times?
Arrival in Paris evening the 14th, departure evening the 18th :)
I will check back with you as soon as I have all plans ready,
for the moment I just booked the flight (77 €).
~Jürgen
Jean-Marc Lasgouttes wrote:
"Juergen" == Juergen Vig
I already bought my tickets today, so most probably we will meet up in Paris
#:O)
~Jürgen
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-.
Hello,
I would really like to be there this year I just have to
organize myself. Probably any of the dates will be 3 for
me.
So put me there with 3 on all and I try to orgnize myself
to be able to partecipate.
I see forward to see you all again!!!
Cheers,
Jürgen
Lars Gullik Bjønnes wrote:
A
Angus Leeming wrote:
Juergen Vigna wrote:
The same for me!
Regards,
Jürgen
Wooo! Jürgen! It's good to see a message from you! How's life in Italy?
Very busy! #:O)
Anyway I follow the mailinglist by reading "Subjects", but I don't find
more time than this
The same for me!
Regards,
Jürgen
Asger Alstrup wrote:
I grant permission to license any and all contributions I've made to LyX
under any open source license.
Regards,
Asger
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL
Hello boys,
I still follow *very quiet* the lyx-devel list ;)
I would *really* also like to come, but as you know I'm very
committed especially in summer and as this year we have taken
over the Pool with Bar/Restaurant it's worse then before.
I see forward to another year when we can organize the m
Angus Leeming wrote:
Good to hear from you Jürgen.
:)
Well I still read the mailing list (not all most mails I only
read the subject ;) and I regularly build lyx on my pc to see
what you're all doing :P
Attached is a little wrapper script that I use. Use it so:
$ ./configure-14x $LYX_DIR xforms qt
Hello Folk,
it seems that I didn't follow enough the lyx list as I'm not anymore
able to configure LyX now. Could somebody explain me what options I
HAVE to use in the configure command?
How do I now compile the different frontends? When I do a --help
it seems that --with-frontend does not anymore
John Levon wrote:
On Tue, Jul 22, 2003 at 05:38:40PM +0200, Andre Poenitz wrote:
What could go wrong after applying the following?
Mouse cursor positioning would be the obvious thing to try. But, it's
already quite broken in current CVS ...
And fixing mouse press positioning problems is even le
Andre Poenitz wrote:
What could go wrong after applying the following?
The cursor x position is probably wrong (inset inside inset).
Greets,
Jürgen
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Mitterstrich 151
Andre Poenitz wrote:
This is arguably a step back on the path to 'multiple BufferView' as
now there's just a single 'active' BufferView again (complete rebreak when
changing BufferViews), but the current 'solution' contained (among others)
- bool clear = false;
- if (!lt) {
-
Andre Poenitz wrote:
But the contained InsetTexts do, so I am not spanking 'slow InsetTabular as
created by Juergen' but 'InsetTabular as container of lots InsetTexts'
[Although I'd think that there is some unnecessary fat in InsetTabular,
too...]
You may have a point here, althought I don't know
Andre Poenitz wrote:
This 'when needed' is basically the time between first and second drawing
phase. We need the rebreak to figure out the height of the InsetText,
so it is needed in the metrics() phase. And once we've done it there there
is no reason not to save the results up to the next draw()
José Matos wrote:
Probably you meant "raw" pointers, no?
No I meant (raw) "row" pointer
In this subject "row" pointers will probably mean something else. Also I
would not have pointed if it wasn't friday...
Did you joke?
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-
John Levon wrote:
Can somebody give me a brief summary of how/why this works ?
Especially, why can't we "reinitLyXText" when lt is non-null ?
Because it might be we are working on "Row" pointers which would
disapear or be invalidated by the reinit, don't you think so?
Jug
--
-._-._-._-.
Andre Poenitz wrote:
So why do we see several updates per redraw?
Why does an inset communicate explicitly with its parent?
I think discussing helps thinking ;)
The problem we have is that we do "updating" of the text in "rows".
so if the "inset" is embedded in a row and it changes it may be that
John Levon wrote:
Why is it the wrong spot ? Can you explain in simple terms ?
I explained below, the x position is changing during draw and if that
happens we have to "recalculate all"!
Dude, I spent *hours* doing this, and could not see where or why it
didn't work. This is lots of printfs in vari
John Levon wrote:
Well, can you explain why calling insettext->update(reinit == true)
inside the insetminipage thing doesn't work ? That's alll I want to know
and after about 50 printf's, I'm still stuck.
Because you do it at the wrong spot! Try to "printf x()" and then after
it drawed it wrong (or
John Levon wrote:
Well, I think I follow you a bit better now. In fact, that is what I am
trying to do ! Basically make sure all inset updates have been done by
the time we actually call draw. But it is beyond my ken (I cannot even
get one small part of this to work, in fact).
As I told you in my
John Levon wrote:
On Thu, Mar 20, 2003 at 09:02:56AM +0100, Juergen Vigna wrote:
But we do this already we calculate all the matrices for drawing and
in the draw function we (most of the time) do just drawing and that
is pretty fast!) or what do you think do we use the "LyXText"
Andre Poenitz wrote:
And I still do not believe that this makes a big difference.
Well this is up to you
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050 SteineggWeb: htt
Andre Poenitz wrote:
Look at what mathed does: At a very high level (i.e InsetFormula::draw) the
work is split. The first call to width() calls metrics() [ok, this is
messy, but currently the easiest way to make sure that metrics() is called
after loading of a buffer, too]. Afterwards, the real dr
John Levon wrote:
This is a more recent version, that also fixes bug 966. We were not
checking for size(text) < size(button) in the ERT draw. This was fixed
by merging the duplicated code.
IMO this should be pretty safe to apply.
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-
John Levon wrote:
This fixes a long-standing bug, for some reason (namely, switch from
closed to inlined did not correctly recalculate the width), but does not
fix an *existing* bug that is new to 1.4.0cvs (bug 965). Jug, if you're
listening: why doesn't the insettext->update() correctly deal with
John Levon wrote:
HA ! That's a bloody joke. This doesn't work. I have absolutely no idea
why, of course. This update stuff is entirely beyond understanding. Just
dealing with the bv->updateInset() vs. bv->update() vs. bv->update(blah)
vs. inset->update() vs. inset->updateInsetInInset() vs lyxtext-
John Levon wrote:
Juergen, can you help ? What would you say if I suggest ripping the font
paramter from inset->update ?
I would say this could be a good idea. Just define a "default" font
for an empty CellInset and pass that one instead. IMO this is the best
solution and you're able to rip out the
Andre Poenitz wrote:
So what about the two-stage drawing?
Give the insets a small cache of width/ascent/descent (you could steal from
math_diminset I suppose), fill the cache of an inset in the first stage
according to the size of the contents of the inset, and do all the drawing
in the second sta
I don't really read all of the mails arriving right now (there is just
too much traffic), but I overscan all of them fast.
Now I'm a bit worried about the actual state of the lyx developement
are you all sure we will not end up as in the "old" development tree?
I hope you try to hold on yourself an
John Levon wrote:
[snip]
Perhaps you're referring to insettext/tabular specific code that
decides which cells needs updating ? But that's not related to
redrawings really, it's more a matter of rebreaking etc. (and it's
broken in several circumstances)
Yes John you are right and I see you're on th
Andre Poenitz wrote:
Would that mean (almost) no effort is spent to "be clever" in this case?
I don't understand your question here?
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050
John Levon wrote:
This just sounds like bugs to me, and several redraws (did you know each
character press sends redraws twice even in a normal par ?) is not the
correct solution. Do you mean cursor droppings ?
There are a lot of different situations when we have "wrong redraws" if
we don't do the
Andre Poenitz wrote:
Face it: Full redraw _is_ faster. This might have changed over time,
though, but it is the current state.
Well this is easy enough to try just forget about the "inteligent"
redraw and set the update always to "NEED_FULL_REDRAW" and you'll
see the difference.
Jug
--
Andre Poenitz wrote:
On Tue, Mar 18, 2003 at 11:52:32AM +0100, Juergen Vigna wrote:
PS: Cut&Paste&press C-M on this to create the math tabular.
$\begin{tabular}{}
\\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\
\end{tabular}$
??? I would like to try th
Lars Gullik Bjønnes wrote:
Who are "we"? the inset? The inset should know nothing about any
lyxtext at all, the same way a Paragraph today knows nothing about any
lyxtext.
Well "we" is the inset. And yes this is a good idea and quite easy IMO
we just have to remove the "DRAW" functionality from th
Lars Gullik Bjønnes wrote:
Keep the enclosed LyXText somehwere else, so that parts of the
paragraph structure could be modified at will, without having to thing
about anything else.
I don't really understand how you would do that and how that would
facilitate the process, I understand however that
John Levon wrote:
This looks to be very silly indeed, so I guess I'm missing something.
Why are we calling update(text) directly several times for one "lfun" ?
Can we not just post the update, and then call it *once* at the end of
handling the lfun (and at the end of handleKeypress and a couple of
Lars Gullik Bjønnes wrote:
Juergen Vigna <[EMAIL PROTECTED]> writes:
| Alfredo Braunstein wrote:
| > It doesn't. You need 1 _top_ lyxtext for every bv (and there is already).
| > Then you have also a lyxtext in every children insettext... I'm talking
| > about th
Alfredo Braunstein wrote:
It doesn't. You need 1 _top_ lyxtext for every bv (and there is already).
Then you have also a lyxtext in every children insettext... I'm talking
about these, mostly. Or else I am confusing something ;)
InsetText already has support for multiple BufferViews (while other
pa
Alfredo Braunstein wrote:
Lars Gullik Bjønnes wrote:
I have a patch ready (that seems to work) that does 99.9% of these
changes.
How the multiple bv will be adressed (or is it already in the patch?)
- by having a cont bv member in lyxtext (i.e different bv for different
buffers)
- by resetting
Andre Poenitz wrote:
This would make Sep 27 a good target, closely followed by Sep 20 and July
26. The next bunch is July 19, and Sep 6.
IMO Sep 27 would be a perfect date ;)
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [E
Andre Poenitz wrote:
On Mon, Mar 10, 2003 at 08:38:07AM +, Angus Leeming wrote:
Have you checked math?
No. I just assumed that you did the tight thing already ;-)
Juergen explained to me how edit() works and how it should work already
twice or so. Then I took another beer, and watched him f
Andre Poenitz wrote:
The hierarchy should be something like
LyXFunc
|
BufferView
|
Buffer
|
OutermostText [And this should go if everything is an inset]
|
Insets
and we should walk it bottom-up. Currently we have some strange combination
of guessing jumps down (
Andre Poenitz wrote:
I am starting to believe that all insets should cache a bufferview or some
"context" after e.g. draw() is called ...
The problem with this is that the BufferView is sometimes redone and
you point to a non valid pointer (the problems we had especially in
the beginning with In
Andre Poenitz wrote:
Folks, I have been asking well in advance, and there was _noone_ opposing
that date.
Well I always told you I most probably cannot attend in May/June!
Sep20 [3]
Sep27 [4]
Ciao,
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-
Lars Gullik Bjønnes wrote:
| Btw: What about your plans for June, Juergen?
He is comming to the developers meeting of course!
#:O) well I will tell you in time. You see I will have family
bussiness at the end of May and I'm not sure I can make it this
year. But we'll see later this year ;)
Andre Poenitz wrote:
On Fri, Feb 07, 2003 at 09:52:12PM +0100, Daniel Naber wrote:
I'd like to use some Qt classes in text.C - just for trying some things
out.
Which Qt classes?
And what would the benefit of using Qt classes in the LyX core be?
I don't think we would like such a change as
Garst R. Reese wrote:
I have some ascii tab separated tables of 150-200 rows.
The table thing limits to 50.
Is there a way to handle this (splitting imported tables over several
pages) ?
Alt-x tabular-insert 200 20
should work.
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-.
Dear Joachim!
Sorry for my late reply but I marked your message todo and the forgot.
Right now I've seen it again and here is my answer.
j.heidemeier wrote:
Dear Juergen,
Well, now I'm having some time to come back to the caption / longtables
thread from November. I finally found a kludge to ge
Hi!
I would have a request, would it be possible to have a backup
of the bugzilla installation with it's data? Or how can I have
offline reading of the buglists in another way? Anyway IMO that
it would be quite good to have a downloadable backup installed
somewhere so that if the server is out for
ChangeLog
--- src/insets/ChangeLog6 Jan 2003 14:02:23 - 1.549
+++ src/insets/ChangeLog7 Jan 2003 16:19:41 -
@@ -1,3 +1,8 @@
+2002-12-17 Juergen Vigna <[EMAIL PROTECTED]>
+
+ * insettext.C (localDispatch): hopefully fixed cursor up down
+ movem
John Levon wrote:
I mean that if you can't fix the bug you shouldn't label the fix a bad
idea.
But it is a bad idea in my opinion (the fix in general I mean not the
particular code lines), anyway I just want to have the lines there so
that I don't have to download an earlier version to see how t
John Levon wrote:
On Fri, Dec 20, 2002 at 09:58:08AM +0100, Juergen Vigna wrote:
Well I don't think this patch is a good idea and if we insert it that
way I at least want a #warning there and I would like to have the old
code there #if 0 out as the existing code should be the right on an
Andre Poenitz wrote:
On Fri, Dec 20, 2002 at 01:26:02AM +, John Levon wrote:
This works OK for me. Note it fixes only one mode of failure - several
other cases are still broken. But those are not regressions, this is.
OK ?
Looks ok.
Well I don't think this patch is a good idea and if w
Angus Leeming wrote:
We also asked what were the problems you were having with upgrading and you
never answered... xforms claims to be api-compatible, so if you have a
problem it should be fixed. That's hard to do without info...
I don't think it's an xforms problem (althought you cannot compi
Lars Gullik Bjønnes wrote:
I thought you switched to xforms 1.0 now?
Nope and I don't have the time right now to get a new version for
my mailer program and recompile and test it to be able to use it
with xforms 1.0 (if yet supported by it). I told you so earlier you
didn't believe me ;)
Andre Poenitz wrote:
On Tue, Dec 17, 2002 at 09:27:12AM +0100, Juergen Vigna wrote:
Well I take it xforms 0.88 is no longer supported, is it?
Since yesterday or so.
Well then someone else has to test the 2 patches of Alfredo on
xforms :(
Jug
Well I take it xforms 0.88 is no longer supported, is it?
I just tried to recompile lyx and it gives me xforms errors about
unknown functions.
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Mitterstrich 1
John Levon wrote:
Ping me again just after 1.4.0cvs opens and I'll apply it.
Did you look at the patch? I think this will surely not introduce
any bugs I would opt to include it now (just my opininon).
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jür
John Levon wrote:
It would be great if people could give this a go. It Works For Me.
I did not yet look at the patch, but I have a question. Are you talking
about having the menues and translated strings displayed good or are
you talking about writing texts in other languages? If the first your
I will commit this 2 patches soon. Just one comment next time please
include the ChangeLog entries I did it this time this is a pro as then
they will contain you name and not mine ;)
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-M
Alfredo Braunstein wrote:
John Levon wrote:
On Thu, Dec 12, 2002 at 06:59:42PM +0200, Dekel Tsur wrote:
Yes, the problem is only with cursor down.
I careated a bug for this. Thankfully, it's not a 1.3 regression
After some disentangling, I think I've found the reason (insetext not
ret
Lars Gullik Bjønnes wrote:
Juergen Vigna <[EMAIL PROTECTED]> writes:
| only 1.0 version of xforms (then I will have the time to use only qt
| version of LyX as I need 0.88 version of xforms still for some other old
| programs.
For compiling them, or running them?
For compilin
Angus Leeming wrote:
Agreed. Lars is suggesting setting up an entirely separate tree. I anticipate
having #ifdefs in LyX's xforms frontend for the foreseeable future.
Having said that, did we come to a consensual view on what version of xforms
to support in LyX 1.3? I'd prefer to throw out both
Michael Schmitt wrote:
Hello,
I think I have finally found a tabular bug that is easily reproducible
and - hopefully - easy to debug. (And I hope all known tabular problems
are related to each other. )
- Open file "tableerror.lyx";
- for i = 1 to 25:
- move cursor down to the i-th cell/row
Lars Gullik Bjønnes wrote:
Then allow 2.56 too in the autogen script.
It is nice that we allow only autoconf version that we know work
there.
Well yes the problem is that I don't know if autconf 2.56 does need
automake 1.6. Do you know more than me about that?
Jug
--
-._-._-._-._-._
Jean-Marc Lasgouttes wrote:
"Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
Juergen> I installed automake 1.6 and had to upgrade also to autoconf
Juergen> 2.56, now autogen.sh tells me that autoconf 2.56 is not
Juergen> supported by LyX, are we serious about th
I installed automake 1.6 and had to upgrade also to autoconf 2.56,
now autogen.sh tells me that autoconf 2.56 is not supported by LyX,
are we serious about that?
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTE
Andre Poenitz wrote:
On Thu, Dec 12, 2002 at 10:01:03AM +0100, Alfredo Braunstein wrote:
I mean the paragraph where the formula is. Rephrasing it, I would expect the
same behaviour if the cursor if just before or after a math inset than if
its inside. Does it makes sense?
A bit, but all I ca
Lars Gullik Bjønnes wrote:
With letter you have to use the template... without you are doomed to
miss required layouts and their order...
IMO this could be a real enhancement for LyX, some sort of order of
layout tags and also to be able to define a Layout which has to
be inserted in the final
Jean-Marc Lasgouttes wrote:
So what was the final decision on this? I think we should get rid of
0.88 now, since it is the most problematic. Note however that this
will cause problems for people who use solaris and for cjk-lyx,
because of shortcomings ion xforms support for input methods. But thi
Moritz Moeller-Herrmann wrote:
Hmm, life would become easier for lyx and other projects, if lyx used
standard sizes. Also most if not all of the KDE icons are available as SVG,
so you could just rerender them for the lyx size.
Hmm if you tell us the rule for "standard" size? As much as I know
Alain Castera wrote:
[snip]
Unless somebody points me to a better method, I will go on this way as it
seems to me that it is the simplest way to obtain wysiwym display of fixed
width columns in a tabular. When it will be possible to test it, it will
still be time to discard everything ;-)
I read
Alain Castera wrote:
Investigating further on how to display these settings, I am now in
trouble and need your advice :
Tabular is now a case (but not the only one) where the alignment may be
given by the "context" (e.g. the owner of the text inset, or the layout
...). In such case, it is impossi
Darren Freeman wrote:
One more thing.
Load a file. Click File->Save As
You guessed it. *BOOM*
Seems like saving to a new disc file is what kills it, except for some
reason when you created a new one by invoking lyx with the filename.
Whoever knows why this is, please help! Too many segfaults a
Juergen Spitzmueller wrote:
I wonder if the attached patch fixes a lot of cut'n'paste bugs.
If not, I do not understand the longtabular stuff at all.
Please have a look.
Well it's a bit hard to read but it seems this are cut&paste bugs
fixed. Seems pretty safe to me to apply and you surely test
John Levon wrote:
People with these problems need to find EVERY failing case and add it
into the table.
Well I think in first place we have to investigate WHY it doesn't work
for some people. As I told you it works for me with qt3.
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-
Alain Castera wrote:
I am this bad boy, I guess.
Yes I still remembered it was an .fr but I couldn't remember the name ;)
But I am not guilty for that : Earlier, the alignment menu in tabular
proposed Left, Center and Right only, the default being left. As I
promised to implemented "fixed widt
John Levon wrote:
On Thu, Nov 21, 2002 at 04:33:32PM +0100, Juergen Vigna wrote:
Well but you have to try this patch as you told us it is buggy, won't
you? I can only test and confirm or not confirm the claims, but you said
it reintroduces a bug so you would have to explain us that.
He
John Levon wrote:
I wouldn't know how to try it. It took me long enough to work out how
to get my keyboard to compose umlauts :( I'm really really lame with
this stuff
Well but you have to try this patch as you told us it is buggy, won't
you? I can only test and confirm or not confirm the claim
Dekel Tsur wrote:
Block alignment is the default, so you don't need to write anything.
Namely, the column specifier is e.g. p{4cm}
For other alignments, you need to write >{\centering}p{4cm}
Oh I understand now. This is due to the patch written by ???
(fill name here) which I said I didn't like
Herbert Voss wrote:
I know that #:O), but not all hosts have a decent installation of
latin15 fonts yet I have a quite recent RedHat 7.3 (with all updates)
and also there are problems with latin15, so that I think we should
leave default latin1 fonts until we can make sure that latin15 is
supporte
Herbert Voss wrote:
it is the setting to get the Euro symbol work
I know that #:O), but not all hosts have a decent installation of
latin15 fonts yet I have a quite recent RedHat 7.3 (with all updates)
and also there are problems with latin15, so that I think we should
leave default latin1 fonts
Herbert Voss wrote:
-german german "German" false iso8859-1 de ""
-ngerman ngerman "German (new spelling)" false iso8859-1 de ""
+german german "German" false iso8859-15 de ""
+ngerman ngerman "German (new spelling)" false iso8859-15 de ""
Hello Herbert!
What I don't like
Dekel Tsur wrote:
Currently, when creating a fixed width column n a tabular,
the possible alignments are left, right and center.
It is not possible to have block alignment.
The following patch fixes that. OK to apply ?
What I miss here is the LaTeX output for the BLOCK alignment, I
don't see it
This patch should fix the lookup when a tabular cannot scroll to the
right location. This might have the effect that we're not always displaying
what we really want (but this is to be demonstarted), but surely that
is better then having a endless loop inside LyX.
Jürgen
P.S.: This shoul
John Levon wrote:
If there are bugs that should be on this list but aren't, tell me.
infinite loop trying to search
http://bugzilla.lyx.org/show_bug.cgi?id=615
page down for large tables broken
http://bugzilla.lyx.org/show_bug.cgi?id=618
- need guru help
I don't think this is easy to fix. We
Andre Poenitz wrote:
This saves a few chars.
Ok to apply?
I like the old way more, but it surely seems correct.
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050 SteineggWe
Dekel Tsur wrote:
On Fri, Nov 08, 2002 at 03:51:03PM +, [EMAIL PROTECTED] wrote:
Log message:
Backed out a change of my last patch which I now see is not correct. This
should fix the undo bugs we see.
This should also be done for 1.2.2.
Is it OK to apply this patch ?
Yes please do so
j.heidemeier wrote:
o.k. - you are the developper.
Well yes but I won't have the time to implement this :(
But reffering to your last mail your solution for the optional argument is
not clear to me. If we interpret the first word of a caption in a cell as
optional argument, how do we omit it
j.heidemeier wrote:
Hello Juergen,
tnx for the quick reply.
#:O)
In principle yes (thats the way I made it in my report) but as longtable only
have a footer and lastfooter and no firstfooter tag you have the problems
with the list of tables (multiple entries in the lot or wrong pagenumbers).
Hello Joachim!
Let me summarize what I understood from your mail:
We can have a caption for longtables in the firstHeader and a different
one in a normal Header (or if I ommit the FirstHeader then the other one
is valid for all of them).
Question: Is it possible to have a Footer-Caption?
I don'
John Levon wrote:
On Thu, Oct 31, 2002 at 04:47:19PM +0100, Jean-Marc Lasgouttes wrote:
Now, _this_ is a problem... I hope lars can transfer it to the new
aussie.
Michael described it as "hell" to set up too.
To start we just need the tarball from Michael, should be no
problem to set it up
1 - 100 of 2676 matches
Mail list logo
