Re: eps preview problems in 1.2pre1
On Thursday 04 April 2002 7:00 pm, Mike Ressler wrote: On Thu, 4 Apr 2002, Ulrich [iso-8859-15] Günther wrote: Eps figures cannot be shown in 1.2pre1. Every single figure creates an alert once I get on the page with the figure. Afterwards the figs show 'error converting to loadable format'. I am using SuSE 7.3 but not the ghostscript that comes with the distribution, but rather ghostscript-7.04-1 with ghostscript-fonts-6.0-2. This smells like the bad Imagemagick convert problem to me. In your preferences, try the following for the EPS-XPM converter: convert EPS:$$i PPM:$$i.ppm ; ppmtoxpm $$i.ppm $$o It uses Imagemagick convert to go from EPS to PPM, then the netpbm tools to go from PPM to XPM. Some versions of convert (like mine in Mandrake 8.0) produce bad XPM files. Mike Note also that if your xforms library is new enough (0.89.x, x= about 5), then your config.h file in the src directory will have #define HAVE_FLIMAGE_DUP 1 #define HAVE_FLIMAGE_ENABLE_PS 1 #define HAVE_FLIMAGE_TO_PIXMAP 1 In which case, you'll be using the image loading routines that come with xforms rather than the crappy hack I wrote! In which case, you don't need to convert to XPM at all; just stop at PPM (and delete all those converters to XPM!) Moreover, if you run lyx -dbg graphics, you'll discover that you can load many formats natively and don't need converters at all. Not EPS though. Angus
Re: WYSIWYM and line spacing
On 05-Apr-2002 Herbert Voss wrote: this is a kind of overhead! for three words I start a search in a database ... I never used Bibtex so this question may seem stupid, but what if the entry changed in the bibtex file (if that is possible), you would give a wrong information, wouldn't you? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ In matters of principle, stand like a rock; in matters of taste, swim with the current. -- Thomas Jefferson
Re: Graphics bug: Error with bounding box y-coordinate in LyX View
On Friday 05 April 2002 1:41 am, R. Lahaye wrote: Hi, I saw a long thread on this subject. Downloading CVS in the meantime, has still a wrong use of Top right y-coordinate for LyX View. (The Top right y-coordinate is somehow also used as the Bottom left y-coordinate). For final LaTeX output (DVI or Postscript) these y-coordinates are used correctly! The values of the (X,Y)-coordinates for Bottom left have equal effect for both LyX View and LaTeX View. However, the value of Top right x-coordinate cuts off different slabs for LyX and for LaTeX! Rob. PS: use clip to bounding box to see these effects. Rob, using today's cvs (as of two minutes ago) all works perfectly as far as I'm concerned. I attach small screenshots of the LyX and LaTeX views to prove it. Now I'm using the xforms image loading routines that come with modern xforms. I seem to remember that you are using a BSD box with xforms 0.88? In which case, you're using the crappy loading routines I wrote myself. I have no time today to investigate in depth, but it's always possible that my clipping routine is broken ;-) Nonetheless, why don't you upgrade your xforms library to the new open source version that came out the other day? Regards, Angus lyxview.png Description: PNG image latexview.png Description: PNG image
Re: Graphics bug: Error with bounding box y-coordinate in LyX View
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: | Lars At least with Gcc 3.1 the difference is not great. | Thanks for doing it. I could not find the time yesterday. The | difference is still great with gcc 2.9x. And gcc 3.1 is not released | yet :) I haven't gcc 3.0 installed anymore, but that is also pretty good, but 3.1. is a lot better. And this will most likely continue. gcc will get better and better and we cannot reap the full benefits since we stay with lyxstring... | I think that lyxstring is really better for our needs than | std::string. The fact that STL authors try to force us to use | std::string is a different matter :) Because of the asserts? | Hmm, I'll have to think again about this stringstream port, since it | would make the code much less painful. but only for stringstream, what about all other api's that use std::string? -- Lgb
CJK-LyX-1.2.0pre1
Hello, I have uploaded CJK-LyX-1.2.0pre1, a patched version of lyx for Chinese, Japanese and Korean users, at the usual ftp site, ftp://stone.phys.pusan.ac.kr/pub/CJK-LyX . Be aware that to compile with the patch file, you have to start with ./autogen.sh. I also wish to warn the users of this version that there is a very annoying bug which I have been unable to remove. Namely, in the inset environment such as table or footnote, the cursor for local input method does not move with the local character input, so that input hebaviour does not look like on the spot, but over the spot in the inset environment. I am open to any suggestion, idea or even a solution !!! Mr. Jurgen Vigna ? -cghan
RE: CJK-LyX-1.2.0pre1
On 05-Apr-2002 [EMAIL PROTECTED] wrote: I also wish to warn the users of this version that there is a very annoying bug which I have been unable to remove. Namely, in the inset environment such as table or footnote, the cursor for local input method does not move with the local character input, so that input hebaviour does not look like on the spot, but over the spot in the inset environment. I am open to any suggestion, idea or even a solution !!! Mr. Jurgen Vigna ? Hi! I don't really understand what problem you have could you please explain it another time. What do you mean with over the spot? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ meeting, n.: An assembly of people coming together to decide what person or department not represented in the room must solve a problem.
Re: Graphics bug: Error with bounding box y-coordinate in LyX View
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars I haven't gcc 3.0 installed anymore, but that is also pretty Lars good, but 3.1. is a lot better. And this will most likely Lars continue. Hmm, what I see is mostly higher compile times and higher disk footprint for the same program. So it is a bit more complicated than just 'improving'. Lars gcc will get better and better and we cannot reap the full Lars benefits since we stay with lyxstring... I do not say we have to keep lyxstring forever. But it is a good stopgap for the stupidity of current C++ compilers (or of the standard, I don't know). Lars | I think that lyxstring is really better for our needs than | Lars std::string. The fact that STL authors try to force us to use | Lars std::string is a different matter :) Lars Because of the asserts? Yes, in part. Having control over this is good. And the compile time factor is pretty important too on my p2-366/128M laptop I use here (of course, it is less annoying on my p4-1.7G at home...). Lars | Hmm, I'll have to think again about this stringstream port, Lars since it | would make the code much less painful. Lars but only for stringstream, what about all other api's that use Lars std::string? There are not so many of them, actually. ifstream/ofstream constructors, and ??? JMarc
Re: New README for the po files
adrien == adrien rebollo [EMAIL PROTECTED] writes: adrien Done. I just added one comment to make clear make XX.pox does adrien the same thing as msgmerge, for translators used to the old adrien way. Applied. Thanks. JMarc
Re: Insert-List badly translatable
On Thu, Apr 04, 2002 at 04:42:07PM +0200, Jean-Marc Lasgouttes wrote: Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars The problem here is that the number of float types are dynamic, Lars so currently a floatname + ' List' is done. I see that this Lars needs changing to enable better translations, but do not expect Lars that to happen for 1.2.0. Jean-Marc I think that the string 'list of something' should be part Jean-Marc of the float definition. This is easy and should solve all Jean-Marc problems. Jean-Marc And 'Wide Figure' could be replaced with 'Figure (wide)', Jean-Marc which should accomodate all languages. I did both. Adrien, could you confirm that things did improve? Yes, they did. However if you have only one adjective (wide) some languages will have problems with eg Algorithm being masculine and Figure being feminine if they have no gender invariable translation for wide (like Spanish I think). But in French large can do the trick so I'll stop complaining... Adrien Rebollo
Re: Graphics bug: Error with bounding box y-coordinate in LyX View
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | Lars but only for stringstream, what about all other api's that use | Lars std::string? | There are not so many of them, actually. ifstream/ofstream | constructors, and ??? Most boost libs and other libs. -- Lgb
Re: Graphics bug: Error with bounding box y-coordinate in LyX Vi
On 05-Apr-2002 Jean-Marc Lasgouttes wrote: Yes, in part. Having control over this is good. And the compile time factor is pretty important too on my p2-366/128M laptop I use here (of course, it is less annoying on my p4-1.7G at home...). Well to tell you the truth I gave up working at home on lyx. It takes too long to compile the sources on my P3-450/256M. When I have 1 hour of time to do something, cvs update make takes 40 minutes well and on the 20 mins left I have time to open 2 source files! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ I sometimes think that God, in creating man, somewhat overestimated his ability. -- Oscar Wilde
Re: WYSIWYM and line spacing
Juergen Vigna wrote: On 05-Apr-2002 Herbert Voss wrote: this is a kind of overhead! for three words I start a search in a database ... I never used Bibtex so this question may seem stupid, but what if the entry changed in the bibtex file (if that is possible), you would give a wrong information, wouldn't you? it's the same behaviour when editing a graphic file Herbert -- http://www.lyx.org/help/
std::string
| I think that lyxstring is really better for our needs than | std::string. The fact that STL authors try to force us to use | std::string is a different matter :) Because of the asserts? How about using a std::string wrapper which contains the needed asserts? I'm thinking of inheriting a wrapper from std::string and import that in the global namespace rather than std::string. This way, LyX will always be using the assert-improved string, while there will be no problems interacting with anything, since anything that expects a std::string will get just that. This does have the drawback that the asserts will not function while the string is being handled by third party code. I don't know how important that is to you.
Re: Graphics bug: Error with bounding box y-coordinate in LyX Vi
Juergen Vigna [EMAIL PROTECTED] writes: | On 05-Apr-2002 Jean-Marc Lasgouttes wrote: Yes, in part. Having control over this is good. And the compile time factor is pretty important too on my p2-366/128M laptop I use here (of course, it is less annoying on my p4-1.7G at home...). | Well to tell you the truth I gave up working at home on lyx. It takes too | long to compile the sources on my P3-450/256M. When I have 1 hour of time | to do something, cvs update make takes 40 minutes well and on the 20 mins | left I have time to open 2 source files! This is a result of us having too large classes and too large include files. This then results in too much needing a recompile almost always... -- Lgb
Re: CJK-LyX-1.2.0pre1
On Fri, Apr 05, 2002 at 12:03:41PM +0200, Juergen Vigna wrote: I also wish to warn the users of this version that there is a very annoying bug which I have been unable to remove. Namely, in the inset environment such as table or footnote, the cursor for local input method does not move with the local character input, so that input hebaviour does not look like on the spot, but over the spot in the inset environment. I am open to any suggestion, idea or even a solution !!! Mr. Jurgen Vigna ? Hi! I don't really understand what problem you have could you please explain it another time. What do you mean with over the spot? Probably this : http://bugzilla.lyx.org/show_bug.cgi?id=312 john -- I never understood what's so hard about picking a unique first and last name - and not going beyond the 6 character limit. - Toon Moene
Re: Graphics bug: Error with bounding box y-coordinate in LyX View
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | Lars Lars but only for stringstream, what about all other api's that use | Lars Lars std::string? Lars | There are not so many of them, actually. ifstream/ofstream | Lars constructors, and ??? Lars Most boost libs and other libs. Are these things we really want to use? But I understand your point. JMarc
Re: Graphics bug: Error with bounding box y-coordinate in LyX Vi
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Juergen Vigna [EMAIL PROTECTED] writes: Lars | On 05-Apr-2002 Jean-Marc Lasgouttes wrote: Yes, in part. Having control over this is good. And the compile time factor is pretty important too on my p2-366/128M laptop I use here (of course, it is less annoying on my p4-1.7G at home...). Lars | Well to tell you the truth I gave up working at home on lyx. Lars It takes too | long to compile the sources on my P3-450/256M. Lars When I have 1 hour of time | to do something, cvs update make Lars takes 40 minutes well and on the 20 mins | left I have time to Lars open 2 source files! Lars This is a result of us having too large classes and too large Lars include files. This then results in too much needing a recompile Lars almost always... And do you really think there is a possiblity to really lower these times (knowing that bloat will have a positive drift in the same timeframe)? JMarc
Re: std::string
| How about using a std::string wrapper which contains the needed asserts? | I'm thinking of inheriting a wrapper from std::string and import that in the | global namespace rather than std::string. This way, LyX will always be using | the assert-improved string, while there will be no problems interacting with | anything, since anything that expects a std::string will get just that. This | does have the drawback that the asserts will not function while the string | is being handled by third party code. I don't know how important that is to | you. Inheriting will mostlikely not work well, wrapping might work, Mind telling me why? however you need std::string to be in namespace std for this to work and not all C++ libs do that yet. it could still be done with a typedef, though the other solution is imho more elegant.
Re: Insert-List badly translatable
adrien == adrien rebollo [EMAIL PROTECTED] writes: adrien Yes, they did. However if you have only one adjective (wide) adrien some languages will have problems with eg Algorithm being adrien masculine and Figure being feminine if they have no gender adrien invariable translation for wide (like Spanish I think). But in adrien French large can do the trick so I'll stop complaining... I guess in this case one can translate it as if it were (wide version) or something. JMarc
ShangHai - Korea - World Cup
Hi, Ik ben vandaag bij de toeristen info in Seoul langs geweest. De enige verbinding tussen ShangHai en Korea is met Incheon. Dat is de havenstad van Seoul, ongeveer een uur met de metro naar Seoul downtown. De boot van ShangHai naar Incheon gaat twee keer per week, dinsdags en donderdags. Vertrek van beiden boten is om 10:00 's morgens en aankomst is de volgende dag: ShangHai 10:00 dinsdag - Incheon 18:30 woensdag ShangHai 10:00 donderdag - Incheon 9:00 vrijdag Ik vraag me nu af of die aankomst tijden wel kloppen, ze verschillen wel erg veel: 18:30 en 9:00 !. De prijzen (enkele reis) voor de verschillende klassen zijn als volgt: regulier (4 pers. per compartiment): 135.000 Won regulier, maar ietwat beter: 175.500 Won suite (4 pers. per compartiment) : 317.250 Won suite (2 pers. per compartiment) : 438.750 Won NB: 1150 Won = 1 Euro Mogelijk zijn de prijzen in China zelfs ietwat (of zelfs behoorlijk) lager. De laatste suites zijn zowat duurder dan vliegen! Als jullie met de boot naar Incheon komen, zal ik jullie uiteraard daar opwachten. Is deze info bruikbaar? - Er staat ontzettend veel te gebeuren in Mei en Juni. Ten dele is dat te doen gebruikelijk, maar voor een groot deel ook nieuwe evenementen ivm. de wereld beker. Een week voor Boeddha's verjaardag (19 mei) is het Lotus Lantern Festival (op 12 mei). Dit is een groots boeddhist festijn, met een lantaarn parade 's avonds. De mensen staan langs de weg met lampionen terwijl een stoet met fantastische bouwwerken van draken, olifanten e.d. langs trekken. Het lijkt wel een combinatie van lampionentocht en carnavalsoptocht in NL. Op 8 Juni is er een speciaal koninklijk ceremonie (er is geen koning meer in Korea, maar ze immiteren hoe het anno-da-zu-mal er aan toe ging). Dit is uniek, want ze voeren dit maar 3 keer op dit jaar. Het wordt in een van de klassieke paleizen in Seoul opgevoerd. 't Is ook nog gratis! Verder barst het op 1 Juni van de kultuur, dans, vuurwerk en straat- festijnen, want dan is de opening van de wereld beker. In tussentijd zijn er ook goede voorstellingen in de Koreaanse traditionele theaters, als je daar ook in geinteresseerd bent. Als jullie langskomen voor een lang genoeg periode (en jullie geen problemen hebben met mijn klein optrekje) kan het erg gezellig worden. Mijn balkon is in ieder geval zeer ruim en daar kunnen we 's avonds gezellig barbequen, eten en kletsen. Wil je zelf internetten over Korea, kijk dan o.a. op: http://www.visitseoul.net/english/ --- Oh, en voor ik het vergeet: noch voor Korea, noch voor Japan hebben jullie een visum nodig; in beiden landen kun je zonder visum tot 3 maanden verblijven. Moeten we het ook nog over de financien, want ik heb hier in Korea enkele miljoenen aan Won! Als ik verder van dienst kan zijn, dan hoor ik het wel. Tot emails, Rob.
Re: Graphics bug: Error with bounding box y-coordinate in LyX View
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: | Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | Lars | Lars but only for stringstream, what about all other api's that use | | Lars Lars std::string? | Lars | There are not so many of them, actually. ifstream/ofstream | | Lars constructors, and ??? | Lars Most boost libs and other libs. | Are these things we really want to use? But I understand your point. Yes, absolutely. -- Lgb
Re: Graphics bug: Error with bounding box y-coordinate in LyX Vi
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: | Lars Juergen Vigna [EMAIL PROTECTED] writes: | Lars | On 05-Apr-2002 Jean-Marc Lasgouttes wrote: Yes, in part. Having control over this is good. And the compile time factor is pretty important too on my p2-366/128M laptop I use here (of course, it is less annoying on my p4-1.7G at home...). | Lars | Well to tell you the truth I gave up working at home on lyx. | Lars It takes too | long to compile the sources on my P3-450/256M. | Lars When I have 1 hour of time | to do something, cvs update make | Lars takes 40 minutes well and on the 20 mins | left I have time to | Lars open 2 source files! | Lars This is a result of us having too large classes and too large | Lars include files. This then results in too much needing a recompile | Lars almost always... | And do you really think there is a possiblity to really lower these | times (knowing that bloat will have a positive drift in the same | timeframe)? Yes, I do belive so. We have a lot of bloat right now, and a lot of badly designed classes and inheritance trees. -- Lgb
Re: std::string
Bjarke Roune [EMAIL PROTECTED] writes: | How about using a std::string wrapper which contains the needed asserts? | I'm thinking of inheriting a wrapper from std::string and import that in | the | global namespace rather than std::string. This way, LyX will always be | using | the assert-improved string, while there will be no problems interacting | with | anything, since anything that expects a std::string will get just that. | This | does have the drawback that the asserts will not function while the | string | is being handled by third party code. I don't know how important that is | to | you. Inheriting will mostlikely not work well, wrapping might work, | Mind telling me why? std::string does not have a virtual destructor. It has never been inteded for inheritence. however you need std::string to be in namespace std for this to work and not all C++ libs do that yet. | it could still be done with a typedef, though the other solution is imho | more elegant. yes. -- Lgb
Re: std::string
Inheriting will mostlikely not work well, wrapping might work,
| Mind telling me why?
std::string does not have a virtual destructor. It has never been
inteded for inheritence.
I'm only thinking of doing something like this:
size_t asserter_string::size()
{
assert(...);
return string::size();
}
(besides from the fact that std::string::size() probably wouldn't need an
assert)
There would be no need to add additional member variables, so a lack of a
virtual destructor should not be a problem. A comment might be added to the
file to point this out.
RE: CJK-LyX-1.2.0pre1
On Fri, 5 Apr 2002, Juergen Vigna wrote: Hi! I don't really understand what problem you have could you please explain it another time. What do you mean with over the spot? Sorry if I was too sloppy Let me explain the situation with the attached four screen shots: 1. In the lyx main window, if I type local (multibyte) characters from the local input method, the characters appear on the screen just like the English typing(the first screen shot-lyx1.png). 2. If I type enter, then the whole local characters are now put on the same spot (screenshot 2-llyx2.png). The way characters are written in this way is called on the spot. 3.However in the footnote inset environment, if I type local characters, the characters appear outside of the environment (screenshot3-llyx3.png). Actually, the cursor for the local characters are outside the footnote box. 4. If I type enter, then the local characters outside of the footnote box are now put inside of the footnote box(screenshot4-lyx4.png). this way of inputting characters are called the over the spot. Hopefully, you've got the situation clearly, so that you may have an idea. cghan lyx1.png Description: PNG image llyx2.png Description: PNG image llyx3.png Description: PNG image lyx4.png Description: PNG image
Re: CJK-LyX-1.2.0pre1
On Fri, 5 Apr 2002, John Levon wrote: Probably this : http://bugzilla.lyx.org/show_bug.cgi?id=312 Maybe or maybe not. The bug has been there since CJK-LyX-1.1.6, when tabular environment was changed to table inset environment. cghan
RE: CJK-LyX-1.2.0pre1
On 05-Apr-2002 cghan wrote: Sorry if I was too sloppy Well you made it a lot better with this email #:O) Let me explain the situation with the attached four screen shots: 1. In the lyx main window, if I type local (multibyte) characters from the local input method, the characters appear on the screen just like the English typing(the first screen shot-lyx1.png). 2. If I type enter, then the whole local characters are now put on the same spot (screenshot 2-llyx2.png). The way characters are written in this way is called on the spot. 3.However in the footnote inset environment, if I type local characters, the characters appear outside of the environment (screenshot3-llyx3.png). Actually, the cursor for the local characters are outside the footnote box. 4. If I type enter, then the local characters outside of the footnote box are now put inside of the footnote box(screenshot4-lyx4.png). this way of inputting characters are called the over the spot. Hopefully, you've got the situation clearly, so that you may have an idea. Well I have to admit if I wouldn't understand it now I would be really dumb ;) This is typically the not handling of a LFUN inside the InsetText's localDispatch and/or the wrong handling of it in the main/loop (not considering that the cursor may be inside theLockingInset()!) You would have to tell me what LFUN is called on the first action. Is it an LFUN only available in CJK-Lyx? Just send me the relevant code pieces (LFUN and if used functions the LFUN calls and I'll fix it for you on the fly ;), but probably you can fix it too by not using bv-text and using bv-getLyXText(). Hope this helps, Jug BTW.: The fix for the #312 problem is: Index: src/insets/insettext.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insettext.C,v retrieving revision 1.280 diff -u -p -r1.280 insettext.C --- src/insets/insettext.C 3 Apr 2002 13:59:04 - 1.280 +++ src/insets/insettext.C 5 Apr 2002 12:16:09 - @@ -1190,7 +1190,7 @@ InsetText::localDispatch(BufferView * bv } } lt-selection.cursor = lt-cursor; - updwhat = CURSOR_PAR; + updwhat = CURSOR | CURSOR_PAR; updflag = true; result = DISPATCHED_NOUPDATE; break; -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ There is an old time toast which is golden for its beauty. When you ascend the hill of prosperity may you not meet a friend. -- Mark Twain
Re: WYSIWYM and line spacing
On 05-Apr-2002 Herbert Voss wrote: I never used Bibtex so this question may seem stupid, but what if the entry changed in the bibtex file (if that is possible), you would give a wrong information, wouldn't you? it's the same behaviour when editing a graphic file ??? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Women are not much, but they are the best other sex we have. -- Herold
Re: WYSIWYM and line spacing
Juergen Vigna wrote: On 05-Apr-2002 Herbert Voss wrote: I never used Bibtex so this question may seem stupid, but what if the entry changed in the bibtex file (if that is possible), you would give a wrong information, wouldn't you? it's the same behaviour when editing a graphic file ??? I can see the changes of an external object when I do anything with the inset ... Herbert -- http://www.lyx.org/help/
Re: CJK-LyX-1.2.0pre1
cghan == cghan [EMAIL PROTECTED] writes: cghan On Fri, 5 Apr 2002, John Levon wrote: Probably this : http://bugzilla.lyx.org/show_bug.cgi?id=312 cghan Maybe or maybe not. The bug has been there since CJK-LyX-1.1.6, cghan when tabular environment was changed to table inset cghan environment. I think it is a problem of using the main lyxtext instead of the one returned by BufferView::getLyXText. But John and Juergen are probably more expert on this. JMarc
Re: More eye candy
On Thu, Mar 28, 2002 at 11:09:51AM +0100, Jean-Marc Lasgouttes wrote: Don't bother with it. generating this does not cost anything. The only proble is with the various TOCS, I think (although I'd like to have hard numbers on a large file: how much does TOC generation cost?). It is not really a matter of performance, but of technical implementation. I wouldn't feel particularly happy about implementing a class derived from QPopupMenu that fills it up during an overridden show(). It might work but I don't think it's a robust technique (as it's definitely unusual, we could expect it to break with various qt versions ...) If menubackend where to cache the TOCS, using some signal, would regenerating the menus at each Menu::update() really cost too much? The time will depend on the number of headings, not number of paragraphs in document. When does Menu::update() get called exactly ? If this works with a reasonable frequency, i.e. we can avoid the update-on-menu-open behaviour, then I'm happy. regards john -- I never understood what's so hard about picking a unique first and last name - and not going beyond the 6 character limit. - Toon Moene
Re: Underfull boxes
On Fri, Mar 29, 2002 at 03:40:58AM +0300, Gady Kozma wrote: I threw together a little document which explains how to deal with under/overfull boxes in LyX, with the intention of making it part of the LyX documentations, stand alone or as a chapter of something bigger. I've added a bug on adding this to the docs here : http://bugzilla.lyx.org/show_bug.cgi?id=318 regards john -- I never understood what's so hard about picking a unique first and last name - and not going beyond the 6 character limit. - Toon Moene
[PATCH] FormGraphics
this patch changes the unit pt in FormGraphics.C to the
correct one bp (PostScript unit), also called BigPoint
Herbert
--
http://www.lyx.org/help/
Index: src/frontends/xforms/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/ChangeLog,v
retrieving revision 1.343
diff -u -r1.343 ChangeLog
--- src/frontends/xforms/ChangeLog 5 Apr 2002 09:18:26 - 1.343
+++ src/frontends/xforms/ChangeLog 5 Apr 2002 11:26:21 -
@@ -1,3 +1,8 @@
+2002-04-05 Herbert Voss [EMAIL PROTECTED]
+
+ * FormGraphics.C: use correct unit bp (big point - PostScript point)
+ for the bounding box values
+
2002-04-05 Angus Leeming [EMAIL PROTECTED]
* FormGraphics.C (updateBB, input): Don't set the path of the file
Index: src/frontends/xforms/FormGraphics.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/FormGraphics.C,v
retrieving revision 1.66
diff -u -r1.66 FormGraphics.C
--- src/frontends/xforms/FormGraphics.C 5 Apr 2002 09:18:26 - 1.66
+++ src/frontends/xforms/FormGraphics.C 5 Apr 2002 11:26:21 -
@@ -169,7 +169,7 @@
setPrehandler(bbox_-input_bb_x1);
setPrehandler(bbox_-input_bb_y1);
- string const bb_units = pt|cm|in;
+ string const bb_units = bp|cm|in;
fl_addto_choice(bbox_-choice_bb_units, bb_units.c_str());
bc().addReadOnly(bbox_-button_getBB);
bc().addReadOnly(bbox_-check_clip);
@@ -296,6 +296,7 @@
}
+
void FormGraphics::update() {
// Update dialog with details from inset
InsetGraphicsParams igp = controller().params();
@@ -453,7 +454,7 @@
fl_set_input(bbox_-input_bb_x1, bb.c_str());
fl_set_input(bbox_-input_bb_y1, bb.c_str());
}
- // pt
+ // bp
fl_set_choice(bbox_-choice_bb_units, 1);
} else {
@@ -464,16 +465,16 @@
LyXLength anyLength;
anyLength = LyXLength(token(bb_inset,' ',0));
updateWidgetsFromLength(bbox_-input_bb_x0,
- bbox_-choice_bb_units,anyLength,pt);
+ bbox_-choice_bb_units,anyLength,bp);
anyLength = LyXLength(token(bb_inset,' ',1));
updateWidgetsFromLength(bbox_-input_bb_y0,
- bbox_-choice_bb_units,anyLength,pt);
+ bbox_-choice_bb_units,anyLength,bp);
anyLength = LyXLength(token(bb_inset,' ',2));
updateWidgetsFromLength(bbox_-input_bb_x1,
- bbox_-choice_bb_units,anyLength,pt);
+ bbox_-choice_bb_units,anyLength,bp);
anyLength = LyXLength(token(bb_inset,' ',3));
updateWidgetsFromLength(bbox_-input_bb_y1,
- bbox_-choice_bb_units,anyLength,pt);
+ bbox_-choice_bb_units,anyLength,bp);
}
}
@@ -590,7 +591,7 @@
fl_set_input(bbox_-input_bb_y0, token(bb,'
',1).c_str());
fl_set_input(bbox_-input_bb_x1, token(bb,'
',2).c_str());
fl_set_input(bbox_-input_bb_y1, token(bb,'
',3).c_str());
- string const unit(pt);
+ string const unit(bp);
fl_set_choice_text(bbox_-choice_bb_units,
unit.c_str());
}
controller().bbChanged = false;
@@ -599,7 +600,7 @@
fl_set_input(bbox_-input_bb_y0, );
fl_set_input(bbox_-input_bb_x1, );
fl_set_input(bbox_-input_bb_y1, );
- fl_set_choice_text(bbox_-choice_bb_units, pt);
+ fl_set_choice_text(bbox_-choice_bb_units, bp);
}
// the size section
Re: More eye candy
John == John Levon [EMAIL PROTECTED] writes: John When does Menu::update() get called exactly ? I think it is after each lyxfunc::dispatch. However, we can tweak this behaviour to get what we (you) need. JMarc
Re: Old feature requests [was: nthiery@Icare.Mines.EDU: Various suggestions]
I don't want to file any bugs until at least a little discussion. - I am missing the following starred environments with amsmath: notation*, problem*, ... Are they non-standard ? Anybody ? - When entering emphasized text, striking right arrow at the end of the line should allow to exit the emphasized text. I wholeheartedly agree here - it has precedent, and is very useful... - Bug in the users guide: it says LyX uses \epsfig, whereas it really uses includegraphics to import figures (which is The Right Thing). It doesn't any more (say epsfig I mean). - Could the file browser for including graphics display thumbnails of the figure as, say, in the xfig file browser ? For xforms: it would be a lot of work. For Qt2: soon. - LyX support for \DeclareGraphicsExtensions ? To be able to generate both postscript and PDF documents, I have my graphics files in both .eps and .pdf format. My problem is that if I specify a graphics file without an extension bla, lyx does not find it. On the other hand, if I specify the full file name bla.eps, the compilation with pdflatex does not work. Well my bug on this in bugzilla nobody understood so I closed it ! - LyX support for \graphicspath It would be nice to have LyX support the graphicspath latex feature. Right now, LyX does not find the figure do display it in the LyX buffer. More important, the compilation fails. On the other hand, exporting as latex, and compiling by hand works. It seems to be related to the compilation in the temporary directory. Sure. - With the Format-Character menu, clicking on apply switch back and forth between the original and the modified versions. Why not. However, it's counter intuitive that clicking on OK switches back to the original ! Perhaps yeah ... - Support for the hyperref package would be cool. ... - Could LyX-Code be defined in amsmath/amsbook classes ? I don't think anyone really likes lyx-code ... - For my use of LyX as presentation tool, I need to be able to quickly scroll the text to some precise position, so as to display the precise part of the document I want, and hide the solutions of the exercises. Moving the cursor around does not work well, since it makes jumps if there are figures or big equations. Right now I use the scrollbar. I would prefer to have keyboard shortcuts (Say Ctrl-Up arrow and Ctrl-down arrow, for scrolling up or down by a fixed amount (e.g. 1cm). That would save me from looking once again foolish trying to figure out where the mouse cursor disappeared. You could use bookmarks or navigate menu ... We want to make scrolling done in terms of on-screen amounts as it fixes a number of bugs, but it's some way off really ... (at least so I'm assured) - I use many different paragraph styles, and had to define many shortcuts of them. I would find more practical to have a unique shortcut, with name completion. Example: to get to the Problem paragraph style, hit M-p PrTAB. It could be on some other shortcut than M-p, to avoid conflicts. I don't know how this would work ... Also, when using the popout paragraph style menu, PgUp and PgDown should probably also move the cursor in the visible range. xforms bug ! john -- I never understood what's so hard about picking a unique first and last name - and not going beyond the 6 character limit. - Toon Moene
layout as string bug (I think)
M-p C-a with article style - look at minibuffer Layout RightAddress not known john -- I never understood what's so hard about picking a unique first and last name - and not going beyond the 6 character limit. - Toon Moene
Re: WYSIWYM and line spacing
Allan == Allan Rae [EMAIL PROTECTED] writes: Allan I don't have a problem with the before and after sections Allan only the part you labelled natbib. I can leave with that too. Allan I have a problem with saving data that is easily regeneratable. Ditto. And also with saving data that does not exist (Caesar et al.) for a pure old numerical \cite thingie. Allan JMarc may have concerns about the before and after handling Allan but I don't. I see, you try to put words in my mouth to defend yourself... Allan As I see it: We know natbib support is turned on/off. We know Allan what \cite format the user wants. We know the key. We know the Allan bibtex file to search. Therefore, we can reconstruct the label Allan string just the same way it was generated originally. We don't Allan need to save the part you labelled natbib. There is probably a problem of having access to the right data at the right time, though. Also, the fact that most of the code is in FormCitation creates some problems that look fishy (described in one of my earlier mails on the subject). JMarc
Re: WYSIWYM and line spacing
Herbert == Herbert Voss [EMAIL PROTECTED] writes:
Herbert there are 7 different commands, for example one: the
Herbert lyx-format: \begin_inset LatexCommand
Herbert \citealp[\beforesee\end_before\afterpage
Herbert 1ff\end_after\natbibWright, 1978; Wright, 1963; Wood,
Herbert 1961]{wright-78-book,wright-63,wood-61} \end_inset
One purely cosmetic objection I have to your stuff is that, if you
are going to make things SGML-like, this should be
beforesee/beforeafterpage 1ff/afternatbibWright, 1978; Wright, 1963; Wood,
1961/natbib
Otherwise, you could use a more sensible solution.
Herbert this is a kind of overhead! for three words I start a search
Herbert in a database ...
So you are doing caching of data in the document. I do not like this
much...
Herbert and how do I know in the inset what bibtex-file I use?
This one is of course the real problem. Angus?
JMarc
Re: [PATCH] FormGraphics
Herbert Voss [EMAIL PROTECTED] writes: | this patch changes the unit pt in FormGraphics.C to the | correct one bp (PostScript unit), also called BigPoint This is obviously correct to me. Applied. -- Lgb
Re: Dialog titles not translated
On Fri, Apr 05, 2002 at 12:49:25PM +0200, [EMAIL PROTECTED] wrote: When you open a Browse dialog from some other dialogs, such as Insert-Graphics, File-Print, and Insert-ListsTOC-BibTeX. These use N_() not _() ... john -- I never understood what's so hard about picking a unique first and last name - and not going beyond the 6 character limit. - Toon Moene
Re: Old feature requests [was: nthiery@Icare.Mines.EDU: Various suggestions]
John == John Levon [EMAIL PROTECTED] writes: John I don't want to file any bugs until at least a little John discussion. - I am missing the following starred environments with amsmath: notation*, problem*, ... Are they non-standard ? John Anybody ? Pass. - When entering emphasized text, striking right arrow at the end of the line should allow to exit the emphasized text. John I wholeheartedly agree here - it has precedent, and is very John useful... I think I do not understand the suggestion. - With the Format-Character menu, clicking on apply switch back and forth between the original and the modified versions. Why not. However, it's counter intuitive that clicking on OK switches back to the original ! John Perhaps yeah ... I think this is fixed now. - Could LyX-Code be defined in amsmath/amsbook classes ? John I don't think anyone really likes lyx-code ... However, defining it in ams* should not make matters worse than they are already. - I use many different paragraph styles, and had to define many shortcuts of them. I would find more practical to have a unique shortcut, with name completion. Example: to get to the Problem paragraph style, hit M-p PrTAB. It could be on some other shortcut than M-p, to avoid conflicts. John I don't know how this would work ... We need tab completion in the layout combox. This seems doable. JMarc
Re: layout as string bug (I think)
John == John Levon [EMAIL PROTECTED] writes: John M-p C-a with article style - look at minibuffer John Layout RightAddress not known But Article does not have a RightAddress layout, does it? Probably LFUN_LAYOUT should be disabled when its argument is a layout which does not exist in the class (useful also for people who want to add layouts to toolbar or manu). We could even have a on/off state. Later. JMarc
Re: Old feature requests [was: nthiery@Icare.Mines.EDU: Various suggestions]
On Fri, Apr 05, 2002 at 04:17:29PM +0200, Jean-Marc Lasgouttes wrote: - When entering emphasized text, striking right arrow at the end of the line should allow to exit the emphasized text. John I wholeheartedly agree here - it has precedent, and is very John useful... I think I do not understand the suggestion. OK, I am typing some normal text, and switch to *emphasised*| the cursor is at the dummy pos, now pressing right will go back to non-emphasised. It's a nice thing, but it needs to be optional and it's probably painful to do ... We need tab completion in the layout combox. This seems doable. oh, ah, right. john -- I never understood what's so hard about picking a unique first and last name - and not going beyond the 6 character limit. - Toon Moene
Re: layout as string bug (I think)
On Fri, Apr 05, 2002 at 04:22:36PM +0200, Jean-Marc Lasgouttes wrote: John == John Levon [EMAIL PROTECTED] writes: John M-p C-a with article style - look at minibuffer John Layout RightAddress not known But Article does not have a RightAddress layout, does it? Probably No, it has a Right Address layout (at least it does for me :) LFUN_LAYOUT should be disabled when its argument is a layout which does not exist in the class (useful also for people who want to add layouts to toolbar or manu). We could even have a on/off state. Later. This is separate but also a bug I guess john -- I never understood what's so hard about picking a unique first and last name - and not going beyond the 6 character limit. - Toon Moene
Re: Old feature requests [was: nthiery@Icare.Mines.EDU: Various suggestions]
John == John Levon [EMAIL PROTECTED] writes: John OK, I am typing some normal text, and switch to *emphasised*| John the cursor is at the dummy pos, now pressing right will go back John to non-emphasised. It's a nice thing, but it needs to be John optional and it's probably painful to do ... I do not understand your description eiither, but the funny thing is that they seem to describe different things... JMarc
Re: layout as string bug (I think)
Jose == Jose Abilio Oliveira Matos [EMAIL PROTECTED] writes: Jose I have called code to the docbook layout that in other classes Jose is lyx-code and I would like to be able to use the same shortcut Jose to access it. Would this be possible then? No. Having same shortcut for different things is not possible currently. I am confident that it will soon, since ANdre' since excited about it, and there is not much we can do to stop him. JMarc
Re: layout as string bug (I think)
John == John Levon [EMAIL PROTECTED] writes: John On Fri, Apr 05, 2002 at 04:22:36PM +0200, Jean-Marc Lasgouttes John wrote: John == John Levon [EMAIL PROTECTED] writes: John M-p C-a with article style - look at minibuffer John Layout RightAddress not known But Article does not have a RightAddress layout, does it? Probably John No, it has a Right Address layout (at least it does for me :) Doh. Can it be that the space in Right Address confuses LFUN_LAYOUT? LFUN_LAYOUT should be disabled when its argument is a layout which does not exist in the class (useful also for people who want to add layouts to toolbar or manu). We could even have a on/off state. Later. John This is separate but also a bug I guess Indeed. JMarc
Re: layout as string bug (I think)
On Friday 05 April 2002 15:38, Jean-Marc Lasgouttes wrote: No. Having same shortcut for different things is not possible currently. I am confident that it will soon, since ANdre' since excited about it, and there is not much we can do to stop him. Ok. BTW you are lucky since André isn't here today, but you already knew this, didn't you? JMarc -- José Abílio
Re: layout as string bug (I think)
On Fri, Apr 05, 2002 at 04:39:19PM +0200, Jean-Marc Lasgouttes wrote: John No, it has a Right Address layout (at least it does for me :) Doh. Can it be that the space in Right Address confuses LFUN_LAYOUT? It's further back than that : LyXFunc::Dispatch: action[1] arg[] Found the pseudoaction: [135|RightAddress] LyXFunc::Dispatch: action[135] arg[RightAddress] BufferView::Pimpl::Dispatch: action[135] arg[RightAddress] LFUN_LAYOUT: (arg) RightAddress john -- I never understood what's so hard about picking a unique first and last name - and not going beyond the 6 character limit. - Toon Moene
RE: CJK-LyX-1.2.0pre1
On 05-Apr-2002 cghan wrote: With your suggestion, I have changed all the (bv-text) To (bv-getLyXText()). I have attached two relevent files, lyxim.C (for connection of local input method to lyx) , and lyxfunc.C ( look at the function LyXFunc::CJK_IMprocess()). Now the cursor moves with the local character but it always starts at the beginning of the lyx screen no matter where the inset environment begins. Four screenshots are attached to explain the situation. Well ok you don't consider the x/y offset of the InsetText. If you have a look at the draw() routine of InsetText you'll see that we call GetVisibleRow() with a yoffset which we calculate with our baseline. It seems that you draw the stuff directly on screen and don't let the InsetText draw it. It is a bit difficult to see what you do exactly in the whole file if you could explain me the relevant sections I'll have a look at them. I'm pretty busy with real work right now so I can help you but you have to do the dirt work ;) Greets, Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Men say of women what pleases them; women do with men what pleases them. -- DeSegur
Re: layout as string bug (I think)
John Levon [EMAIL PROTECTED] writes: | On Fri, Apr 05, 2002 at 04:22:36PM +0200, Jean-Marc Lasgouttes wrote: John == John Levon [EMAIL PROTECTED] writes: John M-p C-a with article style - look at minibuffer John Layout RightAddress not known But Article does not have a RightAddress layout, does it? Probably | No, it has a Right Address layout (at least it does for me :) LFUN_LAYOUT should be disabled when its argument is a layout which does not exist in the class (useful also for people who want to add layouts to toolbar or manu). We could even have a on/off state. Later. | This is separate but also a bug I guess a bind file bug I think... the layout is called Right_Address in the bind file. that is displayed as Right Address in the layout dropdown but RightAddress is used in some of the bind files. broadway.bind:\bind M-z r layout Right_Address de_menus.bind:\bind M-a C-a layout RightAddress fi_menus.bind:\bind M-p S-O layout RightAddress # Oikea osoite hollywood.bind:\bind M-z rlayout Right_Address menus.bind:\bind M-p C-a layout RightAddress pt_menus.bind:\bind M-p S-E layout RightAddress # endereço à direita sv_menus.bind:\bind M-p C-a layout RightAddress -- Lgb
Re: layout as string bug (I think)
John Levon [EMAIL PROTECTED] writes: | On Fri, Apr 05, 2002 at 04:39:19PM +0200, Jean-Marc Lasgouttes wrote: John No, it has a Right Address layout (at least it does for me :) Doh. Can it be that the space in Right Address confuses LFUN_LAYOUT? | It's further back than that : | LyXFunc::Dispatch: action[1] arg[] | Found the pseudoaction: [135|RightAddress] | LyXFunc::Dispatch: action[135] arg[RightAddress] | BufferView::Pimpl::Dispatch: action[135] arg[RightAddress] | LFUN_LAYOUT: (arg) RightAddress Looks correct. Please show me where RightAddress is defined. -- Lgb
Re: Dialog titles not translated
On Friday 05 April 2002 3:14 pm, John Levon wrote: On Fri, Apr 05, 2002 at 12:49:25PM +0200, [EMAIL PROTECTED] wrote: When you open a Browse dialog from some other dialogs, such as Insert-Graphics, File-Print, and Insert-ListsTOC-BibTeX. These use N_() not _() ... john But they shouldn't...
Re: Dialog titles not translated
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus On Friday 05 April 2002 3:14 pm, John Levon wrote: On Fri, Apr 05, 2002 at 12:49:25PM +0200, [EMAIL PROTECTED] wrote: When you open a Browse dialog from some other dialogs, such as Insert-Graphics, File-Print, and Insert-ListsTOC-BibTeX. These use N_() not _() ... Angus But they shouldn't... Indeed...
perhaps this patch fix the file load hang.
I have tried this patch: Index: src/text2.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text2.C,v retrieving revision 1.215 diff -u -p -r1.215 text2.C --- src/text2.C 21 Mar 2002 17:25:31 - 1.215 +++ src/text2.C 5 Apr 2002 15:22:04 - -909,7 +909,7 bool LyXText::fullRebreak(BufferView * b need_break_row = 0; return true; } - return false; + return true; } it fixes the hang when the loading a file... bugzill does not like me at the moment so I cannot find the bug number ... I think it is the blocker bug from bugzilla. I see that in most cases the return value of fullRebreak is not used, so I wonder what kind of problems will arise by having fullRebreak always return true. -- Lgb
Re: WYSIWYM and line spacing
On Friday 05 April 2002 3:11 pm, Jean-Marc Lasgouttes wrote:
Herbert == Herbert Voss [EMAIL PROTECTED] writes:
Herbert there are 7 different commands, for example one: the
Herbert lyx-format: \begin_inset LatexCommand
Herbert \citealp[\beforesee\end_before\afterpage
Herbert 1ff\end_after\natbibWright, 1978; Wright, 1963; Wood,
Herbert 1961]{wright-78-book,wright-63,wood-61} \end_inset
One purely cosmetic objection I have to your stuff is that, if you
are going to make things SGML-like, this should be
beforesee/beforeafterpage 1ff/afternatbibWright, 1978; Wright,
1963; Wood, 1961/natbib
Otherwise, you could use a more sensible solution.
Herbert this is a kind of overhead! for three words I start a search
Herbert in a database ...
So you are doing caching of data in the document. I do not like this
much...
Herbert and how do I know in the inset what bibtex-file I use?
This one is of course the real problem. Angus?
JMarc
Why blame me!
Let's try and think this through properly.
* Herbert would like a pretty citation label on the citation inset button.
* His proposed solution (writing temporary data to the LyX file) has been
vetoed for good reasons.
* He has proposed this solution because the inset cannot easily access this
info itself.
All this is fair enough, however, I'm not sure it's correct.
When the citation inset label is drawn, all the necessary info is available
to it (I think) because getScreenLabel is passed a Buffer *.
So, Herbert, in getScreenLabel you
* can access all available bibkeys (buffer-getBibkeyList()).
* know whether you're to use natbib (buffer-params.use_natbib).
* know whether you're to use numerical or author-year citations
(buffer-params.use_numerical_citations).
* must create routines equivalent to biblio::getNumericalStrings and
biblio::getAuthorYearStrings that return the pretty string you require.
Is it worth it?
Only you can decide.
Will it go in 1.2?
Only Lars can decide.
Over to you.
Angus
Re: perhaps this patch fix the file load hang.
On Fri, Apr 05, 2002 at 05:24:42PM +0200, Lars Gullik Bjønnes wrote: at the moment so I cannot find the bug number ... I think it is the blocker bug from bugzilla. bug 303 it is I see that in most cases the return value of fullRebreak is not used, so I wonder what kind of problems will arise by having fullRebreak always return true. well why not commit it and we shalle see ! john -- I never understood what's so hard about picking a unique first and last name - and not going beyond the 6 character limit. - Toon Moene
Re: Graphics bug: Error with bounding box y-coordinate in LyX View
On Friday 05 April 2002 11:35 am, Herbert Voss wrote: Angus Leeming wrote: The values of the (X,Y)-coordinates for Bottom left have equal effect for both LyX View and LaTeX View. However, the value of Top right x-coordinate cuts off different slabs for LyX and for LaTeX! PS: use clip to bounding box to see these effects. Rob, using today's cvs (as of two minutes ago) all works perfectly as far as I'm concerned. I attach small screenshots of the LyX and LaTeX views to prove it. Angus, I think Rob is right. Change your zoom-factor of the prefs to e.g. 150% and you'll see, that the lyx view is wrong! Herbert Nope. All is fine for me. These are the non-standard values I have in my preferences file. \screen_zoom 130 \screen_font_scalable false Changing them has no effect whatsoever on the displayed graphics. Have a good weekend. Angus
crash on inserted jpg-file
-BEGIN PGP SIGNED MESSAGE- The crash occurs with current 1.2cvs. Lyx was created with rpm -tb. (Same crash with the 1.2pre1 version) I tried to reproduce the crash with other jpg-files too, but failed. Manually convert the file (via convert) to eps and use it works OK. Compiling lyx with --enable-debug looks OK too. The only backtrace I have is from the non-debug-version. (gdb) info locals No symbol table info available. (gdb) bt #0 0x402fd111 in chunk_alloc () from /lib/libc.so.6 #1 0x402fcf64 in malloc () from /lib/libc.so.6 #2 0x40240659 in __builtin_new () from /usr/lib/libstdc++-libc6.2-2.so.3 #3 0x40240840 in __builtin_vec_new () from /usr/lib/libstdc++-libc6.2-2.so.3 #4 0x0822da00 in lyxstring::Srep::Srep () #5 0x0822e2ce in lyxstring::lyxstring () #6 0x082313b5 in operator () #7 0x08228743 in getExtFromContents () #8 0x08229187 in zippedFile () #9 0x0821bee2 in grfx::GCacheItem::convertToDisplayFormat () #10 0x0821a86b in grfx::GCacheItem::startLoading () #11 0x08219beb in grfx::GCache::startLoading () #12 0x0815f1b1 in InsetGraphics::draw () #13 0x08103ae2 in LyXText::drawInset () #14 0x081043d4 in LyXText::draw () #15 0x0810eb34 in LyXText::paintRowText () #16 0x0810ecb7 in LyXText::getVisibleRow () #17 0x080f05e7 in LyXScreen::drawFromTo () #18 0x080f04c4 in LyXScreen::redraw () #19 0x080576ed in BufferView::Pimpl::workAreaExpose () #20 0x08235d94 in SigC::ObjectSlot0_void, BufferView::Pimpl::callback () #21 0x08233dce in SigC::Signal0void, SigC::Marshalvoid ::emit () #22 0x08087467 in WorkArea::work_area_handler () #23 0x08085f33 in C_WorkArea_work_area_handler () #24 0x40097226 in fl_handle_it () from /usr/X11R6/lib/libforms.so.0.89 #25 0x400972e5 in fl_handle_object () from /usr/X11R6/lib/libforms.so.0.89 #26 0x40096bbb in redraw_marked () from /usr/X11R6/lib/libforms.so.0.89 #27 0x40096ce1 in fl_redraw_object () from /usr/X11R6/lib/libforms.so.0.89 #28 0x080554d9 in BufferView::Pimpl::redraw () #29 0x08055b5c in BufferView::Pimpl::resizeCurrentBuffer () #30 0x08055248 in BufferView::Pimpl::buffer () #31 0x08050279 in BufferView::buffer () #32 0x080ce51f in LyXFunc::open () #33 0x080c9567 in LyXFunc::dispatch () #34 0x080c6951 in LyXFunc::verboseDispatch () #35 0x080c68de in LyXFunc::verboseDispatch () #36 0x081d3afd in Menubar::Pimpl::MenuCallback () #37 0x081ced06 in C_Menubar_Pimpl_MenuCallback () #38 0x4005964e in fl_object_qread () from /usr/X11R6/lib/libforms.so.0.89 #39 0x40069fc8 in fl_check_forms () from /usr/X11R6/lib/libforms.so.0.89 #40 0x081ce1d9 in GUIRunTime::runTime () #41 0x080bc044 in LyXGUI::runTime () #42 0x080bc738 in LyX::LyX () #43 0x080e43d1 in main () #44 0x402a67ee in __libc_start_main () from /lib/libc.so.6 - -- Kornel Benko [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 iQCVAwUBPK3nv7ewfbDGmeqhAQFOXQP8DO2jopzrGbgl/Az6cH1DgPkQIOVO62f5 6+A6340GI5DJjOob6MXePdtReL5mPqkAMekZ5ew5To/m4N9ABt4qVQ3RO72BVzfN 7thmab8XepNqOt59SdXtHwmzvf0OsUJZIeukPMgrK0xO+6HDtyGWtNJTA9maWyU1 WjIb43rtemo= =aJ0O -END PGP SIGNATURE- #LyX 1.2 created this file. For more info see http://www.lyx.org/ \lyxformat 220 \textclass article \language ngerman \inputencoding auto \fontscheme default \graphics default \paperfontsize default \papersize Default \paperpackage a4 \use_geometry 0 \use_amsmath 0 \use_natbib 0 \use_numerical_citations 0 \paperorientation portrait \secnumdepth 3 \tocdepth 3 \paragraph_separation indent \defskip medskip \quotes_language english \quotes_times 2 \papercolumns 1 \papersides 1 \paperpagestyle default \layout Standard \begin_inset Graphics FormatVersion 1 filename /usr2/kornel/jpg/shmoo.jpg display color size_type 1 width 10cm keepAspectRatio rotateOrigin center lyxsize_type 1 lyxwidth 10cm \end_inset \the_end attachment: shmoo.jpg
Re: perhaps this patch fix the file load hang.
John Levon [EMAIL PROTECTED] writes: | On Fri, Apr 05, 2002 at 05:24:42PM +0200, Lars Gullik Bjønnes wrote: at the moment so I cannot find the bug number ... I think it is the blocker bug from bugzilla. | bug 303 it is I see that in most cases the return value of fullRebreak is not used, so I wonder what kind of problems will arise by having fullRebreak always return true. | well why not commit it and we shalle see ! I am a bit weary this close to 1.2.0. Can you try it out a bit and see if you come across anything obvious? -- Lgb
Re: crash on inserted jpg-file
Kornel Benko [EMAIL PROTECTED] writes: | The crash occurs with current 1.2cvs. Lyx was created with rpm -tb. | (Same crash with the 1.2pre1 version) I do not see this crash. What version of xforms are you using? -- Lgb
Opensource Xforms conflicts with gettext of LyX ?
Angus Leeming wrote: Now I'm using the xforms image loading routines that come with modern xforms. I seem to remember that you are using a BSD box with xforms 0.88? In which case, you're using the crappy loading routines I wrote myself. Nonetheless, why don't you upgrade your xforms library to the new open source version that came out the other day? Tried with modern xforms - struggle, struggle, struggle. Got stuck during the compilation of LyX-CVS! The output of ./configure --prefix=/opt is: [...] checking for XpmCreateBufferFromImage in -lXpm... yes checking for X11/xpm.h... yes checking xpm header version... 4.11 checking for fl_initialize in -lforms... no checking for fl_initialize in -lxforms... yes checking for X11/forms.h... yes checking xforms header version... 0..0 [...] Configuration Host type: i386-unknown-freebsd4.4 Special build flags:warnings assertions included-libsigc xforms-image-loader C Compiler: gcc C Compiler flags: -I/opt/include C++ Compiler: g++ (2.95.3) C++ Compiler flags: -I/opt/include -W -Wall Linker flags: -L/opt/lib Frontend: xforms libXpm version: 4.11 libforms version: 0..0 LyX binary dir: /opt/bin LyX files dir: /opt/share/lyx === The following minor problems have been detected by configure. === Please check the messages below before running 'make'. === (see the section 'Problems' in the INSTALL file) == Version 0..0 of xforms might not be compatible with LyX, since it is newer than 0.89. You might have slight problems with it. When I then do the usual gmake, the error appears already after a few output lines: $ gmake Making all in intl gmake[1]: Entering directory `/home/lahaye/SOFTWARE/lyx-devel/intl' gcc -c -DLOCALEDIR=\/opt/share/locale\ -DLOCALE_ALIAS_PATH=\/opt/share/locale\ -DLIBDIR=\/opt/lib\ -DHAVE_CONFIG_H -I../src -I. -I../intl -I/opt/include -isystem /usr/X11R6/include -I/opt/include intl-compat.c gcc -c -DLOCALEDIR=\/opt/share/locale\ -DLOCALE_ALIAS_PATH=\/opt/share/locale\ -DLIBDIR=\/opt/lib\ -DHAVE_CONFIG_H -I../src -I. -I../intl -I/opt/include -isystem /usr/X11R6/include -I/opt/include bindtextdom.c gcc -c -DLOCALEDIR=\/opt/share/locale\ -DLOCALE_ALIAS_PATH=\/opt/share/locale\ -DLIBDIR=\/opt/lib\ -DHAVE_CONFIG_H -I../src -I. -I../intl -I/opt/include -isystem /usr/X11R6/include -I/opt/include dcgettext.c gcc -c -DLOCALEDIR=\/opt/share/locale\ -DLOCALE_ALIAS_PATH=\/opt/share/locale\ -DLIBDIR=\/opt/lib\ -DHAVE_CONFIG_H -I../src -I. -I../intl -I/opt/include -isystem /usr/X11R6/include -I/opt/include dgettext.c gcc -c -DLOCALEDIR=\/opt/share/locale\ -DLOCALE_ALIAS_PATH=\/opt/share/locale\ -DLIBDIR=\/opt/lib\ -DHAVE_CONFIG_H -I../src -I. -I../intl -I/opt/include -isystem /usr/X11R6/include -I/opt/include gettext.c gcc -c -DLOCALEDIR=\/opt/share/locale\ -DLOCALE_ALIAS_PATH=\/opt/share/locale\ -DLIBDIR=\/opt/lib\ -DHAVE_CONFIG_H -I../src -I. -I../intl -I/opt/include -isystem /usr/X11R6/include -I/opt/include finddomain.c gcc -c -DLOCALEDIR=\/opt/share/locale\ -DLOCALE_ALIAS_PATH=\/opt/share/locale\ -DLIBDIR=\/opt/lib\ -DHAVE_CONFIG_H -I../src -I. -I../intl -I/opt/include -isystem /usr/X11R6/include -I/opt/include loadmsgcat.c loadmsgcat.c: In function `_nl_load_domain': loadmsgcat.c:516: warning: assignment discards qualifiers from pointer target type gcc -c -DLOCALEDIR=\/opt/share/locale\ -DLOCALE_ALIAS_PATH=\/opt/share/locale\ -DLIBDIR=\/opt/lib\ -DHAVE_CONFIG_H -I../src -I. -I../intl -I/opt/include -isystem /usr/X11R6/include -I/opt/include localealias.c gcc -c -DLOCALEDIR=\/opt/share/locale\ -DLOCALE_ALIAS_PATH=\/opt/share/locale\ -DLIBDIR=\/opt/lib\ -DHAVE_CONFIG_H -I../src -I. -I../intl -I/opt/include -isystem /usr/X11R6/include -I/opt/include textdomain.c gcc -c -DLOCALEDIR=\/opt/share/locale\ -DLOCALE_ALIAS_PATH=\/opt/share/locale\ -DLIBDIR=\/opt/lib\ -DHAVE_CONFIG_H -I../src -I. -I../intl -I/opt/include -isystem /usr/X11R6/include -I/opt/include l10nflist.c gcc -c -DLOCALEDIR=\/opt/share/locale\ -DLOCALE_ALIAS_PATH=\/opt/share/locale\ -DLIBDIR=\/opt/lib\ -DHAVE_CONFIG_H -I../src -I. -I../intl -I/opt/include -isystem /usr/X11R6/include -I/opt/include explodename.c gcc -c -DLOCALEDIR=\/opt/share/locale\ -DLOCALE_ALIAS_PATH=\/opt/share/locale\ -DLIBDIR=\/opt/lib\ -DHAVE_CONFIG_H -I../src -I. -I../intl -I/opt/include -isystem /usr/X11R6/include -I/opt/include dcigettext.c dcigettext.c: In function `plural_lookup': dcigettext.c:993: called object is not a function gmake[1]: *** [dcigettext.o] Error 1 gmake[1]: Leaving directory `/home/lahaye/SOFTWARE/lyx-devel/intl' gmake: *** [all-recursive] Error 1
Re: eps preview problems in 1.2pre1
On Thursday 04 April 2002 7:00 pm, Mike Ressler wrote: > On Thu, 4 Apr 2002, Ulrich [iso-8859-15] Günther wrote: > > Eps figures cannot be shown in 1.2pre1. > > Every single figure creates an alert once I get on the page with the > > figure. Afterwards the figs show 'error converting to loadable format'. > > I am using SuSE 7.3 but not the ghostscript that comes with the > > distribution, but rather ghostscript-7.04-1 with ghostscript-fonts-6.0-2. > > This smells like the bad Imagemagick convert problem to me. In your > preferences, try the following for the EPS->XPM converter: > > convert EPS:$$i PPM:$$i.ppm ; ppmtoxpm $$i.ppm > $$o > > It uses Imagemagick convert to go from EPS to PPM, then the netpbm tools > to go from PPM to XPM. Some versions of convert (like mine in Mandrake > 8.0) produce bad XPM files. > > Mike Note also that if your xforms library is new enough (0.89.x, x>= about 5), then your config.h file in the src directory will have #define HAVE_FLIMAGE_DUP 1 #define HAVE_FLIMAGE_ENABLE_PS 1 #define HAVE_FLIMAGE_TO_PIXMAP 1 In which case, you'll be using the image loading routines that come with xforms rather than the crappy hack I wrote! In which case, you don't need to convert to XPM at all; just stop at PPM (and delete all those converters to XPM!) Moreover, if you run lyx -dbg graphics, you'll discover that you can load many formats natively and don't need converters at all. Not EPS though. Angus
Re: WYSIWYM and line spacing
On 05-Apr-2002 Herbert Voss wrote: > this is a kind of overhead! for three words I start a search in a > database ... I never used Bibtex so this question may seem stupid, but what if the entry changed in the bibtex file (if that is possible), you would give a wrong information, wouldn't you? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ In matters of principle, stand like a rock; in matters of taste, swim with the current. -- Thomas Jefferson
Re: Graphics bug: Error with bounding box y-coordinate in LyX View
On Friday 05 April 2002 1:41 am, R. Lahaye wrote: > Hi, > > I saw a long thread on this subject. > Downloading CVS in the meantime, has still a wrong > use of Top right y-coordinate for LyX View. > (The Top right y-coordinate is somehow also used > as the Bottom left y-coordinate). > > For final LaTeX output (DVI or Postscript) these > y-coordinates are used correctly! > > > > The values of the (X,Y)-coordinates for Bottom left have > equal effect for both LyX View and LaTeX View. > However, the value of Top right x-coordinate cuts off > different slabs for LyX and for LaTeX! > > Rob. > > PS: use "clip to bounding box" to see these effects. Rob, using today's cvs (as of two minutes ago) all works perfectly as far as I'm concerned. I attach small screenshots of the LyX and LaTeX views to prove it. Now I'm using the xforms image loading routines that come with "modern" xforms. I seem to remember that you are using a BSD box with xforms 0.88? In which case, you're using the crappy loading routines I wrote myself. I have no time today to investigate in depth, but it's always possible that my clipping routine is broken ;-) Nonetheless, why don't you upgrade your xforms library to the new open source version that came out the other day? Regards, Angus lyxview.png Description: PNG image latexview.png Description: PNG image
Re: Graphics bug: Error with bounding box y-coordinate in LyX View
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: >> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: > | Lars> At least with Gcc 3.1 the difference is not great. > | Thanks for doing it. I could not find the time yesterday. The | difference is still great with gcc 2.9x. And gcc 3.1 is not released | yet :) I haven't gcc 3.0 installed anymore, but that is also pretty good, but 3.1. is a lot better. And this will most likely continue. gcc will get better and better and we cannot reap the full benefits since we stay with lyxstring... | I think that lyxstring is really better for our needs than | std::string. The fact that STL authors try to force us to use | std::string is a different matter :) Because of the asserts? | Hmm, I'll have to think again about this stringstream port, since it | would make the code much less painful. but only for stringstream, what about all other api's that use std::string? -- Lgb
CJK-LyX-1.2.0pre1
Hello, I have uploaded CJK-LyX-1.2.0pre1, a patched version of lyx for Chinese, Japanese and Korean users, at the usual ftp site, ftp://stone.phys.pusan.ac.kr/pub/CJK-LyX . Be aware that to compile with the patch file, you have to start with "./autogen.sh". I also wish to warn the users of this version that there is a very annoying bug which I have been unable to remove. Namely, in the inset environment such as "table" or "footnote", the cursor for local input method does not move with the local character input, so that input hebaviour does not look like "on the spot", but "over the spot" in the inset environment. I am open to any suggestion, idea or even a solution !!! Mr. Jurgen Vigna ? -cghan
RE: CJK-LyX-1.2.0pre1
On 05-Apr-2002 [EMAIL PROTECTED] wrote: > I also wish to warn the users of this version that there is a very > annoying bug which I have been unable to remove. Namely, in the inset > environment such as "table" or "footnote", the cursor for local input > method does not move with the local character input, so that input > hebaviour does not look like "on the spot", but "over the spot" in the > inset environment. I am open to any suggestion, idea or even a solution !!! > Mr. Jurgen Vigna ? Hi! I don't really understand what problem you have could you please explain it another time. What do you mean with "over the spot"? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ meeting, n.: An assembly of people coming together to decide what person or department not represented in the room must solve a problem.
Re: Graphics bug: Error with bounding box y-coordinate in LyX View
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> I haven't gcc 3.0 installed anymore, but that is also pretty Lars> good, but 3.1. is a lot better. And this will most likely Lars> continue. Hmm, what I see is mostly higher compile times and higher disk footprint for the same program. So it is a bit more complicated than just 'improving'. Lars> gcc will get better and better and we cannot reap the full Lars> benefits since we stay with lyxstring... I do not say we have to keep lyxstring forever. But it is a good stopgap for the stupidity of current C++ compilers (or of the standard, I don't know). Lars> | I think that lyxstring is really better for our needs than | Lars> std::string. The fact that STL authors try to force us to use | Lars> std::string is a different matter :) Lars> Because of the asserts? Yes, in part. Having control over this is good. And the compile time factor is pretty important too on my p2-366/128M laptop I use here (of course, it is less annoying on my p4-1.7G at home...). Lars> | Hmm, I'll have to think again about this stringstream port, Lars> since it | would make the code much less painful. Lars> but only for stringstream, what about all other api's that use Lars> std::string? There are not so many of them, actually. ifstream/ofstream constructors, and ??? JMarc
Re: New README for the po files
> "adrien" == adrien rebollo <[EMAIL PROTECTED]> writes: adrien> Done. I just added one comment to make clear make XX.pox does adrien> the same thing as msgmerge, for translators used to the old adrien> way. Applied. Thanks. JMarc
Re: Insert->List badly translatable
On Thu, Apr 04, 2002 at 04:42:07PM +0200, Jean-Marc Lasgouttes wrote: > > "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > > > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: > Lars> The problem here is that the number of float types are dynamic, > Lars> so currently a "floatname + ' List'" is done. I see that this > Lars> needs changing to enable better translations, but do not expect > Lars> that to happen for 1.2.0. > > Jean-Marc> I think that the string 'list of something' should be part > Jean-Marc> of the float definition. This is easy and should solve all > Jean-Marc> problems. > > Jean-Marc> And 'Wide Figure' could be replaced with 'Figure (wide)', > Jean-Marc> which should accomodate all languages. > > I did both. Adrien, could you confirm that things did improve? > Yes, they did. However if you have only one adjective (wide) some languages will have problems with eg "Algorithm" being masculine and "Figure" being feminine if they have no gender invariable translation for wide (like Spanish I think). But in French "large" can do the trick so I'll stop complaining... Adrien Rebollo
Re: Graphics bug: Error with bounding box y-coordinate in LyX View
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | Lars> but only for stringstream, what about all other api's that use | Lars> std::string? > | There are not so many of them, actually. ifstream/ofstream | constructors, and ??? Most boost libs and other libs. -- Lgb
Re: Graphics bug: Error with bounding box y-coordinate in LyX Vi
On 05-Apr-2002 Jean-Marc Lasgouttes wrote: > Yes, in part. Having control over this is good. And the compile time > factor is pretty important too on my p2-366/128M laptop I use here (of > course, it is less annoying on my p4-1.7G at home...). Well to tell you the truth I gave up working at home on lyx. It takes too long to compile the sources on my P3-450/256M. When I have 1 hour of time to do something, cvs update make takes 40 minutes well and on the 20 mins left I have time to open 2 source files! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ I sometimes think that God, in creating man, somewhat overestimated his ability. -- Oscar Wilde
Re: WYSIWYM and line spacing
Juergen Vigna wrote: > On 05-Apr-2002 Herbert Voss wrote: > > >>this is a kind of overhead! for three words I start a search in a >>database ... >> > > I never used Bibtex so this question may seem stupid, but what if the entry > changed in the bibtex file (if that is possible), you would give a wrong > information, wouldn't you? it's the same behaviour when editing a graphic file Herbert -- http://www.lyx.org/help/
std::string
> | I think that lyxstring is really better for our needs than > | std::string. The fact that STL authors try to force us to use > | std::string is a different matter :) > > Because of the asserts? > How about using a std::string wrapper which contains the needed asserts? I'm thinking of inheriting a wrapper from std::string and import that in the global namespace rather than std::string. This way, LyX will always be using the assert-improved string, while there will be no problems interacting with anything, since anything that expects a std::string will get just that. This does have the drawback that the asserts will not function while the string is being handled by third party code. I don't know how important that is to you.
Re: Graphics bug: Error with bounding box y-coordinate in LyX Vi
Juergen Vigna <[EMAIL PROTECTED]> writes: | On 05-Apr-2002 Jean-Marc Lasgouttes wrote: > >> Yes, in part. Having control over this is good. And the compile time >> factor is pretty important too on my p2-366/128M laptop I use here (of >> course, it is less annoying on my p4-1.7G at home...). > | Well to tell you the truth I gave up working at home on lyx. It takes too | long to compile the sources on my P3-450/256M. When I have 1 hour of time | to do something, cvs update make takes 40 minutes well and on the 20 mins | left I have time to open 2 source files! This is a result of us having too large classes and too large include files. This then results in too much needing a recompile almost always... -- Lgb
Re: CJK-LyX-1.2.0pre1
On Fri, Apr 05, 2002 at 12:03:41PM +0200, Juergen Vigna wrote: > > I also wish to warn the users of this version that there is a very > > annoying bug which I have been unable to remove. Namely, in the inset > > environment such as "table" or "footnote", the cursor for local input > > method does not move with the local character input, so that input > > hebaviour does not look like "on the spot", but "over the spot" in the > > inset environment. I am open to any suggestion, idea or even a solution !!! > > Mr. Jurgen Vigna ? > > Hi! > > I don't really understand what problem you have could you please explain > it another time. What do you mean with "over the spot"? Probably this : http://bugzilla.lyx.org/show_bug.cgi?id=312 john -- "I never understood what's so hard about picking a unique first and last name - and not going beyond the 6 character limit." - Toon Moene
Re: Graphics bug: Error with bounding box y-coordinate in LyX View
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | Lars> Lars> but only for stringstream, what about all other api's that use | Lars> Lars> std::string? >> Lars> | There are not so many of them, actually. ifstream/ofstream | Lars> constructors, and ??? Lars> Most boost libs and other libs. Are these things we really want to use? But I understand your point. JMarc
Re: Graphics bug: Error with bounding box y-coordinate in LyX Vi
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Juergen Vigna <[EMAIL PROTECTED]> writes: Lars> | On 05-Apr-2002 Jean-Marc Lasgouttes wrote: >> >>> Yes, in part. Having control over this is good. And the compile >>> time factor is pretty important too on my p2-366/128M laptop I use >>> here (of course, it is less annoying on my p4-1.7G at home...). >> Lars> | Well to tell you the truth I gave up working at home on lyx. Lars> It takes too | long to compile the sources on my P3-450/256M. Lars> When I have 1 hour of time | to do something, cvs update make Lars> takes 40 minutes well and on the 20 mins | left I have time to Lars> open 2 source files! Lars> This is a result of us having too large classes and too large Lars> include files. This then results in too much needing a recompile Lars> almost always... And do you really think there is a possiblity to really lower these times (knowing that bloat will have a positive drift in the same timeframe)? JMarc
Re: std::string
> | How about using a std::string wrapper which contains the needed asserts? > > > | I'm thinking of inheriting a wrapper from std::string and import that in the > | global namespace rather than std::string. This way, LyX will always be using > | the assert-improved string, while there will be no problems interacting with > | anything, since anything that expects a std::string will get just that. This > | does have the drawback that the asserts will not function while the string > | is being handled by third party code. I don't know how important that is to > | you. > > Inheriting will mostlikely not work well, wrapping might work, > Mind telling me why? > however > you need std::string to be in namespace std for this to work and not > all C++ libs do that yet. > it could still be done with a typedef, though the other solution is imho more elegant.
Re: Insert->List badly translatable
> "adrien" == adrien rebollo <[EMAIL PROTECTED]> writes: adrien> Yes, they did. However if you have only one adjective (wide) adrien> some languages will have problems with eg "Algorithm" being adrien> masculine and "Figure" being feminine if they have no gender adrien> invariable translation for wide (like Spanish I think). But in adrien> French "large" can do the trick so I'll stop complaining... I guess in this case one can translate it as if it were (wide version) or something. JMarc
ShangHai - Korea - World Cup
Hi, Ik ben vandaag bij de toeristen info in Seoul langs geweest. De enige verbinding tussen ShangHai en Korea is met Incheon. Dat is de havenstad van Seoul, ongeveer een uur met de metro naar Seoul downtown. De boot van ShangHai naar Incheon gaat twee keer per week, dinsdags en donderdags. Vertrek van beiden boten is om 10:00 's morgens en aankomst is de volgende dag: ShangHai 10:00 dinsdag - Incheon 18:30 woensdag ShangHai 10:00 donderdag - Incheon 9:00 vrijdag Ik vraag me nu af of die aankomst tijden wel kloppen, ze verschillen wel erg veel: 18:30 en 9:00 !. De prijzen (enkele reis) voor de verschillende klassen zijn als volgt: regulier (4 pers. per compartiment): 135.000 Won regulier, maar ietwat beter: 175.500 Won suite (4 pers. per compartiment) : 317.250 Won suite (2 pers. per compartiment) : 438.750 Won NB: 1150 Won = 1 Euro Mogelijk zijn de prijzen in China zelfs ietwat (of zelfs behoorlijk) lager. De laatste suites zijn zowat duurder dan vliegen! Als jullie met de boot naar Incheon komen, zal ik jullie uiteraard daar opwachten. Is deze info bruikbaar? - Er staat ontzettend veel te gebeuren in Mei en Juni. Ten dele is dat "te doen gebruikelijk", maar voor een groot deel ook nieuwe evenementen ivm. de wereld beker. Een week voor Boeddha's verjaardag (19 mei) is het Lotus Lantern Festival (op 12 mei). Dit is een groots boeddhist festijn, met een lantaarn parade 's avonds. De mensen staan langs de weg met lampionen terwijl een stoet met fantastische bouwwerken van draken, olifanten e.d. langs trekken. Het lijkt wel een combinatie van lampionentocht en carnavalsoptocht in NL. Op 8 Juni is er een speciaal koninklijk ceremonie (er is geen koning meer in Korea, maar ze immiteren hoe het anno-da-zu-mal er aan toe ging). Dit is uniek, want ze voeren dit maar 3 keer op dit jaar. Het wordt in een van de klassieke paleizen in Seoul opgevoerd. 't Is ook nog gratis! Verder barst het op 1 Juni van de kultuur, dans, vuurwerk en straat- festijnen, want dan is de opening van de wereld beker. In tussentijd zijn er ook goede voorstellingen in de Koreaanse traditionele theaters, als je daar ook in geinteresseerd bent. Als jullie langskomen voor een lang genoeg periode (en jullie geen problemen hebben met mijn klein optrekje) kan het erg gezellig worden. Mijn balkon is in ieder geval zeer ruim en daar kunnen we 's avonds gezellig barbequen, eten en kletsen. Wil je zelf internetten over Korea, kijk dan o.a. op: http://www.visitseoul.net/english/ --- Oh, en voor ik het vergeet: noch voor Korea, noch voor Japan hebben jullie een visum nodig; in beiden landen kun je zonder visum tot 3 maanden verblijven. Moeten we het ook nog over de financien, want ik heb hier in Korea enkele miljoenen aan Won! Als ik verder van dienst kan zijn, dan hoor ik het wel. Tot emails, Rob.
Re: Graphics bug: Error with bounding box y-coordinate in LyX View
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: >> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: > | Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | Lars> | Lars> but only for stringstream, what about all other api's that use | | Lars> Lars> std::string? >>> | Lars> | There are not so many of them, actually. ifstream/ofstream | | Lars> constructors, and ??? > | Lars> Most boost libs and other libs. > | Are these things we really want to use? But I understand your point. Yes, absolutely. -- Lgb
Re: Graphics bug: Error with bounding box y-coordinate in LyX Vi
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: >> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: > | Lars> Juergen Vigna <[EMAIL PROTECTED]> writes: | Lars> | On 05-Apr-2002 Jean-Marc Lasgouttes wrote: >>> Yes, in part. Having control over this is good. And the compile time factor is pretty important too on my p2-366/128M laptop I use here (of course, it is less annoying on my p4-1.7G at home...). >>> | Lars> | Well to tell you the truth I gave up working at home on lyx. | Lars> It takes too | long to compile the sources on my P3-450/256M. | Lars> When I have 1 hour of time | to do something, cvs update make | Lars> takes 40 minutes well and on the 20 mins | left I have time to | Lars> open 2 source files! > | Lars> This is a result of us having too large classes and too large | Lars> include files. This then results in too much needing a recompile | Lars> almost always... > | And do you really think there is a possiblity to really lower these | times (knowing that bloat will have a positive drift in the same | timeframe)? Yes, I do belive so. We have a lot of bloat right now, and a lot of badly "designed" classes and inheritance trees. -- Lgb
Re: std::string
"Bjarke Roune" <[EMAIL PROTECTED]> writes: >> | How about using a std::string wrapper which contains the needed asserts? >> > >> | I'm thinking of inheriting a wrapper from std::string and import that in | the >> | global namespace rather than std::string. This way, LyX will always be | using >> | the assert-improved string, while there will be no problems interacting | with >> | anything, since anything that expects a std::string will get just that. | This >> | does have the drawback that the asserts will not function while the | string >> | is being handled by third party code. I don't know how important that is | to >> | you. >> >> Inheriting will mostlikely not work well, wrapping might work, >> | Mind telling me why? std::string does not have a virtual destructor. It has never been inteded for inheritence. >> however >> you need std::string to be in namespace std for this to work and not >> all C++ libs do that yet. >> | it could still be done with a typedef, though the other solution is imho | more elegant. yes. -- Lgb
Re: std::string
> >> Inheriting will mostlikely not work well, wrapping might work,
> >>
> | Mind telling me why?
>
> std::string does not have a virtual destructor. It has never been
> inteded for inheritence.
>
I'm only thinking of doing something like this:
size_t asserter_string::size()
{
assert(...);
return string::size();
}
(besides from the fact that std::string::size() probably wouldn't need an
assert)
There would be no need to add additional member variables, so a lack of a
virtual destructor should not be a problem. A comment might be added to the
file to point this out.
RE: CJK-LyX-1.2.0pre1
On Fri, 5 Apr 2002, Juergen Vigna wrote: > > > Hi! > > I don't really understand what problem you have could you please explain > it another time. What do you mean with "over the spot"? > Sorry if I was too sloppy Let me explain the situation with the attached four screen shots: 1. In the lyx main window, if I type local (multibyte) characters from the local input method, the characters appear on the screen just like the English typing(the first screen shot-lyx1.png). 2. If I type "enter", then the whole local characters are now put on the same spot (screenshot 2-llyx2.png). The way characters are written in this way is called "on the spot". 3.However in the footnote inset environment, if I type local characters, the characters appear outside of the environment (screenshot3-llyx3.png). Actually, the cursor for the local characters are outside the footnote box. 4. If I type "enter", then the local characters outside of the footnote box are now put inside of the footnote box(screenshot4-lyx4.png). this way of inputting characters are called the "over the spot". Hopefully, you've got the situation clearly, so that you may have an idea. cghan lyx1.png Description: PNG image llyx2.png Description: PNG image llyx3.png Description: PNG image lyx4.png Description: PNG image
Re: CJK-LyX-1.2.0pre1
On Fri, 5 Apr 2002, John Levon wrote: > > Probably this : > > http://bugzilla.lyx.org/show_bug.cgi?id=312 > Maybe or maybe not. The bug has been there since CJK-LyX-1.1.6, when "tabular" environment was changed to table inset environment. cghan
RE: CJK-LyX-1.2.0pre1
On 05-Apr-2002 cghan wrote: > Sorry if I was too sloppy Well you made it a lot better with this email #:O) > Let me explain the situation with the attached four screen shots: > > 1. In the lyx main window, if I type local (multibyte) characters from the > local input method, the characters appear on the screen just like the > English typing(the first screen shot-lyx1.png). > > 2. If I type "enter", then the whole local characters are now put > on the same spot (screenshot 2-llyx2.png). The way characters are written > in this way is called "on the spot". > > 3.However in the footnote inset environment, if I type local characters, > the characters appear outside of the environment (screenshot3-llyx3.png). > Actually, the cursor for the local characters are outside the footnote > box. > > 4. If I type "enter", then the local characters outside of the footnote > box are now put inside of the footnote box(screenshot4-lyx4.png). this > way of inputting characters are called the "over the spot". > > Hopefully, you've got the situation clearly, so that you may have an idea. Well I have to admit if I wouldn't understand it now I would be really dumb ;) This is typically the not handling of a "LFUN" inside the InsetText's localDispatch and/or the wrong handling of it in the main/loop (not considering that the cursor may be inside theLockingInset()!) You would have to tell me what LFUN is called on the first action. Is it an LFUN only available in CJK-Lyx? Just send me the relevant code pieces (LFUN and if used functions the LFUN calls and I'll fix it for you on the fly ;), but probably you can fix it too by not using bv->text and using bv->getLyXText(). Hope this helps, Jug BTW.: The fix for the #312 problem is: Index: src/insets/insettext.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insettext.C,v retrieving revision 1.280 diff -u -p -r1.280 insettext.C --- src/insets/insettext.C 3 Apr 2002 13:59:04 - 1.280 +++ src/insets/insettext.C 5 Apr 2002 12:16:09 - @@ -1190,7 +1190,7 @@ InsetText::localDispatch(BufferView * bv } } lt->selection.cursor = lt->cursor; - updwhat = CURSOR_PAR; + updwhat = CURSOR | CURSOR_PAR; updflag = true; result = DISPATCHED_NOUPDATE; break; -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ There is an old time toast which is golden for its beauty. "When you ascend the hill of prosperity may you not meet a friend." -- Mark Twain
Re: WYSIWYM and line spacing
On 05-Apr-2002 Herbert Voss wrote: >> I never used Bibtex so this question may seem stupid, but what if the entry >> changed in the bibtex file (if that is possible), you would give a wrong >> information, wouldn't you? > > it's the same behaviour when editing a graphic file ??? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Women are not much, but they are the best other sex we have. -- Herold
Re: WYSIWYM and line spacing
Juergen Vigna wrote: > On 05-Apr-2002 Herbert Voss wrote: > > >>>I never used Bibtex so this question may seem stupid, but what if the entry >>>changed in the bibtex file (if that is possible), you would give a wrong >>>information, wouldn't you? >>> >>it's the same behaviour when editing a graphic file >> > > ??? I can see the changes of an external object when I do anything with the inset ... Herbert -- http://www.lyx.org/help/
Re: CJK-LyX-1.2.0pre1
> "cghan" == cghan <[EMAIL PROTECTED]> writes: cghan> On Fri, 5 Apr 2002, John Levon wrote: >> Probably this : >> >> http://bugzilla.lyx.org/show_bug.cgi?id=312 >> cghan> Maybe or maybe not. The bug has been there since CJK-LyX-1.1.6, cghan> when "tabular" environment was changed to table inset cghan> environment. I think it is a problem of using the main lyxtext instead of the one returned by BufferView::getLyXText. But John and Juergen are probably more expert on this. JMarc
Re: More eye candy
On Thu, Mar 28, 2002 at 11:09:51AM +0100, Jean-Marc Lasgouttes wrote: > Don't bother with it. generating this does not cost anything. The only > proble is with the various TOCS, I think (although I'd like to have > hard numbers on a large file: how much does TOC generation cost?). It is not really a matter of performance, but of technical implementation. I wouldn't feel particularly happy about implementing a class derived from QPopupMenu that fills it up during an overridden show(). It might work but I don't think it's a robust technique (as it's definitely unusual, we could expect it to break with various qt versions ...) > If menubackend where to cache the TOCS, using some signal, would > regenerating the menus at each Menu::update() really cost too much? > The time will depend on the number of headings, not number of > paragraphs in document. When does Menu::update() get called exactly ? If this works with a reasonable "frequency", i.e. we can avoid the update-on-menu-open behaviour, then I'm happy. regards john -- "I never understood what's so hard about picking a unique first and last name - and not going beyond the 6 character limit." - Toon Moene
Re: Underfull boxes
On Fri, Mar 29, 2002 at 03:40:58AM +0300, Gady Kozma wrote: > I threw together a little document which explains how to deal with > under/overfull boxes in LyX, with the intention of making it part of the > LyX documentations, stand alone or as a chapter of something bigger. I've added a bug on adding this to the docs here : http://bugzilla.lyx.org/show_bug.cgi?id=318 regards john -- "I never understood what's so hard about picking a unique first and last name - and not going beyond the 6 character limit." - Toon Moene
[PATCH] FormGraphics
this patch changes the unit "pt" in FormGraphics.C to the
correct one "bp" (PostScript unit), also called BigPoint
Herbert
--
http://www.lyx.org/help/
Index: src/frontends/xforms/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/ChangeLog,v
retrieving revision 1.343
diff -u -r1.343 ChangeLog
--- src/frontends/xforms/ChangeLog 5 Apr 2002 09:18:26 - 1.343
+++ src/frontends/xforms/ChangeLog 5 Apr 2002 11:26:21 -
@@ -1,3 +1,8 @@
+2002-04-05 Herbert Voss <[EMAIL PROTECTED]>
+
+ * FormGraphics.C: use correct unit bp (big point - PostScript point)
+ for the bounding box values
+
2002-04-05 Angus Leeming <[EMAIL PROTECTED]>
* FormGraphics.C (updateBB, input): Don't set the path of the file
Index: src/frontends/xforms/FormGraphics.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/FormGraphics.C,v
retrieving revision 1.66
diff -u -r1.66 FormGraphics.C
--- src/frontends/xforms/FormGraphics.C 5 Apr 2002 09:18:26 - 1.66
+++ src/frontends/xforms/FormGraphics.C 5 Apr 2002 11:26:21 -
@@ -169,7 +169,7 @@
setPrehandler(bbox_->input_bb_x1);
setPrehandler(bbox_->input_bb_y1);
- string const bb_units = "pt|cm|in";
+ string const bb_units = "bp|cm|in";
fl_addto_choice(bbox_->choice_bb_units, bb_units.c_str());
bc().addReadOnly(bbox_->button_getBB);
bc().addReadOnly(bbox_->check_clip);
@@ -296,6 +296,7 @@
}
+
void FormGraphics::update() {
// Update dialog with details from inset
InsetGraphicsParams & igp = controller().params();
@@ -453,7 +454,7 @@
fl_set_input(bbox_->input_bb_x1, bb.c_str());
fl_set_input(bbox_->input_bb_y1, bb.c_str());
}
- // "pt"
+ // "bp"
fl_set_choice(bbox_->choice_bb_units, 1);
} else {
@@ -464,16 +465,16 @@
LyXLength anyLength;
anyLength = LyXLength(token(bb_inset,' ',0));
updateWidgetsFromLength(bbox_->input_bb_x0,
- bbox_->choice_bb_units,anyLength,"pt");
+ bbox_->choice_bb_units,anyLength,"bp");
anyLength = LyXLength(token(bb_inset,' ',1));
updateWidgetsFromLength(bbox_->input_bb_y0,
- bbox_->choice_bb_units,anyLength,"pt");
+ bbox_->choice_bb_units,anyLength,"bp");
anyLength = LyXLength(token(bb_inset,' ',2));
updateWidgetsFromLength(bbox_->input_bb_x1,
- bbox_->choice_bb_units,anyLength,"pt");
+ bbox_->choice_bb_units,anyLength,"bp");
anyLength = LyXLength(token(bb_inset,' ',3));
updateWidgetsFromLength(bbox_->input_bb_y1,
- bbox_->choice_bb_units,anyLength,"pt");
+ bbox_->choice_bb_units,anyLength,"bp");
}
}
@@ -590,7 +591,7 @@
fl_set_input(bbox_->input_bb_y0, token(bb,'
',1).c_str());
fl_set_input(bbox_->input_bb_x1, token(bb,'
',2).c_str());
fl_set_input(bbox_->input_bb_y1, token(bb,'
',3).c_str());
- string const unit("pt");
+ string const unit("bp");
fl_set_choice_text(bbox_->choice_bb_units,
unit.c_str());
}
controller().bbChanged = false;
@@ -599,7 +600,7 @@
fl_set_input(bbox_->input_bb_y0, "");
fl_set_input(bbox_->input_bb_x1, "");
fl_set_input(bbox_->input_bb_y1, "");
- fl_set_choice_text(bbox_->choice_bb_units, "pt");
+ fl_set_choice_text(bbox_->choice_bb_units, "bp");
}
// the size section
Re: More eye candy
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> When does Menu::update() get called exactly ? I think it is after each lyxfunc::dispatch. However, we can tweak this behaviour to get what we (you) need. JMarc
Re: Old feature requests [was: nthiery@Icare.Mines.EDU: Various suggestions]
I don't want to file any bugs until at least a little discussion. > - I am missing the following starred environments with amsmath: >notation*, problem*, ... Are they non-standard ? Anybody ? > - When entering emphasized text, striking right arrow at the end of the >line should allow to exit the emphasized text. I wholeheartedly agree here - it has precedent, and is very useful... > - Bug in the users guide: it says LyX uses \epsfig, whereas it really >uses includegraphics to import figures (which is The Right Thing). It doesn't any more (say epsfig I mean). > - Could the file browser for including graphics display thumbnails of >the figure as, say, in the xfig file browser ? For xforms: it would be a lot of work. For Qt2: soon. > - LyX support for "\DeclareGraphicsExtensions" ? >To be able to generate both postscript and PDF documents, I have my >graphics files in both .eps and .pdf format. My problem is that if >I specify a graphics file without an extension "bla", lyx does not >find it. On the other hand, if I specify the full file name >"bla.eps", the compilation with pdflatex does not work. Well my bug on this in bugzilla nobody understood so I closed it ! > - LyX support for "\graphicspath" > >It would be nice to have LyX support the graphicspath latex >feature. Right now, LyX does not find the figure do display it in >the LyX buffer. More important, the compilation fails. On the other >hand, exporting as latex, and compiling by hand works. It seems to >be related to the compilation in the temporary directory. Sure. > - With the Format->Character menu, clicking on apply switch back and >forth between the original and the modified versions. Why not. >However, it's counter intuitive that clicking on OK switches back >to the original ! Perhaps yeah ... > - Support for the hyperref package would be cool. ... > - Could LyX-Code be defined in amsmath/amsbook classes ? I don't think anyone really likes lyx-code ... > - For my use of LyX as presentation tool, I need to be able to >quickly scroll the text to some precise position, so as to display >the precise part of the document I want, and hide the solutions of >the exercises. Moving the cursor around does not work well, since >it makes jumps if there are figures or big equations. Right now I >use the scrollbar. I would prefer to have keyboard shortcuts (Say >Ctrl-Up arrow and Ctrl-down arrow, for scrolling up or down by a >fixed amount (e.g. 1cm). That would save me from looking once again >foolish trying to figure out where the mouse cursor disappeared. You could use bookmarks or navigate menu ... We want to make scrolling done in terms of on-screen amounts as it fixes a number of bugs, but it's some way off really ... (at least so I'm assured) > - I use many different paragraph styles, and had to define many >shortcuts of them. I would find more practical to have a unique >shortcut, with name completion. > >Example: to get to the "Problem" paragraph style, hit M-p Pr. >It could be on some other shortcut than M-p, to avoid conflicts. I don't know how this would work ... >Also, when using the popout paragraph style menu, PgUp and PgDown >should probably also move the cursor in the visible range. xforms bug ! john -- "I never understood what's so hard about picking a unique first and last name - and not going beyond the 6 character limit." - Toon Moene
layout as string bug (I think)
M-p C-a with article style - look at minibuffer "Layout RightAddress not known" john -- "I never understood what's so hard about picking a unique first and last name - and not going beyond the 6 character limit." - Toon Moene
Re: WYSIWYM and line spacing
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes: Allan> I don't have a problem with the and sections Allan> only the part you labelled . I can leave with that too. Allan> I have a problem with saving data that is easily regeneratable. Ditto. And also with saving data that does not exist (Caesar et al.) for a pure old numerical \cite thingie. Allan> JMarc may have concerns about the and handling Allan> but I don't. I see, you try to put words in my mouth to defend yourself... Allan> As I see it: We know natbib support is turned on/off. We know Allan> what \cite format the user wants. We know the key. We know the Allan> bibtex file to search. Therefore, we can reconstruct the label Allan> string just the same way it was generated originally. We don't Allan> need to save the part you labelled . There is probably a problem of having access to the right data at the right time, though. Also, the fact that most of the code is in FormCitation creates some problems that look fishy (described in one of my earlier mails on the subject). JMarc
Re: WYSIWYM and line spacing
> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
Herbert> there are 7 different commands, for example one: the
Herbert> lyx-format: \begin_inset LatexCommand
Herbert> \citealp[<\before>see<\end_before><\after>page
Herbert> 1ff<\end_after><\natbib>Wright, 1978; Wright, 1963; Wood,
Herbert> 1961]{wright-78-book,wright-63,wood-61} \end_inset
One purely cosmetic objection I have to your <> stuff is that, if you
are going to make things SGML-like, this should be
seepage 1ffWright, 1978; Wright, 1963; Wood,
1961
Otherwise, you could use a more sensible solution.
Herbert> this is a kind of overhead! for three words I start a search
Herbert> in a database ...
So you are doing caching of data in the document. I do not like this
much...
Herbert> and how do I know in the inset what bibtex-file I use?
This one is of course the real problem. Angus?
JMarc
