Re: attachments policy
On Tue, Apr 30, 2002 at 01:35:09PM -0500, Mate Wierdl wrote: > audio/basic I think it is fairly safe to remove audio/*... > There is also a possibility that a message containing these kinds of > attachments are simply rejected. Which option is better (I think the > latter). I think, too. > Also, I think it is a good idea to pose an upper limit on message size. > What should it be? Is 30,000 bytes good on all lists, but 300,000 on > the devel list? 30k might be tight but I think you should just try and if there are problems, increase it a bit. 300k is a bit too much for my taste even on devel. Although I had patches larger than 100k myself I'd rather set the limit there... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: [PATCH] Re: Conflict with endfloat
On Tue, Apr 30, 2002 at 03:27:47PM +0200, Herbert Voss wrote:
> please apply together with small changes to insetgraphics.
> [...]
> if (!opts.empty() && !message.empty())
> - before += ("[" + opts + ',' + message);
> + before += ("[%\n" + opts + ',' + message);
In such cases I find it usually helpful to put a comment there _why_ the
\n" is necessary. This increases the probability of a long life for such
"superfluous" output ;-)
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Re: [PATCH] Re: Conflict with endfloat
Looking at the export from 1.16 fix 4, and 1.2.0pre4 (without the patch),
I see the following from 1.1.6
%% LyX 1.1 created this file. For more info, see http://www.lyx.org/.
\begin{document}
This is a test with a float.
\begin{figure}
{\centering \includegraphics{graphs/overall-spring/spring-non-dim.eps} \par}
\caption{There is a figure here}
\end{figure}
This is some text after the float.
\end{document}
while from 1.2.0 I get
%% LyX 1.2 created this file. For more info, see http://www.lyx.org/.
\begin{document}
This is a test with a float.\begin{figure}%
\begin{center}\includegraphics{graphs/overall-spring/spring-non-dim}\end{center}
\caption{There is a figure here}\end{figure}%
This is some text after the float.
\end{document}
The error I get from running latex on the 1.2.0 tex file is
(temp-120pre4.fff)
Runaway arguement?
! File ended while scanning use of \next.
\par
<*> temp-120pre4.tex
?
! Emergency stop.
\par
<*> temp-120pre4.tex
So, it might also be related to the difference in the use of \par between
the two exports. When I had a go at trying to put \par in various places
however, I wasn't successful.
Rod
On Thu, 2 May 2002, Herbert Voss wrote:
> Rod Pinna wrote:
>
> > Herbert et al,
> >
> > Just checked the patch. For endfloat to work, it needs the following
> >
> > os << "\n\\end{" << tmptype << "}\n";
> >
> > rather than
> >
> > os << "\\end{" << tmptype << "}%\n";
> >
> > which was the original line.
> >
> > i.e. end{float}\n, rather than end{float}%
>
>
> yes, I still have it in my tree. forget to tell you ...
>
> I saw that 1.1.6 has the same output, so I'm wondering why
> it worked for you.
>
> Herbert
>
>
>
> --
> http://www.lyx.org/help/
>
_
rpinna|"Zoeggeler denies Hackl four straight luge golds"
@civil.uwa|
.edu.au | ABC news headline, 2002
Re: [PATCH] Re: Conflict with endfloat
Rod Pinna wrote:
> Herbert et al,
>
> Just checked the patch. For endfloat to work, it needs the following
>
> os << "\n\\end{" << tmptype << "}\n";
>
> rather than
>
> os << "\\end{" << tmptype << "}%\n";
>
> which was the original line.
>
> i.e. end{float}\n, rather than end{float}%
yes, I still have it in my tree. forget to tell you ...
I saw that 1.1.6 has the same output, so I'm wondering why
it worked for you.
Herbert
--
http://www.lyx.org/help/
Re: LaTeX Export: clip bounding box values lost?
R. Lahaye wrote:
>>ok, I have it.
>>
> You initially didn't see it, asked me for an test file, but then sent
> the above; so I assume you can reproduce it yourself now, can't you?
>
> I have set about everything there's to set in the Graphics dialog (Draft,
> Unzip, Extra LaTeX options etc. etc.) with, say, graph1.eps. I then clicked
> on Browse for another graphics file, selected graph2.eps (No [Apply] nor
> [OK] yet!), just tab over to Bounding Box and see that the bb coordinates
> have changed. All other settings are still there as they were before.
>
> With eps files, the bounding box changed to the values in the new file.
> With my Grace files, the bounding box values changed to all zeros!!
>
> I consider this as a bug. Would you agree?
try the one-line-patch, it should help
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.369
diff -u -r1.369 ChangeLog
--- src/frontends/xforms/ChangeLog 1 May 2002 10:04:55 - 1.369
+++ src/frontends/xforms/ChangeLog 2 May 2002 05:04:23 -
@@ -1,3 +1,7 @@
+2002-05-02 Herbert Voss <[EMAIL PROTECTED]>
+
+ * FormGraphics.C (input): do not read bb new when it was changed
+
2002-04-30 Rob Lahaye <[EMAIL PROTECTED]>
* FormDocument.C: "USletter" -> "US letter" etc.
"Other" -> "Custom".
Index: src/frontends/xforms/FormGraphics.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/FormGraphics.C,v
retrieving revision 1.70
diff -u -r1.70 FormGraphics.C
--- src/frontends/xforms/FormGraphics.C 1 May 2002 09:25:51 - 1.70
+++ src/frontends/xforms/FormGraphics.C 2 May 2002 05:04:23 -
@@ -510,7 +510,8 @@
if (out_name != in_name && !out_name.empty()) {
fl_set_input(file_->input_filename, out_name.c_str());
}
- if (controller().isFilenameValid(out_name))
+ if (controller().isFilenameValid(out_name) &&
+ !controller().bbChanged)
updateBB(out_name, string());
} else if (ob == file_->check_subcaption) {
Re: [PATCH] Re: Conflict with endfloat
Herbert et al,
Just checked the patch. For endfloat to work, it needs the following
os << "\n\\end{" << tmptype << "}\n";
rather than
os << "\\end{" << tmptype << "}%\n";
which was the original line.
i.e. end{float}\n, rather than end{float}%
No other change appear necessary. I also check using a figure with an ERT
comment after it, in a float, at that went through fine.
Following the discussion on lyx-devel, I don't know what chance this has
of being included. Just as a final comment, I would say that in the
exported tex file, I find it easier to follow if the floats start and end
on new lines.
Thanks,
Rod
On Tue, 30 Apr 2002, Herbert Voss wrote:
> Rod Pinna wrote:
>
> > Herbert,
> >
> > Two questions...
> >
> > 1/ will this patch apply to lyx-1.2.0pre4. I don't follwo the CVS branch.
> > 2/ if it does...how do I apply it. Just to show my cluelessness :)
> >
> > If it can be applied, I'll give it a try tomorrow (mt time), and let you
> > know how it goes.
>
>
> an easy way is to look in the patch. in the beginning
> of each part you see the start line. look for this
> in the file src/insets/insetfloat.C (latex) and change
> the line the one which is maeked with +
>
> the changes in insetgraphics.C are not important to you.
>
>
> Herbert
>
>
>
> --
> http://www.lyx.org/help/
>
_
rpinna|"Zoeggeler denies Hackl four straight luge golds"
@civil.uwa|
.edu.au | ABC news headline, 2002
Re: Japanese lass' sexy pictures / Please remove
Hi, I know that most concern is on how to stop such spam email from being sent to listmembers and the mailinglist itself. Besides this, once it has arrived, is it possible to eliminate these email entries from the mailing list archive? Has someone permission to access the mailinglist archive and actually delete arrived emails that should not be there? That would keep the archive a bit more to the point :). Just a thought, Rob. PS: For personal reasons I only access the mailinglist archive for following the LyX discussions.
Japanese lass' sexy pictures
ec615__FD99__ATTRIBUTE_ALREADY.html Description: Binary data
Re: LaTeX Export: clip bounding box values lost?
Herbert Voss writes: > > R. Lahaye wrote: > > > I have two identical files, say graph1.eps and graph2.eps. > > Then do this simple sequence: > > - open a graphics and load graph1.eps > > - set the the bounding box (and clip) > > - click [Apply] > > - load graph2.eps > > Then the bounding box values are immediately reset to the values > > corresponding to "Get values from file"; clip and everything else > > are still same. > > Sure you don't see this? > > ok, I have it. Herbert, You initially didn't see it, asked me for an test file, but then sent the above; so I assume you can reproduce it yourself now, can't you? I have set about everything there's to set in the Graphics dialog (Draft, Unzip, Extra LaTeX options etc. etc.) with, say, graph1.eps. I then clicked on Browse for another graphics file, selected graph2.eps (No [Apply] nor [OK] yet!), just tab over to Bounding Box and see that the bb coordinates have changed. All other settings are still there as they were before. With eps files, the bounding box changed to the values in the new file. With my Grace files, the bounding box values changed to all zeros!! I consider this as a bug. Would you agree? Regards, Rob.
Re: Solution to the problem of reading old format?
On Wed, May 01, 2002 at 01:19:49PM -0700, Kayvan A. Sylvan wrote: > > Get Up!! > > I was anticipating all sorts of "No" since that's what happened the last > time this idea was brought up. I wonder why. Perhaps it is simply the amount of time and bugfixes invested in relyx-perl. Now that it's clear there are no candidates for maintaining it, it makes a lot more sense to start afresh. > > ...and do the work... you have hereby volunteered :-) > > All the reLyX bugs are already assigned to me, so yes. Excellent ! Having the unmaintained relyx has been a PITA for some time ... Who knows I might even learn python and help out :) john -- "Please let's not resume the argument with the usual whining about how this feature will wipe out humanity or bring us to the promised land." - Charles Campbell on magic words in Subject: headers
Re: Solution to the problem of reading old format?
On Wed, May 01, 2002 at 09:41:05PM +0200, Lars Gullik Bjønnes wrote: > "Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: > > | On Wed, May 01, 2002 at 09:11:51PM +0200, Lars Gullik Bjønnes wrote: > >> "Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: > >> > >> | On Wed, May 01, 2002 at 09:14:15PM +0300, Dekel Tsur wrote: > >> >> In my opinion, the problems when reading old files (bugs #374,#375,#376) > >> >> are unacceptable. > >> >> > >> >> I suggest a different approach for this problem: > >> >> the conversion should be done by an outside script and not in LyX source code. > >> >> Attached is a proof of concept script that converts minipages & float from > >> >> old format to new format. > >> >> The script correctly handle the test case of bugs #374,#375,#376. > >> >> Comments? > >> > > >> | Great! > >> > > >> | This is the direction that we should be going in when we are handling > >> | file format changes. I think that newer LyX should not be burdened > >> | with supporting older file formats. Instead, convertor scripts should > >> | be provided. > >> > >> Yes, this is absolutely the way we want to go, but we will not do so > >> completely for 1.2.0. For 1.3.0 otoh we should be able to have a good > >> framework for this in place. > > > | Speaking of this... > > > | I found an interesting link: http://pylatex.sourceforge.net > > > | reLyX in python? > > Yes please. Allright! Cool! > | *ducks for cover* > > Get Up!! I was anticipating all sorts of "No" since that's what happened the last time this idea was brought up. > ...and do the work... you have hereby volunteered :-) All the reLyX bugs are already assigned to me, so yes. ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92) msg37565/pgp0.pgp Description: PGP signature
Re: [MAILER-DAEMON@wierdlmpc.msci.memphis.edu] failure notice
John Levon <[EMAIL PROTECTED]> writes: | On Wed, May 01, 2002 at 09:50:36PM +0200, Lars Gullik Bjønnes wrote: > >> And if we have some 4-5 of the regular list participants as >> moderators this would work just fine. > | If it's "press a key moderation" I'd be happy to help out... I am not even sure that there are mailing list software that can do this, at least not free ones. -- Lgb
Re: [MAILER-DAEMON@wierdlmpc.msci.memphis.edu] failure notice
On Wed, May 01, 2002 at 09:50:36PM +0200, Lars Gullik Bjønnes wrote: > And if we have some 4-5 of the regular list participants as > moderators this would work just fine. If it's "press a key moderation" I'd be happy to help out... john -- "Please let's not resume the argument with the usual whining about how this feature will wipe out humanity or bring us to the promised land." - Charles Campbell on magic words in Subject: headers
Re: [MAILER-DAEMON@wierdlmpc.msci.memphis.edu] failure notice
Mate Wierdl <[EMAIL PROTECTED]> writes: | Presently the only "almost" sure thing is that the sender of a | spam/virus will not reply to the proper address of a confirmation | request. Moderation would also work. All new subscribers are automatically moderated until the moderator turns moderation for this subscriber off. And if we have some 4-5 of the regular list participants as moderators this would work just fine. -- Lgb
Re: Solution to the problem of reading old format?
"Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: | On Wed, May 01, 2002 at 09:11:51PM +0200, Lars Gullik Bjønnes wrote: >> "Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: >> >> | On Wed, May 01, 2002 at 09:14:15PM +0300, Dekel Tsur wrote: >> >> In my opinion, the problems when reading old files (bugs #374,#375,#376) >> >> are unacceptable. >> >> >> >> I suggest a different approach for this problem: >> >> the conversion should be done by an outside script and not in LyX source code. >> >> Attached is a proof of concept script that converts minipages & float from >> >> old format to new format. >> >> The script correctly handle the test case of bugs #374,#375,#376. >> >> Comments? >> > >> | Great! >> > >> | This is the direction that we should be going in when we are handling >> | file format changes. I think that newer LyX should not be burdened >> | with supporting older file formats. Instead, convertor scripts should >> | be provided. >> >> Yes, this is absolutely the way we want to go, but we will not do so >> completely for 1.2.0. For 1.3.0 otoh we should be able to have a good >> framework for this in place. > | Speaking of this... > | I found an interesting link: http://pylatex.sourceforge.net > | reLyX in python? but I guess we would have to help that project a bit, it seems that it is hardly moving. -- Lgb
Re: Solution to the problem of reading old format?
"Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: | On Wed, May 01, 2002 at 09:11:51PM +0200, Lars Gullik Bjønnes wrote: >> "Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: >> >> | On Wed, May 01, 2002 at 09:14:15PM +0300, Dekel Tsur wrote: >> >> In my opinion, the problems when reading old files (bugs #374,#375,#376) >> >> are unacceptable. >> >> >> >> I suggest a different approach for this problem: >> >> the conversion should be done by an outside script and not in LyX source code. >> >> Attached is a proof of concept script that converts minipages & float from >> >> old format to new format. >> >> The script correctly handle the test case of bugs #374,#375,#376. >> >> Comments? >> > >> | Great! >> > >> | This is the direction that we should be going in when we are handling >> | file format changes. I think that newer LyX should not be burdened >> | with supporting older file formats. Instead, convertor scripts should >> | be provided. >> >> Yes, this is absolutely the way we want to go, but we will not do so >> completely for 1.2.0. For 1.3.0 otoh we should be able to have a good >> framework for this in place. > | Speaking of this... > | I found an interesting link: http://pylatex.sourceforge.net > | reLyX in python? Yes please. | *ducks for cover* Get Up!! ...and do the work... you have hereby volunteered :-) -- Lgb
Re: [MAILER-DAEMON@wierdlmpc.msci.memphis.edu] failure notice
On Wed, May 01, 2002 at 12:13:53AM -0700, Kayvan A. Sylvan wrote: > On Wed, May 01, 2002 at 09:08:40AM +0200, Lars Gullik Bjønnes wrote: > > Mate Wierdl <[EMAIL PROTECTED]> writes: > > > > | So then removing attachments is just snakeoil: viruses are > > | application/octet-stream. > > > > Doeas all virii use octet-stream? I think not. > > > > | As for size restriction: it is again snakeoil with the proposed limits: > > | Klez is 120K. > > > > Did you do this only for the mis-benefit of klez? > > > > btw. filtering is the only way to be somewhat sure. > > Yes. Filtering is the only sure way. Yes, here is how filtering works 1 I get a spam 2 I create a receipe which will block this spam 3 goto 1 In particular, filtering is retroactive. Please note that about two percent of all spam addressed to the lyx lists get actually sent to list members. Two percent, unfortunately, means at least one a day---would be tolerable perhaps, but some are viruses. And in 6 months, 2% may mean 10 a day. > > Excerpts from my procmail recipes (the last one kills klez): > Please show me the receipe that will stop tomorrow's new spam written in Spanish, Chinese, Korean, Turkish. Seriously, where do you guys get these laws "Filtering is the only sure way" and "filtering is the only way to be somewhat sure" ? Presently the only "almost" sure thing is that the sender of a spam/virus will not reply to the proper address of a confirmation request. > :0 > * Content-Type: (text/html)|(multipart/alternative)|(multipart/mixed) > * B ?? TVqQAAMEA > /dev/null > Can you think of a legitimate message that will be stopped by this receipe? How many spams do you recommend for me to read/analyze each day, and how many receipes do you recommend for me to create each day? Mate
Re: How would you like to earn $500-$1000 a month extra cash withjust a little honest effort.
Mark Court <[EMAIL PROTECTED]> writes: | Subject: BOY, 15, EARNS $71,000 IN 5 WEEKS! > | $$$"TRUE STORY" SEEN ON ABC 20-20 bla bla bla The regular pyramid game where only those how starts it earns any monies... the rest are just suckers. Regardless of how many times it is stated that this is legal, it most likely is not. -- Lgb
Re: Solution to the problem of reading old format?
On Wed, May 01, 2002 at 09:11:51PM +0200, Lars Gullik Bjønnes wrote: > "Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: > > | On Wed, May 01, 2002 at 09:14:15PM +0300, Dekel Tsur wrote: > >> In my opinion, the problems when reading old files (bugs #374,#375,#376) > >> are unacceptable. > >> > >> I suggest a different approach for this problem: > >> the conversion should be done by an outside script and not in LyX source code. > >> Attached is a proof of concept script that converts minipages & float from > >> old format to new format. > >> The script correctly handle the test case of bugs #374,#375,#376. > >> Comments? > > > | Great! > > > | This is the direction that we should be going in when we are handling > | file format changes. I think that newer LyX should not be burdened > | with supporting older file formats. Instead, convertor scripts should > | be provided. > > Yes, this is absolutely the way we want to go, but we will not do so > completely for 1.2.0. For 1.3.0 otoh we should be able to have a good > framework for this in place. Speaking of this... I found an interesting link: http://pylatex.sourceforge.net reLyX in python? *ducks for cover* ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92) msg37557/pgp0.pgp Description: PGP signature
Re: [MAILER-DAEMON@wierdlmpc.msci.memphis.edu] failure notice
On Wednesday 01 May 2002 05:21, Mate Wierdl wrote: > So then removing attachments is just snakeoil: viruses are > application/octet-stream. Mail viruses are frequently of almost any MIME type ... it's usually the file extension that determines what certain brain-damaged MUAs pay attention to. Unfortunately the solution I've been using is Exim (www.exim.org) specific ... a carefully crafted filter using regexps to check for certain file extensions in a message whilst ignoring all the MIME encapsulation stuff. It seems to be pretty successful, although it isn't a 100% cure ... I've been using it for a couple of years and no outbreaks of mail viruses where I work. The latest version of the filter is lurking in the Exim mailing list archive, and it might be possible to hack it to work with qmail. I can dig up a copy if anyone is interested in working on it.
How would you like to earn $500-$1000 a month extra cash with just alittle honest effort.
Subject: BOY, 15, EARNS $71,000 IN 5 WEEKS! $$$"TRUE STORY" SEEN ON ABC 20-20 BOY, 15, MAKES 71 THOUSAND DOLLARS IN 5 WKS!! U CAN 2!! AS SEEN ON NATIONAL TV: This is the one! PARENTS OF 15 YEAR-OLD FINDS $71,000 CASH HIDDEN IN HIS CLOSET Does this headline look familiar? Of course it does. You most likely have just seen this story recently featured on a major nightly news program (USA). His mother was cleaning and putting laundry away when she came across a large brown paper bag that was suspiciously buried beneath some clothes and a skateboard in the back of her 15-year-old son's closet. Nothing could have prepared her for the shock she got when she opened the bag and found it was full of cash. Five-dollar bills, twenties, fifties, and hundreds -- all neatly rubber-banded in labeled piles. "My first thought was that he had robbed a bank," said the 41-year-old woman. "There was over $71,000 dollars in that bag -- that's more than my husband earns in a year." The woman immediately called her husband at the car-dealership where he worked to tell him what she had discovered. He came home right away and they drove together to the boy's school and picked him up. Little did they suspect that where the money came from was more shocking than actually finding it in the closet. As it turns out, the boy had been sending out, via E-mail, a type of "Report" to E-mail addresses that he obtained off of the Internet. Everyday after school for the past two months, he had been doing this right on his computer in his bedroom. "I just got the E-mail one day and I figured what the heck. I put my name on it like the instructions said and I started sending it out," said the clever 15-year-old. The E-mail letter listed 5 addresses and contained instructions to send one $5 dollar bill to each person on the list, then delete the address at the top and move the other addresses Down , and finally to add your name to the top of the list. The letter goes on to state that you would receive several thousand dollars in five-dollar bills within 2 weeks if you sent out the letter with your name at the top of the 5-address list. "I get junk E-mail all the time, and really did not think it was going to work," the boy continued. Within the first few days of sending out the E-mail, the Post Office Box that his parents had gotten him for his video-game magazine subscriptions began to fill up with, not magazines, but envelopes containing $5 bills. "About a week later I rode [my bike] down to the post office and my box had 1 magazine and about 300 envelopes stuffed in it. There was also a yellow slip that said I had to go up to the [post office] counter. I thought I was in trouble or something (laughs)." He went on, "I went up to the counter and they had a whole box of more mail for me. I had to ride back home and empty out my backpack because I could not carry it all." Over the next few weeks, the boy continued sending out the E-mail. "The money just kept coming in and I just kept sorting it and stashing it in the closet. I barely had time for my homework." He had also been riding his bike to several of the banks in his area and exchanging the $5 bills for twenties, fifties, and hundreds. "I didn't want the banks to get suspicious so I kept riding to different banks with like five thousand at a time in my backpack. I would usually tell the lady at the bank counter that my dad had sent me in [to exchange the money] and he was outside waiting for me. One time the lady gave me a really strange look and told me that she would not be able to do it for me and my dad would have to come in and do it, but I just rode to the next bank down the street (laughs)." Surprisingly, the boy did not have any reason to be afraid. The reporting news team examined and investigated the so-called "chain-letter" the boy was sending out and found that it was not a chain-letter at all. In fact, it was completely legal according to; US Postal and Lottery Laws, Title 18, Section 1302 and 1341, or Title 18, Section 3005 in the US code, also in the code of federal regulations, Volume 16, Sections 255 and 436, which state a product or service must be exchanged for money received. Every five-dollar bill that he received contained a little note that read, "Please send me report number XYX." This simple note made the letter legal because he was exchanging a service (a "How-To" Report) for a five-dollar fee. Here is the letter that the 15-year-old was sending out by E-mail. You can do the exact same thing he was doing, simply by following the instructions in this letter! Dear Friends & Future Millionaires: AS SEEN ON NATIONAL TV: Make over a half-million dollars every 4 to 5 months from your home for an investment of only a one-time $25 expense - (U.S. dollars) -- THANKS TO THE COMPUTER AGE AND THE INTERNET ! === BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!! Before you say "Bull
Re: Solution to the problem of reading old format?
On Wed, May 01, 2002 at 09:11:51PM +0200, Lars Gullik Bjønnes wrote: > | This is the direction that we should be going in when we are handling > | file format changes. I think that newer LyX should not be burdened > | with supporting older file formats. Instead, convertor scripts should > | be provided. > > Yes, this is absolutely the way we want to go, but we will not do so > completely for 1.2.0. For 1.3.0 otoh we should be able to have a good > framework for this in place. And then we can extend it to even older formats like those pesky .tex things right ?! john -- "Please let's not resume the argument with the usual whining about how this feature will wipe out humanity or bring us to the promised land." - Charles Campbell on magic words in Subject: headers
Re: Solution to the problem of reading old format?
"Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: | On Wed, May 01, 2002 at 09:14:15PM +0300, Dekel Tsur wrote: >> In my opinion, the problems when reading old files (bugs #374,#375,#376) >> are unacceptable. >> >> I suggest a different approach for this problem: >> the conversion should be done by an outside script and not in LyX source code. >> Attached is a proof of concept script that converts minipages & float from >> old format to new format. >> The script correctly handle the test case of bugs #374,#375,#376. >> Comments? > | Great! > | This is the direction that we should be going in when we are handling | file format changes. I think that newer LyX should not be burdened | with supporting older file formats. Instead, convertor scripts should | be provided. Yes, this is absolutely the way we want to go, but we will not do so completely for 1.2.0. For 1.3.0 otoh we should be able to have a good framework for this in place. -- Lgb
Re: Solution to the problem of reading old format?
On Wed, May 01, 2002 at 09:14:15PM +0300, Dekel Tsur wrote: > In my opinion, the problems when reading old files (bugs #374,#375,#376) > are unacceptable. > > I suggest a different approach for this problem: > the conversion should be done by an outside script and not in LyX source code. > Attached is a proof of concept script that converts minipages & float from > old format to new format. > The script correctly handle the test case of bugs #374,#375,#376. > Comments? Great! This is the direction that we should be going in when we are handling file format changes. I think that newer LyX should not be burdened with supporting older file formats. Instead, convertor scripts should be provided. ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92) msg37552/pgp0.pgp Description: PGP signature
Re: Fix for DVI update bug
"Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: | On Wed, May 01, 2002 at 08:08:25PM +0200, Lars Gullik Bjønnes wrote: >> "Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: >> >> >> | lyxstring.C:1764: parse error before `::' >> >> | lyxstring.C:1766: confused by earlier errors, bailing out >> >> >> >> All this because of substandard compiler and library... >> >> >> >> What complier are you using? >> > >> | 2.95.1 on my Linux build machines. >> >> This works with 2.96: >> (by turning the ifs it work with gcc 3.x) > | Yes, this works with gcc-2.95 as well. > | Ship it! ;-) We need configure magic to make it work with gcc 3 as well... And I have no clue how dec cxx wil react to this... -- Lgb
Re: Solution to the problem of reading old format?
Dekel Tsur <[EMAIL PROTECTED]> writes: | In my opinion, the problems when reading old files (bugs #374,#375,#376) | are unacceptable. > | I suggest a different approach for this problem: | the conversion should be done by an outside script and not in LyX source code. | Attached is a proof of concept script that converts minipages & float from | old format to new format. | The script correctly handle the test case of bugs #374,#375,#376. | Comments? It it works ok, we put it in the distribution, add another comment in UPGRADING and perhaps README, and forget about it, except for pointing users at it when strange things happen. -- Lgb
Re: big message handling
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | Changes that limit developers just since we want to avoid spam or | virii is not good. smoking away again I see... -- Lgb
Re: Fix for DVI update bug
On Wed, May 01, 2002 at 08:08:25PM +0200, Lars Gullik Bjønnes wrote: > "Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: > > >> | lyxstring.C:1764: parse error before `::' > >> | lyxstring.C:1766: confused by earlier errors, bailing out > >> > >> All this because of substandard compiler and library... > >> > >> What complier are you using? > > > | 2.95.1 on my Linux build machines. > > This works with 2.96: > (by turning the ifs it work with gcc 3.x) Yes, this works with gcc-2.95 as well. Ship it! ;-) -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92) msg37548/pgp0.pgp Description: PGP signature
Re: Fix for DVI update bug
"Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: >> What about this version then: >> (and it is probably not correct anymore) > | Yes, it compiles and links and runs but produces no change (that is, | the same misbehavior with the dependency files). Yes... I posted a new correct one... -- Lgb
Solution to the problem of reading old format?
In my opinion, the problems when reading old files (bugs #374,#375,#376)
are unacceptable.
I suggest a different approach for this problem:
the conversion should be done by an outside script and not in LyX source code.
Attached is a proof of concept script that converts minipages & float from
old format to new format.
The script correctly handle the test case of bugs #374,#375,#376.
Comments?
#!/usr/bin/python
import sys,string
def check_token(lines, token, i):
if lines[i][:len(token)] == token:
return 1
return 0
def find_token(lines, token, start):
n = len(lines)
m = len(token)
i = start
while i < n:
line = lines[i]
if line[:m] == token:
return i
i = i+1
return -1
def find_token2(lines, token1, token2, start):
n = len(lines)
m1 = len(token1)
m2 = len(token2)
i = start
while i < n:
line = lines[i]
if line[:m1] == token1 or line[:m2] == token2:
return i
i = i+1
return -1
def find_token_backwards(lines, token, start):
n = len(lines)
m = len(token)
i = start
while i >= 0:
line = lines[i]
if line[:m] == token:
return i
i = i-1
return -1
floats = {
"footnote": ["\\begin_inset Foot\n",
"collapsed true\n"],
"margin": ["\\begin_inset Marginal\n",
"collapsed true\n"],
"fig": ["\\begin_inset Float figure\n",
"placement htbp\n",
"wide false\n",
"collapsed false\n"],
"tab": ["\\begin_inset Float table\n",
"placement htbp\n",
"wide false\n",
"collapsed false\n"],
"alg": ["\\begin_inset Float algorithm\n",
"placement htbp\n",
"wide false\n",
"collapsed false\n"],
"wide-fig": ["\\begin_inset Float figure\n",
"placement htbp\n",
"wide true\n",
"collapsed false\n"],
"wide-tab": ["\\begin_inset Float table\n",
"placement htbp\n",
"wide true\n",
"collapsed false\n"]
}
def remove_oldfloat(lines):
i = 0
while 1:
i = find_token(lines, "\\begin_float", i)
if i == -1:
break
j = find_token(lines, "\\end_float", i+1)
floattype = string.split(lines[i])[1]
#print floattype
start = floats[floattype]+["\n"]
mid = lines[i+1:j]
lines[i:j+1]= start+mid+["\\end_inset \n"]
i = i+1
def remove_oldminipage(lines):
i = 0
flag = 0
while 1:
i = find_token(lines, "\\pextra_type 2", i)
if i == -1:
break
hfill = 0
line = string.split(lines[i])
if line[4] == "\\pextra_hfill":
line[4:6] = []
hfill = 1
if line[4] == "\\pextra_start_minipage":
line[4:6] = []
width = line[5]
if line[4] == "\\pextra_widthp":
width = line[5]+"col%"
start = ["\\begin_inset Minipage\n",
"position %s\n" % line[3],
"inner_position 0\n",
'height "0pt"\n',
'width "%s"\n' % width,
"collapsed false\n"
]
if flag:
flag = 0
if hfill:
start = ["\n","\hfill\n","\n"]+start
else:
start = ["\\layout Standard\n"] + start
j = find_token_backwards(lines,"\\layout", i-1)
j0 = j
mid = lines[j:i]
j = find_token2(lines,"\\layout", "\\end_float", i+1)
mid = mid+lines[i+1:j]
while 1:
i = find_token2(lines,"\\layout", "\\pextra_type", j+1)
if i == -1 or not check_token(lines, "\\pextra_type", i):
break
line = string.split(lines[i])
if line[4] == "\\pextra_hfill":
line[4:6] = []
if line[4] == "\\pextra_start_minipage" and line[5] == "1":
flag = 1
break
j = find_token_backwards(lines,"\\layout", i-1)
mid = mid+lines[j:i]
j = find_token2(lines,"\\layout", "\\end_float", i+1)
mid = mid+lines[i+1:j]
end = ["\\end_inset \n"]
lines[j0:j] = start+mid+end
i = i+1
in_file = sys.argv[1]
out_file = sys.argv[2]
fh = open(in_file)
lines = fh.readlines()
fh.close()
remove_oldminipage(lines)
remove_oldfloat(lines)
fh = open(out_file, "w")
for line in lines:
fh.write(line)
fh.close()
Re: big message handling
Mate Wierdl <[EMAIL PROTECTED]> writes: | On Wed, May 01, 2002 at 09:11:24AM +0200, Lars Gullik Bjønnes wrote: >> Mate Wierdl <[EMAIL PROTECTED]> writes: >> >> | Probably a better solution than I proposed is sending a too big >> | message to a special address/list. >> >> imho all changes that are intrusivve on the usage of the lists are bad. > | Sending big files to the list is intrusive for some users (including | some developers). Changes that limit developers just since we want to avoid spam or virii is not good. I do not put size limitation in that category. | So far, I have two votes: one says, forget size limitation, the other | have it. I that is my vote, then you are not listening. >> are sure you cannot plug in procmaqiø somewhere and do some super >> simple filtering? > | Can you tell me what filter will filter out future spam/virus and is | nonintrusive to the users? We are talking about now about 100 spams a | day arriving to the lyx lists... Tell me _any_ filter that will filter any/all problematic mails that does not exist yet... 100 a day? Your are kindo switching positions in this discussion... -- Lgb
Re: Fix for DVI update bug
> What about this version then: > (and it is probably not correct anymore) Yes, it compiles and links and runs but produces no change (that is, the same misbehavior with the dependency files). -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92) msg37544/pgp0.pgp Description: PGP signature
Re: Fix for DVI update bug
"Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes:
>> | lyxstring.C:1764: parse error before `::'
>> | lyxstring.C:1766: confused by earlier errors, bailing out
>>
>> All this because of substandard compiler and library...
>>
>> What complier are you using?
>
| 2.95.1 on my Linux build machines.
This works with 2.96:
(by turning the ifs it work with gcc 3.x)
istream & operator>>(istream & is, lyxstring & str)
{
typedef istreamistream_type;
typedef int int_type;
typedef std::streambuf streambuf_type;
typedef string string_type;
typedef string::size_type size_type;
size_type extracted = 0;
#if 0
istream_type::sentry cerb(is, false);
if (cerb) {
#else
if (is.ipfx0()) {
#endif
str.erase();
std::streamsize w = is.width();
size_type n;
n = w > 0 ? static_cast(w) : str.max_size();
int_type const eof = EOF;
streambuf_type * sb = is.rdbuf();
int_type c = sb->sgetc();
while (extracted < n
&& c != eof && !isspace(c)) {
str += c;
++extracted;
c = sb->snextc();
}
if (c == eof)
is.setstate(std::ios::eofbit);
is.width(0);
}
#if 1
is.isfx();
#endif
if (!extracted)
is.setstate(std::ios::failbit);
return is;
}
--
Lgb
Re: big message handling
On Wed, May 01, 2002 at 09:11:24AM +0200, Lars Gullik Bjønnes wrote: > Mate Wierdl <[EMAIL PROTECTED]> writes: > > | Probably a better solution than I proposed is sending a too big > | message to a special address/list. > > imho all changes that are intrusivve on the usage of the lists are bad. Sending big files to the list is intrusive for some users (including some developers). I really need input on this: should I then just drop the size limitation? But perhaps the lyx webpage on mailing lists could ask users to be considerate, and put big files on the web instead of sending them. So far, I have two votes: one says, forget size limitation, the other have it. > > are sure you cannot plug in procmaqiø somewhere and do some super > simple filtering? Can you tell me what filter will filter out future spam/virus and is nonintrusive to the users? We are talking about now about 100 spams a day arriving to the lyx lists... Mate
Re: Fix for DVI update bug
"Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes:
| On Wed, May 01, 2002 at 07:01:49PM +0200, Lars Gullik Bjønnes wrote:
>> [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
>>
>> | Dekel Tsur <[EMAIL PROTECTED]> writes:
>> >
>> | | The bug was due to a bug in lyxstring (operator <<)
>> | | The problem was that the code did not skip the whitespace before the first
>> | | non whitespace char.
>> | | Attached are two possible fixes:
>> | | The first one was copied from g++-2/std/bastring.cc
>> | | (I don't know what side-effects is.ipfx0 has).
>> >
>> | except that it does not exist in a standard stream?
>> >
>> | Also I am not sure that your change is according to the standard.
>> >
>> | | The second one does the whitespace skipping manually.
>>
>> Can you sheck if this is possible to use with lyxstring:
>> (it probably require a istream that is pretty standard conforming)
What about this version then:
(and it is probably not correct anymore)
istream & operator>>(istream & is, lyxstring & str)
{
typedef istreamistream_type;
typedef int int_type;
typedef std::streambuf streambuf_type;
typedef string string_type;
typedef string::size_type size_type;
size_type extracted = 0;
str.erase();
std::streamsize w = is.width();
size_type n;
n = w > 0 ? static_cast(w) : str.max_size();
int_type const eof = EOF;
streambuf_type * sb = is.rdbuf();
int_type c = sb->sgetc();
while (extracted < n
&& c != eof && !isspace(c)) {
str += c;
++extracted;
c = sb->snextc();
}
if (c == eof)
is.setstate(std::ios::eofbit);
is.width(0);
if (!extracted)
is.setstate(std::ios::failbit);
return is;
}
--
Lgb
Re: Fix for DVI update bug
> | lyxstring.C:1764: parse error before `::' > | lyxstring.C:1766: confused by earlier errors, bailing out > > All this because of substandard compiler and library... > > What complier are you using? 2.95.1 on my Linux build machines. ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92) msg37540/pgp0.pgp Description: PGP signature
Re: [MAILER-DAEMON@wierdlmpc.msci.memphis.edu] failure notice
Mate Wierdl <[EMAIL PROTECTED]> writes: | On Wed, May 01, 2002 at 09:08:40AM +0200, Lars Gullik Bjønnes wrote: >> Mate Wierdl <[EMAIL PROTECTED]> writes: >> >> | So then removing attachments is just snakeoil: viruses are >> | application/octet-stream. >> >> Doeas all virii use octet-stream? I think not. >> >> | As for size restriction: it is again snakeoil with the proposed limits: >> | Klez is 120K. >> >> Did you do this only for the mis-benefit of klez? >> > | Posing size restiction is reasonable because of people behind | slow network access. Sure, but not as a method to get rid of virii. >> btw. filtering is the only way to be somewhat sure. > | Of what? Of removing stuff that you don't want. -- Lgb
Re: [MAILER-DAEMON@wierdlmpc.msci.memphis.edu] failure notice
On Wed, May 01, 2002 at 09:08:40AM +0200, Lars Gullik Bjønnes wrote: > Mate Wierdl <[EMAIL PROTECTED]> writes: > > | So then removing attachments is just snakeoil: viruses are > | application/octet-stream. > > Doeas all virii use octet-stream? I think not. > > | As for size restriction: it is again snakeoil with the proposed limits: > | Klez is 120K. > > Did you do this only for the mis-benefit of klez? > Posing size restiction is reasonable because of people behind slow network access. > btw. filtering is the only way to be somewhat sure. Of what? Mate
Re: Fix for DVI update bug
"Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes:
| On Wed, May 01, 2002 at 07:01:49PM +0200, Lars Gullik Bjønnes wrote:
>> [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
>>
>> | Dekel Tsur <[EMAIL PROTECTED]> writes:
>> >
>> | | The bug was due to a bug in lyxstring (operator <<)
>> | | The problem was that the code did not skip the whitespace before the first
>> | | non whitespace char.
>> | | Attached are two possible fixes:
>> | | The first one was copied from g++-2/std/bastring.cc
>> | | (I don't know what side-effects is.ipfx0 has).
>> >
>> | except that it does not exist in a standard stream?
>> >
>> | Also I am not sure that your change is according to the standard.
>> >
>> | | The second one does the whitespace skipping manually.
>>
>> Can you sheck if this is possible to use with lyxstring:
>> (it probably require a istream that is pretty standard conforming)
>
| g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../.. -I../.. -I../../boost -i
| system /usr/X11R6/include -g -W -Wall -c lyxstring.C -Wp,-MD,.deps/lyxstring.TPl
| o
| lyxstring.C: In function `class istream & operator >>(istream &, lyxstring &)':
| lyxstring.C:1738: ANSI C++ forbids declaration `int_type' with no type
| lyxstring.C:1738: typedef name may not be class-qualified
| lyxstring.C:1738: parse error before `;'
| lyxstring.C:1739: ANSI C++ forbids declaration `__streambuf_type' with no type
| lyxstring.C:1739: typedef name may not be class-qualified
| lyxstring.C:1739: parse error before `;'
| lyxstring.C:1740: ANSI C++ forbids declaration `__ctype_type' with no type
| lyxstring.C:1740: typedef name may not be class-qualified
| lyxstring.C:1740: parse error before `;'
| lyxstring.C:1745: `sentry' is not a member of type `istream'
| lyxstring.C:1745: parse error before `('
| lyxstring.C:1746: `cerb' undeclared (first use this function)
| lyxstring.C:1746: (Each undeclared identifier is reported only once
| lyxstring.C:1746: for each function it appears in.)
| lyxstring.C:1752: `ctype_type' undeclared (first use this function)
| lyxstring.C:1752: parse error before `const'
| lyxstring.C:1753: `int_type' undeclared (first use this function)
| lyxstring.C:1754: `streambuf_type' undeclared (first use this function)
| lyxstring.C:1754: `sb' undeclared (first use this function)
| lyxstring.C:1755: parse error before `='
| lyxstring.C:1758: `c' undeclared (first use this function)
| lyxstring.C:1758: `eof' undeclared (first use this function)
| lyxstring.C:1758: `ctype' undeclared (first use this function)
| lyxstring.C:1758: `ctype_base' undeclared (first use this function)
| lyxstring.C:1758: parse error before `::'
| lyxstring.C:1764: `ios_base' undeclared (first use this function)
| lyxstring.C:1764: parse error before `::'
| lyxstring.C:1766: confused by earlier errors, bailing out
All this because of substandard compiler and library...
What complier are you using?
The oldest compiler I can test with is gcc 2.96 (in progress)
--
Lgb
Re: [PATCH] Re: Other untranslated parts
On Wednesday 01 May 2002 6:06 pm, John Levon wrote: > On Fri, Apr 26, 2002 at 06:53:05PM +0200, Herbert Voss wrote: > > --- src/frontends/controllers/ControlGraphics.C 19 Apr 2002 09:17:05 > > - 1.34 +++ src/frontends/controllers/ControlGraphics.C26 Apr 2002 > > 16:45:16 - } > > + > > +int ControlGraphics::getOriginChoiceNo(string const orig) > > ... > > What happened to this patch ? > > john I did it "properly". Bin it. Angus
Re: [PATCH] Re: Other untranslated parts
On Fri, Apr 26, 2002 at 06:53:05PM +0200, Herbert Voss wrote: > --- src/frontends/controllers/ControlGraphics.C 19 Apr 2002 09:17:05 - > 1.34 > +++ src/frontends/controllers/ControlGraphics.C 26 Apr 2002 16:45:16 - > } > + > +int ControlGraphics::getOriginChoiceNo(string const orig) ... What happened to this patch ? john -- "Please let's not resume the argument with the usual whining about how this feature will wipe out humanity or bring us to the promised land." - Charles Campbell on magic words in Subject: headers
Re: Fix for DVI update bug
On Wed, May 01, 2002 at 07:01:49PM +0200, Lars Gullik Bjønnes wrote:
> [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
>
> | Dekel Tsur <[EMAIL PROTECTED]> writes:
> >
> | | The bug was due to a bug in lyxstring (operator <<)
> | | The problem was that the code did not skip the whitespace before the first
> | | non whitespace char.
> | | Attached are two possible fixes:
> | | The first one was copied from g++-2/std/bastring.cc
> | | (I don't know what side-effects is.ipfx0 has).
> >
> | except that it does not exist in a standard stream?
> >
> | Also I am not sure that your change is according to the standard.
> >
> | | The second one does the whitespace skipping manually.
>
> Can you sheck if this is possible to use with lyxstring:
> (it probably require a istream that is pretty standard conforming)
g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../.. -I../.. -I../../boost -i
system /usr/X11R6/include -g -W -Wall -c lyxstring.C -Wp,-MD,.deps/lyxstring.TPl
o
lyxstring.C: In function `class istream & operator >>(istream &, lyxstring &)':
lyxstring.C:1738: ANSI C++ forbids declaration `int_type' with no type
lyxstring.C:1738: typedef name may not be class-qualified
lyxstring.C:1738: parse error before `;'
lyxstring.C:1739: ANSI C++ forbids declaration `__streambuf_type' with no type
lyxstring.C:1739: typedef name may not be class-qualified
lyxstring.C:1739: parse error before `;'
lyxstring.C:1740: ANSI C++ forbids declaration `__ctype_type' with no type
lyxstring.C:1740: typedef name may not be class-qualified
lyxstring.C:1740: parse error before `;'
lyxstring.C:1745: `sentry' is not a member of type `istream'
lyxstring.C:1745: parse error before `('
lyxstring.C:1746: `cerb' undeclared (first use this function)
lyxstring.C:1746: (Each undeclared identifier is reported only once
lyxstring.C:1746: for each function it appears in.)
lyxstring.C:1752: `ctype_type' undeclared (first use this function)
lyxstring.C:1752: parse error before `const'
lyxstring.C:1753: `int_type' undeclared (first use this function)
lyxstring.C:1754: `streambuf_type' undeclared (first use this function)
lyxstring.C:1754: `sb' undeclared (first use this function)
lyxstring.C:1755: parse error before `='
lyxstring.C:1758: `c' undeclared (first use this function)
lyxstring.C:1758: `eof' undeclared (first use this function)
lyxstring.C:1758: `ctype' undeclared (first use this function)
lyxstring.C:1758: `ctype_base' undeclared (first use this function)
lyxstring.C:1758: parse error before `::'
lyxstring.C:1764: `ios_base' undeclared (first use this function)
lyxstring.C:1764: parse error before `::'
lyxstring.C:1766: confused by earlier errors, bailing out
--
Kayvan A. Sylvan | Proud husband of | Father to my kids:
Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89)
http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)
msg37534/pgp0.pgp
Description: PGP signature
Re: relyx & bugzilla
On Wed, May 01, 2002 at 10:05:08AM +0200, Asger K. Alstrup Nielsen wrote: > - If it is not realistic that a bug will be fixed within a reasonable > time-frame, mark it as "LATER" or "REMIND". For a bugzilla as small as LyX's, I'd be happy with resolving as LATER where appropriate, although this in essence means the bug is pretty much forgotten in practice. > It is important to keep the bug-list realistic and managable, > because only then will you be somewhat person independent. The list is tiny right now ... let's worry about things when they actually happen > It is important that all people can get an overview of the > realistic bugs. This is what milestones, priorities, assignation and severities are for IMHO. regards john -- "Please let's not resume the argument with the usual whining about how this feature will wipe out humanity or bring us to the promised land." - Charles Campbell on magic words in Subject: headers
Re: relyx & bugzilla
On Wed, May 01, 2002 at 12:15:28AM -0700, Kayvan A. Sylvan wrote: > > if we cannot hoax anyone to at least work on one og the bugs... > > You can go ahead and assign a few to me. I won't get it done > for a week or two, but I will get it done. I've assigned them all to you. Don't worry it doesn't mean you have to fix them all :)) Please feel free to WONTFIX any/all bugs that you don't want to deal with thanks john -- "Please let's not resume the argument with the usual whining about how this feature will wipe out humanity or bring us to the promised land." - Charles Campbell on magic words in Subject: headers
Re: Fix for DVI update bug
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Dekel Tsur <[EMAIL PROTECTED]> writes:
>
| | The bug was due to a bug in lyxstring (operator <<)
| | The problem was that the code did not skip the whitespace before the first
| | non whitespace char.
| | Attached are two possible fixes:
| | The first one was copied from g++-2/std/bastring.cc
| | (I don't know what side-effects is.ipfx0 has).
>
| except that it does not exist in a standard stream?
>
| Also I am not sure that your change is according to the standard.
>
| | The second one does the whitespace skipping manually.
Can you sheck if this is possible to use with lyxstring:
(it probably require a istream that is pretty standard conforming)
istream & operator>>(istream & is, lyxstring & str)
{
typedef istreamistream_type;
typedef istream_type::int_type int_type;
typedef istream_type::__streambuf_type streambuf_type;
typedef istream_type::__ctype_type ctype_type;
typedef string string_type;
typedef string_type::size_type size_type;
size_type extracted = 0;
istream_type::sentry cerb(is, false);
if (cerb) {
str.erase();
streamsize w = is.width();
size_type n;
n = w > 0 ? static_cast(w) : str.max_size();
ctype_type const & ctype = use_facet(is.getloc());
int_type const eof = istream::traits_type::eof();
streambuf_type * sb = is.rdbuf();
int_type c = sb->sgetc();
while (extracted < n
&& c != eof && !ctype.is(ctype_base::space, c)) {
str += c;
++extracted;
c = sb->snextc();
}
if (c == eof)
is.setstate(ios_base::eofbit);
is.width(0);
}
if (!extracted)
is.setstate (ios_base::failbit);
return is;
}
--
Lgb
Re: [PATCH] keeping aspect ratio in the LyX view of a graphic
Herbert Voss <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: > >> | your right, but there are some more files to change, leave it >> | until tomorrow. >> It is also a bit late... wait for 1.3.0 will this. You already have a >> compability problem. > > | it's not very important to me, but when we want to change it | which makes sense, than we should change it now! | we have a pre-version, so we do not need any compatibilty | stuff. Sure we do. After the preleases has been launched on the public we need to cater for them. | on the other hand, I read the files in a case that | the value is set to original by default, when an unknown | token appears. > | it's not very impressive, when every version has a new | file-format ... That will happen for some time yet... we have just too many needed changes. -- Lgb
Re: Fix for DVI update bug
Dekel Tsur <[EMAIL PROTECTED]> writes:
| The bug was due to a bug in lyxstring (operator <<)
| The problem was that the code did not skip the whitespace before the first
| non whitespace char.
| Attached are two possible fixes:
| The first one was copied from g++-2/std/bastring.cc
| (I don't know what side-effects is.ipfx0 has).
except that it does not exist in a standard stream?
Also I am not sure that your change is according to the standard.
| The second one does the whitespace skipping manually.
>
| Index: lyxstring.C
| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/lyxstring.C,v
| retrieving revision 1.53
| diff -u -p -r1.53 lyxstring.C
| --- lyxstring.C 6 Apr 2002 12:42:42 - 1.53
| +++ lyxstring.C 1 May 2002 15:32:19 -
| @@ -1745,12 +1745,15 @@ istream & operator>>(istream & is, lyxst
| // better solution
| int w = is.width(0);
| s.clear();
| - char c = 0;
| - while (is.get(c)) {
| - if (isspace(c)) { is.putback(c); break; }
| - s += c;
| - if (--w == 1) break;
| +if (is.ipfx0()) {
| + char c = 0;
| + while (is.get(c)) {
| + if (isspace(c)) { is.putback(c); break; }
| + s += c;
| + if (--w == 1) break;
| + }
| }
| + is.isfx();
| if (s.empty()) is.setstate(std::ios::failbit);
| #endif
| return is;
>
| Index: lyxstring.C
| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/lyxstring.C,v
| retrieving revision 1.53
| diff -u -p -r1.53 lyxstring.C
| --- lyxstring.C 6 Apr 2002 12:42:42 - 1.53
| +++ lyxstring.C 1 May 2002 15:40:42 -
| @@ -1746,9 +1746,17 @@ istream & operator>>(istream & is, lyxst
| int w = is.width(0);
| s.clear();
| char c = 0;
| + bool skipspace = true;
| while (is.get(c)) {
| - if (isspace(c)) { is.putback(c); break; }
| - s += c;
| + if (isspace(c)) {
| + if (!skipspace) {
| + is.putback(c);
| + break;
| + }
| + } else {
| + s += c;
| + skipspace = false;
| + }
| if (--w == 1) break;
| }
| if (s.empty()) is.setstate(std::ios::failbit);
This is what current libstc++ does (gcc 3.1):
template
basic_istream<_CharT, _Traits>&
operator>>(basic_istream<_CharT, _Traits>& __in,
basic_string<_CharT, _Traits, _Alloc>& __str)
{
typedef basic_istream<_CharT, _Traits>__istream_type;
typedef typename __istream_type::int_type __int_type;
typedef typename __istream_type::__streambuf_type __streambuf_type;
typedef typename __istream_type::__ctype_type __ctype_type;
typedef basic_string<_CharT, _Traits, _Alloc> __string_type;
typedef typename __string_type::size_type __size_type;
__size_type __extracted = 0;
typename __istream_type::sentry __cerb(__in, false);
if (__cerb)
{
__str.erase();
streamsize __w = __in.width();
__size_type __n;
__n = __w > 0 ? static_cast<__size_type>(__w) : __str.max_size();
const __ctype_type& __ctype = use_facet<__ctype_type>(__in.getloc());
const __int_type __eof = _Traits::eof();
__streambuf_type* __sb = __in.rdbuf();
__int_type __c = __sb->sgetc();
while (__extracted < __n
&& __c != __eof && !__ctype.is(ctype_base::space, __c))
{
__str += _Traits::to_char_type(__c);
++__extracted;
__c = __sb->snextc();
}
if (__c == __eof)
__in.setstate(ios_base::eofbit);
__in.width(0);
}
#ifdef _GLIBCPP_RESOLVE_LIB_DEFECTS
//211. operator>>(istream&, string&) doesn't set failbit
if (!__extracted)
__in.setstate (ios_base::failbit);
#endif
return __in;
}
This test prog shows that the spaces is discarded... but I really do
not see how... Perhaps it is the stream itself that is in some kind of
ignore space mode...
#include
#include
#include
using namespace std;
int main()
{
string line("test test test test");
istringstream ist(line);
string word;
while (ist) {
ist >> word;
cout << word << endl;
}
}
--
Lgb
Re: Fix for DVI update bug
On Wed, May 01, 2002 at 06:43:42PM +0300, Dekel Tsur wrote: > The bug was due to a bug in lyxstring (operator <<) > The problem was that the code did not skip the whitespace before the first > non whitespace char. > Attached are two possible fixes: > The first one was copied from g++-2/std/bastring.cc > (I don't know what side-effects is.ipfx0 has). > The second one does the whitespace skipping manually. My hero!!! I have tested the first patch and it fixes the Update->DVI problem. I just realized why this was showing up in the RPM but not in my Cygwin builds. The RPM uses ``configure --with-included-string'', but when I was doing my Cygwin builds, I was just doing a plain configure. I now did the same with patch2 and it also works. So, Lars, Angus, whoever else, please pick one of these patches and apply to CVS. Thanks! ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92) msg37528/pgp0.pgp Description: PGP signature
Re: Placement of \usepackage{babel}
Dekel Tsur wrote:
> On Wed, May 01, 2002 at 02:17:47AM +0200, [EMAIL PROTECTED] wrote:
>
>>>I suggest we revert to the old behavior (which has been around for
>>>ages, (before 1.0)), and make a proper fix in 1.3.0 (or later):
>>>have a package management dialog which allow you to add the
>>>
>>packages
>>
>>>you want (and set their options), and additionally, have a package
>>>databases that contains all known constraints.
>>>
>>I would like to point out that, in this particular case, it is very easy
>>to add usepackage{babel} just before the renewcommand. Just
>>a matter of telling people to add one line in their preamble.
>>
>
> But how would a user know where this information is written ?
>
>
>>OTOH, here are packages which really need to be before babel (and
>>it seems to me that this is recommended in general)
>>
>
> In lyx < 1.2.0, the user could tell lyx not to put \usepackage{babel}
> automatically (by using the default language),
> and put \usepackage{babel} manually in the preamble. So it not a big problem.
>
>
>>Do you really think that avoiding one extra line is s important?
>>
>
> Yes. Why this has to fixed now?
I agree, it's dissatisfying. I f you are interested I can send
you the patch for my package manager, as far as it works for now.
but it's a lot do
Herbert
--
http://www.lyx.org/help/
Re: Placement of \usepackage{babel}
On Wed, May 01, 2002 at 02:17:47AM +0200, [EMAIL PROTECTED] wrote:
> > I suggest we revert to the old behavior (which has been around for
> > ages, (before 1.0)), and make a proper fix in 1.3.0 (or later):
> > have a package management dialog which allow you to add the
> packages
> > you want (and set their options), and additionally, have a package
> > databases that contains all known constraints.
>
> I would like to point out that, in this particular case, it is very easy
> to add usepackage{babel} just before the renewcommand. Just
> a matter of telling people to add one line in their preamble.
But how would a user know where this information is written ?
> OTOH, here are packages which really need to be before babel (and
> it seems to me that this is recommended in general)
In lyx < 1.2.0, the user could tell lyx not to put \usepackage{babel}
automatically (by using the default language),
and put \usepackage{babel} manually in the preamble. So it not a big problem.
> Do you really think that avoiding one extra line is s important?
Yes. Why this has to fixed now?
Re: Bug with geometry package
Angus Leeming wrote: > which is correct. you are right, my fault. I think I should say good bye until 1.2 is really out, because it's a bit confusing for me to hold all my different versions keep apart. HErbert -- http://www.lyx.org/help/
Re: Mathed cursor goosed ??
On Wed, May 01, 2002 at 05:18:12AM +0100, John Levon wrote: > > Load the attached then do export->ascii. The cursor ends up > above the top of the document somehow. > > Also the ascii export is not too stellar : I think that the InsetFormula::ascii should be droped for 1.2.0 It does not always give you a sensible result, and moreover, some users (like me) might prefer using latex notation when writing formulae in text files.
Re: Update DVI bug still there
On Wed, May 01, 2002 at 05:22:15AM +0200, Lars Gullik Bjønnes wrote: > "Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: > > | On Wed, May 01, 2002 at 04:42:06AM +0200, Lars Gullik Bjønnes wrote: > >> | [[Now, I insert "X" in the LyX buffer, do File->Save and View->Update->DVI]] > >> > > >> | Dependency file exists > >> | Read dep: /net/home/kayvan/etc/scouts/lyx//../img/garf2.eps 3732986742 938383314 > >> | Updating DepTable... > >> | /net/home/kayvan/etc/scouts/lyx//../img/garf2.eps same mtime > >> | Finished updating DepTable (0 sec). > >> | return no_change > >> | TextCache: BufferView::buffer > >> > >> Is this all you get on the second run? > > > | Yes. > > strange... > what is the contents of the .dep file? /tmp/lyx_tmpdir23063O4eKc2/lyx_tmpbuf0/foo.eps 814242218 0 /tmp/lyx_tmpdir23063O4eKc2/lyx_tmpbuf0/foo.tex 2837693465 1020267561 /usr/share/texmf/tex/generic/babel/babel.def 3150438143 984247284 /usr/share/texmf/tex/generic/babel/babel.sty 3507177009 984247284 /usr/share/texmf/tex/generic/babel/english.ldf 3794645794 984247285 /usr/share/texmf/tex/latex/base/article.cls 3125085149 984160264 /usr/share/texmf/tex/latex/base/fontenc.sty 46135906 984160263 /usr/share/texmf/tex/latex/base/inputenc.sty 2787711530 984160263 /usr/share/texmf/tex/latex/base/latin1.def 61207602 984160263 /usr/share/texmf/tex/latex/base/size10.clo 4000307840 984160264 /usr/share/texmf/tex/latex/base/t1enc.def 4171694287 984160263 /usr/share/texmf/tex/latex/config/graphics.cfg 1304009822 916818488 /usr/share/texmf/tex/latex/graphics/dvips.def 3647412727 984161114 /usr/share/texmf/tex/latex/graphics/graphics.sty 1742016218 984161114 /usr/share/texmf/tex/latex/graphics/graphicx.sty 4049810553 984161114 /usr/share/texmf/tex/latex/graphics/keyval.sty 2300645532 984161114 /usr/share/texmf/tex/latex/graphics/trig.sty 1552932108 984161114 > (why does it seem that it only containes the .eps file?) > > >> And can you please debug with super simple lyx files only (especially > >> at first) > > > | I have reduced the testcase to this file: No preamble, no special stuff, > | just an inserted graphic. The LyX and eps file are attached. > > And if you reduce the testcase even more? To a file that just contains > an 'X' and then change into 'XX'? Without the inserted graphic the file works fine. BUT... If you start with the inserted graphic, do an Update->DVI, then delete the graphic and try again, it exhibits the same misbehavior. > > And what is the difference in the debug out put between those two > testcases then? Here is the case when you start without the inserted graphic: [...] Updating DepTable... /tmp/lyx_tmpdir23076t68IIC/lyx_tmpbuf0/foo.tex CRC... done /usr/share/texmf/tex/generic/babel/babel.def same mtime /usr/share/texmf/tex/generic/babel/babel.sty same mtime /usr/share/texmf/tex/generic/babel/english.ldf same mtime /usr/share/texmf/tex/latex/base/article.cls same mtime /usr/share/texmf/tex/latex/base/fontenc.sty same mtime /usr/share/texmf/tex/latex/base/inputenc.sty same mtime /usr/share/texmf/tex/latex/base/latin1.def same mtime /usr/share/texmf/tex/latex/base/size10.clo same mtime /usr/share/texmf/tex/latex/base/t1enc.def same mtime Finished updating DepTable (0 sec). Dep. file has NOT changed Write dep: /tmp/lyx_tmpdir23076t68IIC/lyx_tmpbuf0/foo.tex 738525099 1020267717 Write dep: /usr/share/texmf/tex/generic/babel/babel.def 3150438143 984247284 Write dep: /usr/share/texmf/tex/generic/babel/babel.sty 3507177009 984247284 Write dep: /usr/share/texmf/tex/generic/babel/english.ldf 3794645794 984247285 Write dep: /usr/share/texmf/tex/latex/base/article.cls 3125085149 984160264 Write dep: /usr/share/texmf/tex/latex/base/fontenc.sty 46135906 984160263 Write dep: /usr/share/texmf/tex/latex/base/inputenc.sty 2787711530 984160263 Write dep: /usr/share/texmf/tex/latex/base/latin1.def 61207602 984160263 Write dep: /usr/share/texmf/tex/latex/base/size10.clo 4000307840 984160264 Write dep: /usr/share/texmf/tex/latex/base/t1enc.def 4171694287 984160263 [...] -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92) msg37523/pgp0.pgp Description: PGP signature
Re: [PATCH] keeping aspect ratio in the LyX view of a graphic
Lars Gullik Bjønnes wrote: > | your right, but there are some more files to change, leave it > > | until tomorrow. > > It is also a bit late... wait for 1.3.0 will this. You already have a > compability problem. it's not very important to me, but when we want to change it which makes sense, than we should change it now! we have a pre-version, so we do not need any compatibilty stuff. on the other hand, I read the files in a case that the value is set to original by default, when an unknown token appears. it's not very impressive, when every version has a new file-format ... Herbert -- http://www.lyx.org/help/
Fix for DVI update bug
The bug was due to a bug in lyxstring (operator <<)
The problem was that the code did not skip the whitespace before the first
non whitespace char.
Attached are two possible fixes:
The first one was copied from g++-2/std/bastring.cc
(I don't know what side-effects is.ipfx0 has).
The second one does the whitespace skipping manually.
Index: lyxstring.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/lyxstring.C,v
retrieving revision 1.53
diff -u -p -r1.53 lyxstring.C
--- lyxstring.C 6 Apr 2002 12:42:42 - 1.53
+++ lyxstring.C 1 May 2002 15:32:19 -
@@ -1745,12 +1745,15 @@ istream & operator>>(istream & is, lyxst
// better solution
int w = is.width(0);
s.clear();
- char c = 0;
- while (is.get(c)) {
- if (isspace(c)) { is.putback(c); break; }
- s += c;
- if (--w == 1) break;
+if (is.ipfx0()) {
+ char c = 0;
+ while (is.get(c)) {
+ if (isspace(c)) { is.putback(c); break; }
+ s += c;
+ if (--w == 1) break;
+ }
}
+ is.isfx();
if (s.empty()) is.setstate(std::ios::failbit);
#endif
return is;
Index: lyxstring.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/lyxstring.C,v
retrieving revision 1.53
diff -u -p -r1.53 lyxstring.C
--- lyxstring.C 6 Apr 2002 12:42:42 - 1.53
+++ lyxstring.C 1 May 2002 15:40:42 -
@@ -1746,9 +1746,17 @@ istream & operator>>(istream & is, lyxst
int w = is.width(0);
s.clear();
char c = 0;
+ bool skipspace = true;
while (is.get(c)) {
- if (isspace(c)) { is.putback(c); break; }
- s += c;
+ if (isspace(c)) {
+ if (!skipspace) {
+ is.putback(c);
+ break;
+ }
+ } else {
+ s += c;
+ skipspace = false;
+ }
if (--w == 1) break;
}
if (s.empty()) is.setstate(std::ios::failbit);
Re: Bug with geometry package
Angus Leeming wrote:
> On Wednesday 01 May 2002 4:21 pm, Angus Leeming wrote:
>
>>On Wednesday 01 May 2002 4:15 pm, Herbert Voss wrote:
>>
>>>Someone changed the behaviour when activating
>>>Layout->Document-Paper->Custom Sizes.
>>>
>>>All input fields show the value 0. this is wrong!
>>>geometry has default values for the lengths, so that
>>>these inputfields have to leave empty, to get the predefined
>>>values. Now we have a latex output like
>>>
>>>\geometry{verbose,a4paper,tmargin=0cm,bmargin=0cm,lmargin=0cm,rmargin=0cm
>>>,h eadheight=0cm,headsep=0cm,footskip=0cm}
>>>
>>>and it should be \geometry{verbose,a4paper}
>>>when I do not input any length.
>>>
>>>Herbert
>>>
>>Probably my fault. I'll have a look.
>>Angus
>>
>
> (Not my fault because I haven't done anything here).
>
> I get, when exporting to LaTeX:
>
> \geometry{verbose,a4paper,lmargin=0.5in,rmargin=0.5in,headheight=-1in}
>
> which is correct.
File->new
Layout->Document-Paper->Custom Sizes
export to latex, what does the header says?
it should be: \geometry{verbose,a4paper}
HErbert
--
http://www.lyx.org/help/
Re: [PATCH] keeping aspect ratio in the LyX view of a graphic
Herbert Voss <[EMAIL PROTECTED]> writes: | Angus Leeming wrote: > >> On Wednesday 01 May 2002 3:59 pm, Herbert Voss wrote: >> >>| 0: as is >>| 1: width/height >>| 2: scale >> >>then that is what it should say. >>I just hate non-descriptive constants. >> >> | cool ... | I never read that you said this about the figinset .. | which has only non-descriptive constants mostly because it was scheduled for replacement almost from the beginning. >>>no comment ... >>> >>>Angus, do we want to make Lars happy? :-) >>> >>>Herbert >>> >> I think that if this makes him happy, he should get out more ;-) >> Herbert, if you want to do this, then fine, but you should note that >> "size_type" means something quite specific in C++ and your >> nomenclature is confusing in this regard. Try size_kind perhaps. > > | your right, but there are some more files to change, leave it > | until tomorrow. It is also a bit late... wait for 1.3.0 will this. You already have a compability problem. -- Lgb
Re: Bug with geometry package
Angus Leeming wrote:
> On Wednesday 01 May 2002 4:15 pm, Herbert Voss wrote:
>
>>Someone changed the behaviour when activating
>>Layout->Document-Paper->Custom Sizes.
>>
>>All input fields show the value 0. this is wrong!
>>geometry has default values for the lengths, so that
>>these inputfields have to leave empty, to get the predefined
>>values. Now we have a latex output like
>>
>>\geometry{verbose,a4paper,tmargin=0cm,bmargin=0cm,lmargin=0cm,rmargin=0cm,h
>>eadheight=0cm,headsep=0cm,footskip=0cm}
>>
>>and it should be \geometry{verbose,a4paper}
>>when I do not input any length.
>>
>>Herbert
>>
>
> Probably my fault. I'll have a look.
this seems not to be easy to change, because we have now a
LyXlength here and we do not know if we have a user defined
0cm or an undefined lyxlength, which is also set to 0cm
Herbert
--
http://www.lyx.org/help/
Re: Bug with geometry package
On Wednesday 01 May 2002 4:21 pm, Angus Leeming wrote:
> On Wednesday 01 May 2002 4:15 pm, Herbert Voss wrote:
> > Someone changed the behaviour when activating
> > Layout->Document-Paper->Custom Sizes.
> >
> > All input fields show the value 0. this is wrong!
> > geometry has default values for the lengths, so that
> > these inputfields have to leave empty, to get the predefined
> > values. Now we have a latex output like
> >
> > \geometry{verbose,a4paper,tmargin=0cm,bmargin=0cm,lmargin=0cm,rmargin=0cm
> >,h eadheight=0cm,headsep=0cm,footskip=0cm}
> >
> > and it should be \geometry{verbose,a4paper}
> > when I do not input any length.
> >
> > Herbert
>
> Probably my fault. I'll have a look.
> Angus
(Not my fault because I haven't done anything here).
I get, when exporting to LaTeX:
\geometry{verbose,a4paper,lmargin=0.5in,rmargin=0.5in,headheight=-1in}
which is correct.
Angus
Re: [PATCH] keeping aspect ratio in the LyX view of a graphic
Angus Leeming wrote: > On Wednesday 01 May 2002 3:59 pm, Herbert Voss wrote: > >| 0: as is >| 1: width/height >| 2: scale > >then that is what it should say. >I just hate non-descriptive constants. > > >>>| cool ... >>>| I never read that you said this about the figinset .. >>>| which has only non-descriptive constants >>> >>>mostly because it was scheduled for replacement almost from the >>>beginning. >>> >>no comment ... >> >>Angus, do we want to make Lars happy? :-) >> >>Herbert >> > > I think that if this makes him happy, he should get out more ;-) > > Herbert, if you want to do this, then fine, but you should note that > "size_type" means something quite specific in C++ and your nomenclature is > confusing in this regard. Try size_kind perhaps. your right, but there are some more files to change, leave it until tomorrow. Herbert -- http://www.lyx.org/help/
Re: Bug with geometry package
On Wednesday 01 May 2002 4:15 pm, Herbert Voss wrote:
> Someone changed the behaviour when activating
> Layout->Document-Paper->Custom Sizes.
>
> All input fields show the value 0. this is wrong!
> geometry has default values for the lengths, so that
> these inputfields have to leave empty, to get the predefined
> values. Now we have a latex output like
>
> \geometry{verbose,a4paper,tmargin=0cm,bmargin=0cm,lmargin=0cm,rmargin=0cm,h
>eadheight=0cm,headsep=0cm,footskip=0cm}
>
> and it should be \geometry{verbose,a4paper}
> when I do not input any length.
>
> Herbert
Probably my fault. I'll have a look.
Angus
Re: [PATCH] keeping aspect ratio in the LyX view of a graphic
On Wednesday 01 May 2002 3:59 pm, Herbert Voss wrote: > >>>| 0: as is > >>>| 1: width/height > >>>| 2: scale > >>> > >>>then that is what it should say. > >>>I just hate non-descriptive constants. > >>> > > | cool ... > > | I never read that you said this about the figinset .. > > | which has only non-descriptive constants > > > > mostly because it was scheduled for replacement almost from the > > beginning. > > no comment ... > > Angus, do we want to make Lars happy? :-) > > Herbert I think that if this makes him happy, he should get out more ;-) Herbert, if you want to do this, then fine, but you should note that "size_type" means something quite specific in C++ and your nomenclature is confusing in this regard. Try size_kind perhaps. Angus
Bug with geometry package
Someone changed the behaviour when activating
Layout->Document-Paper->Custom Sizes.
All input fields show the value 0. this is wrong!
geometry has default values for the lengths, so that
these inputfields have to leave empty, to get the predefined
values. Now we have a latex output like
\geometry{verbose,a4paper,tmargin=0cm,bmargin=0cm,lmargin=0cm,rmargin=0cm,headheight=0cm,headsep=0cm,footskip=0cm}
and it should be \geometry{verbose,a4paper}
when I do not input any length.
Herbert
--
http://www.lyx.org/help/
Re: [PATCH] keeping aspect ratio in the LyX view of a graphic
>>>| 0: as is
>>>| 1: width/height
>>>| 2: scale
>>>then that is what it should say.
>>>I just hate non-descriptive constants.
>>>
>>
> | cool ...
> | I never read that you said this about the figinset ..
> | which has only non-descriptive constants
>
> mostly because it was scheduled for replacement almost from the
> beginning.
no comment ...
Angus, do we want to make Lars happy? :-)
Herbert
--
http://www.lyx.org/help/
Index: src/insets/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/ChangeLog,v
retrieving revision 1.409
diff -u -r1.409 ChangeLog
--- src/insets/ChangeLog1 May 2002 10:23:51 - 1.409
+++ src/insets/ChangeLog1 May 2002 14:52:55 -
@@ -1,3 +1,7 @@
+2002-05-01 Herbert Voss <[EMAIL PROTECTED]>
+
+ * insetgraphicsParams.[Ch]: read/write (lyx)size_type as text
+
2002-05-01 Angus Leeming <[EMAIL PROTECTED]>
* InsetgraphicsParams.[Ch]: whitespace.
Index: src/insets/insetgraphicsParams.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetgraphicsParams.C,v
retrieving revision 1.35
diff -u -r1.35 insetgraphicsParams.C
--- src/insets/insetgraphicsParams.C1 May 2002 10:23:51 - 1.35
+++ src/insets/insetgraphicsParams.C1 May 2002 14:52:55 -
@@ -162,6 +162,34 @@
}
+namespace {
+
+InsetGraphicsParams::sizeType getSizeType(string const & str_in)
+{
+ if (str_in == "width_height")
+ return InsetGraphicsParams::WH;
+ else if (str_in == "scale")
+ return InsetGraphicsParams::SCALE;
+
+ // all other like "original"
+ return InsetGraphicsParams::DEFAULT_SIZE;
+}
+
+
+string const getSizeTypeStr(InsetGraphicsParams::sizeType sT_in)
+{
+ if (sT_in == InsetGraphicsParams::SCALE)
+ return "scale";
+ else if (sT_in == InsetGraphicsParams::WH)
+ return "width_height";
+
+ // all other like DEFAULT_SIZE"
+ return "original";
+}
+
+} //anon
+
+
void InsetGraphicsParams::Write(ostream & os) const
{
// If there is no filename, write nothing for it.
@@ -183,11 +211,7 @@
os << "\tsubcaptionText \"" << subcaptionText << '\"' << '\n';
if (noUnzip)
os << "\tnoUnzip\n";
- // we always need the size type
- // 0: no special
- // 1: width/height combination
- // 2: scale
- os << "\tsize_type " << size_type << '\n';
+ os << "\tsize_type " << getSizeTypeStr(size_type) << '\n';
if (!width.zero())
os << "\twidth " << width.asString() << '\n';
if (!height.zero())
@@ -205,7 +229,7 @@
if (!special.empty())
os << "\tspecial " << special << '\n';
// the values for the view in lyx
- os << "\tlyxsize_type " << lyxsize_type << '\n';
+ os << "\tlyxsize_type " << getSizeTypeStr(lyxsize_type) << '\n';
if (!lyxwidth.zero()) // the lyx-viewsize
os << "\tlyxwidth " << lyxwidth.asString() << '\n';
if (!lyxheight.zero())
@@ -242,17 +266,7 @@
noUnzip = true;
} else if (token == "size_type") {
lex.next();
- switch (lex.getInteger()) {
- case 0:
- size_type = DEFAULT_SIZE;
- break;
- case 1:
- size_type = WH;
- break;
- case 2:
- size_type = SCALE;
- break;
- }
+ size_type = getSizeType(lex.getString());
} else if (token == "width") {
lex.next();
width = LyXLength(lex.getString());
@@ -276,17 +290,7 @@
rotateOrigin=lex.getString();
} else if (token == "lyxsize_type") {
lex.next();
- switch (lex.getInteger()) {
- case 0:
- lyxsize_type = DEFAULT_SIZE;
- break;
- case 1:
- lyxsize_type = WH;
- break;
- case 2:
- lyxsize_type = SCALE;
- break;
- }
+ lyxsize_type = getSizeType(lex.getString());
} else if (token == "lyxwidth") {
lex.next();
lyxwidth = LyXLength(lex.getString());
Re: Character dialog + Afrikaans
On Wednesday 01 May 2002 2:50 pm, John Levon wrote: > maybe fixed already but opening char dialog in a new doc shows the > language > as Afrikaans (failed to set it to english) > > john Or rather, to "No change". Yuch! We have a list with "No change" when we expect "ignore". Only luck meant that this bug wasn't triggered before. (it was triggered now because I sorted the list :-(). Fixed. Angus
Re: Update DVI bug still there
On Wed, 2002-05-01 at 04:04, Kayvan A. Sylvan wrote: > On Wed, May 01, 2002 at 01:36:01AM +0100, John Levon wrote: > > On Wed, May 01, 2002 at 02:24:51AM +0200, Lars Gullik Bjønnes wrote: > > > > > xdvi and gv watch the file to see if it changes. then reloads. > > > note that xdvi somethings needs some "event" f.ex. getting focus to > > > update, and gv needs some time. > > > > OK, so this is really a feature and the bug can be WORKSFORME yes ? > > No. > > My update DVI problem has nothing to do with XDVI or any other > piece of software that does not refresh itself. > > LaTeX is not run when it should be. > > I will investigate. I also see this with lyx-1.2.0pre4 source rpm, but I just recompiled from cvs now and there every thing seems to work as it should. Otto
Re: [PATCH] keeping aspect ratio in the LyX view of a graphic
Herbert Voss <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: > >> Herbert Voss <[EMAIL PROTECTED]> writes: >> | why? >> ... what is "type 1" anyway... >>> >> | 0: as is >> | 1: width/height >> | 2: scale >> then that is what it should say. >> I just hate non-descriptive constants. > > | cool ... | I never read that you said this about the figinset .. | which has only non-descriptive constants mostly because it was scheduled for replacement almost from the beginning. -- Lgb
I can't print
im running LyX in a debian system. i use CUPS as my print manager. When I print, this error comes up: lp: unable to print file: client-error-not-found where do you think is the problem? CUPS daemon is listening but it just won't print.. tia -- Jan Michael C Alonzo email: <[EMAIL PROTECTED]> Gnagloot, n.: A person who leaves all his ski passes on his jacket just to impress people. -- Rich Hall, "Sniglets" msg37508/pgp0.pgp Description: PGP signature
Re: [PATCH] keeping aspect ratio in the LyX view of a graphic
Lars Gullik Bjønnes wrote: > Herbert Voss <[EMAIL PROTECTED]> writes: > > | why? > >>>... what is "type 1" >>>anyway... >>> >> > | 0: as is > | 1: width/height > | 2: scale > > then that is what it should say. > I just hate non-descriptive constants. cool ... I never read that you said this about the figinset .. which has only non-descriptive constants Herbert -- http://www.lyx.org/help/
Character dialog + Afrikaans
maybe fixed already but opening char dialog in a new doc shows the language as Afrikaans (failed to set it to english) john -- "Please let's not resume the argument with the usual whining about how this feature will wipe out humanity or bring us to the promised land." - Charles Campbell on magic words in Subject: headers
Re: Mathed cursor goosed ??
On Wed, May 01, 2002 at 10:01:40AM +0100, Angus Leeming wrote:
> Attachment please.
oops
john
--
"Please let's not resume the argument with the usual whining about how this
feature will wipe out humanity or bring us to the promised land."
- Charles Campbell on magic words in Subject: headers
#LyX 1.2 created this file. For more info see http://www.lyx.org/
\lyxformat 220
\textclass article
\language english
\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 Formula $SOMEREBREB^{t43t43t43t_{4t43t43t}}$
\end_inset
\the_end
Re: [PATCH] keeping aspect ratio in the LyX view of a graphic
Herbert Voss <[EMAIL PROTECTED]> writes: | why? > >> ... what is "type 1" >> anyway... > > | 0: as is | 1: width/height | 2: scale then that is what it should say. I just hate non-descriptive constants. -- Lgb
Re: [PATCH] keeping aspect ratio in the LyX view of a graphic
Lars Gullik Bjønnes wrote: > | this does not depends to what we read, because LyX < 1.2.0 > | still saves both values. The keepLyXAspectratio is a feature > | for the future ... > > but the we do not need it for 1.2.0... should the gui be finished or not? it should ... > | with 1.2.0 read: > | -- > | \begin_inset Graphics FormatVersion 1 > | filename TEST/my_figure.eps > | display color > | size_type 1 > > hmm thse types need to be changed in 1.3.0CVS why? > ... what is "type 1" > anyway... 0: as is 1: width/height 2: scale Herbert -- http://www.lyx.org/help/
Re: compilation error lyx-1.2.0pre4
"Michael M. Tung" <[EMAIL PROTECTED]> writes:
| Hi all,
>
| I obtain the following compilation error for latest version
| 1.2.0pre4 (in the directory lyx-1.2.0pre4/src/support):
>
| source='lyxsum.C' object='lyxsum.lo' libtool=yes \
| depfile='.deps/lyxsum.Plo' tmpdepfile='.deps/lyxsum.TPlo' \
| depmode=gcc /bin/sh ../../config/depcomp \
| /bin/sh ../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I.
| -I../../src -I./../ -I../.. -I../.. -I../../boost -isystem
| /usr/X11R6/include -g -O -fno-rtti -fno-exceptions -W -Wall -c -o
| lyxsum.lo `test -f lyxsum.C || echo './'`lyxsum.C
| g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../.. -I../..
| -I../../boost -isystem /usr/X11R6/include -g -O -fno-rtti -fno-exceptions
| -W -Wall -c lyxsum.C -Wp,-MD,.deps/lyxsum.TPlo
| In file included from ../../boost/boost/crc.hpp:14,
| from lyxsum.C:14:
| ../../boost/boost/integer.hpp:58: Internal compiler error.
| ../../boost/boost/integer.hpp:58: Please submit a full bug report to
| `[EMAIL PROTECTED]'.
| ../../boost/boost/integer.hpp:58: See
| http://egcs.cygnus.com/faq.html#bugreport> for details.
| make: *** [lyxsum.lo] Error 1
>
| The relevant code would be in integer.hpp/line 58
>
| // integer templates specifying number of bits ---//
>
| // signed
| template< int Bits > // bits (including sign) required
| struct int_t
| {
| typedef typename int_least_helper
| <
| (Bits-1 <= std::numeric_limits::digits) +
| (Bits-1 <= std::numeric_limits::digits) +
| (Bits-1 <= std::numeric_limits::digits) +
| (Bits-1 <= std::numeric_limits::digits)
| >::least least;
| typedef typename int_fast_t::fast fast;
| };
>
| My compiler version is egcs-2.91.66 (which has some bugs). However,
| it's the first time I get this error (previous compilation ran
| smoothly). Maybe this comment can be useful for the next stable
| release.
as Angus says... but also: what previous compilation?
--
Lgb
Re: [PATCH] keeping aspect ratio in the LyX view of a graphic
Herbert Voss <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: > >> Angus Leeming <[EMAIL PROTECTED]> writes: >> | On Wednesday 01 May 2002 12:58 pm, Lars Gullik Bjønnes wrote: >> Angus Leeming <[EMAIL PROTECTED]> writes: | Attached is Herbert's patch from several days ago, stripped clean of all | other changes he sent. | | Looks pretty straightforward to me and works fine. | | Lars, what say you? Are you happy for this to go in or should it wait? It look ok to me, but remind me again what problem it solves. >> | Oh, someone on the users' list complained that the LyX-view and >> the | LaTeX-view were inconsistent without this and Herbert got busy. >> | Personally, I don't care if they are different. I guess that if >> goes in if | you decide that you're of the caring point- of view! >> I boils down to "How does 1.1.5 and 1.1.5 behave?". > > | this does not depends to what we read, because LyX < 1.2.0 | still saves both values. The keepLyXAspectratio is a feature | for the future ... but the we do not need it for 1.2.0... | Herbert > | with 1.1.6 | -- | \begin_inset Figure size 56 79 | file TEST/my_figure.eps | width 1 2 | flags 3 > | \end_inset | -- | with 1.2.0 read: | -- | \begin_inset Graphics FormatVersion 1 | filename TEST/my_figure.eps | display color | size_type 1 hmm thse types need to be changed in 1.3.0CVS... what is "type 1" anyway... | width 2cm | rotateOrigin center | lyxsize_type 1 ditto. | lyxwidth 56pt | lyxheight 79pt | \end_inset -- Lgb
Re: [PATCH] keeping aspect ratio in the LyX view of a graphic
Angus Leeming wrote:
> Of course I want to discuss something I don't understand. Now I understand
> what you mean, I'll adjust your comment so that future readers will
> understand it too.
>
> Incidentally, storing leftTop etc in the LyX file leads to this daft bit of
> code in insetgraphics.
>
> if (!params().rotateOrigin.empty()) {
> options << " origin=" << params().rotateOrigin[0];
> if (contains(params().rotateOrigin,"Top"))
> options << 't';
> else if (contains(params().rotateOrigin,"Bottom"))
> options << 'b';
> else if (contains(params().rotateOrigin,"Baseline"))
> options << 'B';
> options << ",\n";
> }
>
> Sigh. Why didn't we just store lt, lb, lB etc?
I understand what you want to say, but this is the other way
around. When I look into the lyxfile, than I know whats
going there, real names, no abbreviations.
ANd helping users to find problems is easier with "readable"
code.
Herbert
--
http://www.lyx.org/help/
Re: compilation error lyx-1.2.0pre4
There are two possible answers to this:
1. Lars Gullik Bjønnes (the guy in charge!) will tell you to upgrade your
compiler. egcs is an ancient C++ compiler and is nowhere near standard
compliant. Most people here are using a gcc 2.95+ compiler.
2. The more friendly answer is to tell you to ask Dekel Tsur
<[EMAIL PROTECTED]>. I understand that he's still using egcs.
Regards,
Angus
On Wednesday 01 May 2002 1:44 pm, Michael M. Tung wrote:
> Hi all,
>
> I obtain the following compilation error for latest version
> 1.2.0pre4 (in the directory lyx-1.2.0pre4/src/support):
>
> source='lyxsum.C' object='lyxsum.lo' libtool=yes \
> depfile='.deps/lyxsum.Plo' tmpdepfile='.deps/lyxsum.TPlo' \
> depmode=gcc /bin/sh ../../config/depcomp \
> /bin/sh ../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I.
> -I../../src -I./../ -I../.. -I../.. -I../../boost -isystem
> /usr/X11R6/include -g -O -fno-rtti -fno-exceptions -W -Wall -c -o
> lyxsum.lo `test -f lyxsum.C || echo './'`lyxsum.C
> g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../.. -I../..
> -I../../boost -isystem /usr/X11R6/include -g -O -fno-rtti -fno-exceptions
> -W -Wall -c lyxsum.C -Wp,-MD,.deps/lyxsum.TPlo
> In file included from ../../boost/boost/crc.hpp:14,
> from lyxsum.C:14:
> ../../boost/boost/integer.hpp:58: Internal compiler error.
> ../../boost/boost/integer.hpp:58: Please submit a full bug report to
> `[EMAIL PROTECTED]'.
> ../../boost/boost/integer.hpp:58: See
> http://egcs.cygnus.com/faq.html#bugreport> for details.
> make: *** [lyxsum.lo] Error 1
>
> The relevant code would be in integer.hpp/line 58
>
> // integer templates specifying number of bits
> ---//
>
> // signed
> template< int Bits > // bits (including sign) required
> struct int_t
> {
> typedef typename int_least_helper
> <
> (Bits-1 <= std::numeric_limits::digits) +
> (Bits-1 <= std::numeric_limits::digits) +
> (Bits-1 <= std::numeric_limits::digits) +
> (Bits-1 <= std::numeric_limits::digits)
>
> >::least least;
>
> typedef typename int_fast_t::fast fast;
> };
>
> My compiler version is egcs-2.91.66 (which has some bugs). However,
> it's the first time I get this error (previous compilation ran
> smoothly). Maybe this comment can be useful for the next stable
> release.
>
> Thanx for your help!
> Best,
>Michael
--
Dr Angus Leeming
Dept. of Bioengineering
Imperial College
London SW7 2BX
Tel +44 (0) 20 7594 5186
Fax +44 (0) 20 7584 6897
Re: [PATCH] keeping aspect ratio in the LyX view of a graphic
On Wednesday 01 May 2002 1:38 pm, Herbert Voss wrote:
> Angus Leeming wrote:
> > On Wednesday 01 May 2002 1:13 pm, Herbert Voss wrote:
> >>Angus Leeming wrote:
> >>>ps Herbert, you make me work bloody hard sometimes...
> >>
> >>I apologize, but only when you could apply this absolutely
> >>harmless patch ... :-)
> >>
> >>Herbert
> >
> > What does it achieve? They're only commentst and not even descriptive
> > ones at that.
>
> do you want a discussion about some characters of comments
>
> these comments are for bug-hunting or do you always know
> that leftBotton is send to latex as lb?
>
> HErbert
Of course I want to discuss something I don't understand. Now I understand
what you mean, I'll adjust your comment so that future readers will
understand it too.
Incidentally, storing leftTop etc in the LyX file leads to this daft bit of
code in insetgraphics.
if (!params().rotateOrigin.empty()) {
options << " origin=" << params().rotateOrigin[0];
if (contains(params().rotateOrigin,"Top"))
options << 't';
else if (contains(params().rotateOrigin,"Bottom"))
options << 'b';
else if (contains(params().rotateOrigin,"Baseline"))
options << 'B';
options << ",\n";
}
Sigh. Why didn't we just store lt, lb, lB etc?
Ok, I'll add your patch.
Angus
compilation error lyx-1.2.0pre4
Hi all,
I obtain the following compilation error for latest version
1.2.0pre4 (in the directory lyx-1.2.0pre4/src/support):
source='lyxsum.C' object='lyxsum.lo' libtool=yes \
depfile='.deps/lyxsum.Plo' tmpdepfile='.deps/lyxsum.TPlo' \
depmode=gcc /bin/sh ../../config/depcomp \
/bin/sh ../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I.
-I../../src -I./../ -I../.. -I../.. -I../../boost -isystem
/usr/X11R6/include -g -O -fno-rtti -fno-exceptions -W -Wall -c -o
lyxsum.lo `test -f lyxsum.C || echo './'`lyxsum.C
g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../.. -I../..
-I../../boost -isystem /usr/X11R6/include -g -O -fno-rtti -fno-exceptions
-W -Wall -c lyxsum.C -Wp,-MD,.deps/lyxsum.TPlo
In file included from ../../boost/boost/crc.hpp:14,
from lyxsum.C:14:
../../boost/boost/integer.hpp:58: Internal compiler error.
../../boost/boost/integer.hpp:58: Please submit a full bug report to
`[EMAIL PROTECTED]'.
../../boost/boost/integer.hpp:58: See
http://egcs.cygnus.com/faq.html#bugreport> for details.
make: *** [lyxsum.lo] Error 1
The relevant code would be in integer.hpp/line 58
// integer templates specifying number of bits ---//
// signed
template< int Bits > // bits (including sign) required
struct int_t
{
typedef typename int_least_helper
<
(Bits-1 <= std::numeric_limits::digits) +
(Bits-1 <= std::numeric_limits::digits) +
(Bits-1 <= std::numeric_limits::digits) +
(Bits-1 <= std::numeric_limits::digits)
>::least least;
typedef typename int_fast_t::fast fast;
};
My compiler version is egcs-2.91.66 (which has some bugs). However,
it's the first time I get this error (previous compilation ran
smoothly). Maybe this comment can be useful for the next stable
release.
Thanx for your help!
Best,
Michael
Re: [PATCH] keeping aspect ratio in the LyX view of a graphic
Angus Leeming wrote: > On Wednesday 01 May 2002 1:13 pm, Herbert Voss wrote: > >>Angus Leeming wrote: >> >>>ps Herbert, you make me work bloody hard sometimes... >>> >>I apologize, but only when you could apply this absolutely >>harmless patch ... :-) >> >>Herbert >> > > What does it achieve? They're only commentst and not even descriptive ones at > that. do you want a discussion about some characters of comments these comments are for bug-hunting or do you always know that leftBotton is send to latex as lb? HErbert -- http://www.lyx.org/help/
Re: [PATCH] keeping aspect ratio in the LyX view of a graphic
Lars Gullik Bjønnes wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > > | On Wednesday 01 May 2002 12:58 pm, Lars Gullik Bjønnes wrote: > >>>Angus Leeming <[EMAIL PROTECTED]> writes: >>>| Attached is Herbert's patch from several days ago, stripped clean of all >>>| other changes he sent. >>>| >>>| Looks pretty straightforward to me and works fine. >>>| >>>| Lars, what say you? Are you happy for this to go in or should it wait? >>> >>>It look ok to me, but remind me again what problem it solves. >>> > | Oh, someone on the users' list complained that the LyX-view and the > | LaTeX-view were inconsistent without this and Herbert got busy. > > | Personally, I don't care if they are different. I guess that if goes in if > | you decide that you're of the caring point- of view! > > I boils down to "How does 1.1.5 and 1.1.5 behave?". this does not depends to what we read, because LyX < 1.2.0 still saves both values. The keepLyXAspectratio is a feature for the future ... Herbert with 1.1.6 -- \begin_inset Figure size 56 79 file TEST/my_figure.eps width 1 2 flags 3 \end_inset -- with 1.2.0 read: -- \begin_inset Graphics FormatVersion 1 filename TEST/my_figure.eps display color size_type 1 width 2cm rotateOrigin center lyxsize_type 1 lyxwidth 56pt lyxheight 79pt \end_inset -- http://www.lyx.org/help/
Re: [PATCH] keeping aspect ratio in the LyX view of a graphic
On Wednesday 01 May 2002 1:18 pm, Lars Gullik Bjønnes wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > | On Wednesday 01 May 2002 12:58 pm, Lars Gullik Bjønnes wrote: > >> Angus Leeming <[EMAIL PROTECTED]> writes: > >> | Attached is Herbert's patch from several days ago, stripped clean of > >> | all other changes he sent. > >> | > >> | Looks pretty straightforward to me and works fine. > >> | > >> | Lars, what say you? Are you happy for this to go in or should it wait? > >> > >> It look ok to me, but remind me again what problem it solves. > | > | Oh, someone on the users' list complained that the LyX-view and the > | LaTeX-view were inconsistent without this and Herbert got busy. > | > | Personally, I don't care if they are different. I guess that if goes in > | if you decide that you're of the caring point- of view! > > I boils down to "How does 1.1.5 and 1.1.5 behave?". Badly ;-) The user could not display the image in LyX with a size different to that in LaTeX. Now he can, so really your question doesn't apply; there's more functionality available now. So really, it boils down to Herbert's philosophy point. Angus
Re: [PATCH] keeping aspect ratio in the LyX view of a graphic
On Wednesday 01 May 2002 1:13 pm, Herbert Voss wrote: > Angus Leeming wrote: > > ps Herbert, you make me work bloody hard sometimes... > > I apologize, but only when you could apply this absolutely > harmless patch ... :-) > > Herbert What does it achieve? They're only commentst and not even descriptive ones at that. A
Re: [PATCH] keeping aspect ratio in the LyX view of a graphic
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | Angus Leeming <[EMAIL PROTECTED]> writes: > | | On Wednesday 01 May 2002 12:58 pm, Lars Gullik Bjønnes wrote: >>> Angus Leeming <[EMAIL PROTECTED]> writes: >>> | Attached is Herbert's patch from several days ago, stripped clean of all >>> | other changes he sent. >>> | >>> | Looks pretty straightforward to me and works fine. >>> | >>> | Lars, what say you? Are you happy for this to go in or should it wait? >>> >>> It look ok to me, but remind me again what problem it solves. >> | | Oh, someone on the users' list complained that the LyX-view and the | | LaTeX-view were inconsistent without this and Herbert got busy. >> | | Personally, I don't care if they are different. I guess that if goes in if | | you decide that you're of the caring point- of view! > | I boils down to "How does 1.1.5 and 1.1.5 behave?". ... and 1.1.6... obviously. -- Lgb
Re: [PATCH] keeping aspect ratio in the LyX view of a graphic
Angus Leeming wrote:
> ps Herbert, you make me work bloody hard sometimes...
I apologize, but only when you could apply this absolutely
harmless patch ... :-)
Herbert
--
http://www.lyx.org/help/
Index: src/frontends/controllers/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/ChangeLog,v
retrieving revision 1.170
diff -u -r1.170 ChangeLog
--- src/frontends/controllers/ChangeLog 1 May 2002 09:25:51 - 1.170
+++ src/frontends/controllers/ChangeLog 1 May 2002 10:51:38 -
@@ -1,3 +1,8 @@
+2002-04-28 Herbert Voss <[EMAIL PROTECTED]>
+
+ * ControlGraphic.[Ch] : adding the LaTeX shortcuts as
+ commands
+
2002-04-30 Angus Leeming <[EMAIL PROTECTED]>
* ControlGraphics.[Ch] (getRotationOriginData): new helper function.
Index: src/frontends/controllers/ControlGraphics.C
===
RCS file:
/usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/ControlGraphics.C,v
retrieving revision 1.35
diff -u -r1.35 ControlGraphics.C
--- src/frontends/controllers/ControlGraphics.C 1 May 2002 09:25:51 - 1.35
+++ src/frontends/controllers/ControlGraphics.C 1 May 2002 10:51:39 -
@@ -188,9 +188,11 @@
namespace {
char const * const rorigin_latex_strs[] = {
- "center", "leftTop", "leftBottom", "leftBaseline",
- "centerTop", "centerBottom", "centerBaseline",
- "rightTop", "rightBottom", "rightBaseline" };
+ // as comment the LaTeX shortcuts
+ "center", // c
+ "leftTop", "leftBottom", "leftBaseline",// lt lb lB
+ "centerTop", "centerBottom", "centerBaseline", // ct cb cB
+ "rightTop", "rightBottom", "rightBaseline" }; // rt rb rB
char const * const rorigin_gui_strs[] = {
N_("center"),
Re: [PATCH] keeping aspect ratio in the LyX view of a graphic
Angus Leeming <[EMAIL PROTECTED]> writes: | On Wednesday 01 May 2002 12:58 pm, Lars Gullik Bjønnes wrote: >> Angus Leeming <[EMAIL PROTECTED]> writes: >> | Attached is Herbert's patch from several days ago, stripped clean of all >> | other changes he sent. >> | >> | Looks pretty straightforward to me and works fine. >> | >> | Lars, what say you? Are you happy for this to go in or should it wait? >> >> It look ok to me, but remind me again what problem it solves. > | Oh, someone on the users' list complained that the LyX-view and the | LaTeX-view were inconsistent without this and Herbert got busy. > | Personally, I don't care if they are different. I guess that if goes in if | you decide that you're of the caring point- of view! I boils down to "How does 1.1.5 and 1.1.5 behave?". -- Lgb
Re: [PATCH] keeping aspect ratio in the LyX view of a graphic
On Wednesday 01 May 2002 12:58 pm, Lars Gullik Bjønnes wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > | Attached is Herbert's patch from several days ago, stripped clean of all > | other changes he sent. > | > | Looks pretty straightforward to me and works fine. > | > | Lars, what say you? Are you happy for this to go in or should it wait? > > It look ok to me, but remind me again what problem it solves. Oh, someone on the users' list complained that the LyX-view and the LaTeX-view were inconsistent without this and Herbert got busy. Personally, I don't care if they are different. I guess that if goes in if you decide that you're of the caring point- of view! Angus
Re: [PATCH] keeping aspect ratio in the LyX view of a graphic
Lars Gullik Bjønnes wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > > | Attached is Herbert's patch from several days ago, stripped clean of all > | other changes he sent. > > | Looks pretty straightforward to me and works fine. > > | Lars, what say you? Are you happy for this to go in or should it wait? > > It look ok to me, but remind me again what problem it solves. I forgot the "Keep Aspect Ratio" for the lyxview of images. it's a question of philosophy to say that it solves a problem the graphics gui is still in a phase of testing and it seems that there are are no "real problems" except the easy_to_fix_one one with the 64bit color. This testing includes the gui, too. hope, this helps ... ;-) Herbert -- http://www.lyx.org/help/
Re: [PATCH] keeping aspect ratio in the LyX view of a graphic
Angus Leeming <[EMAIL PROTECTED]> writes: | Attached is Herbert's patch from several days ago, stripped clean of all | other changes he sent. > | Looks pretty straightforward to me and works fine. > | Lars, what say you? Are you happy for this to go in or should it wait? It look ok to me, but remind me again what problem it solves. -- Lgb
Re: Some unconverted "Standard"s
John Levon <[EMAIL PROTECTED]> writes: | On Mon, Apr 29, 2002 at 05:14:38PM +0200, Lars Gullik Bjønnes wrote: > >> I found these and thing they should be changed. >> Does the following patch look ok? > | Dunno if it's this patch, but here's one way to crash : > | start a new doc, enter some normal text in par 1. > | Start a new par, and set it to Subsection. Now insert an index list | in this par (this will reset to Standard). Now click before the index | button, and reset it to Subsection. Now start typing. Observe drawing | errors as the cursor is somehow on the line above. As soon as you go | past the end of the line above, ->BOOM > | #4 0x81e1d43 in void lyx::Assert (assertion=false) at LAssert.h:33 | #5 0x80cbf31 in Paragraph::Pimpl::getChar (this=0x83bdf40, pos=29) at |paragraph_pimpl.C:92 > | Can you look Lars ? Ok, this is a bug, but it also is a case of "do not do that then". First of al it should not be allowed to change the layout of the par where the index resides. Also no text should be allowed with the indexlist inset at all... -- Lgb
Re: [PATCH] Internationalising the rotation origin strings in the graphics dialog
On Wednesday 01 May 2002 12:30 pm, Lars Gullik Bjønnes wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > | On Tuesday 30 April 2002 6:03 pm, John Levon wrote: > >> On Tue, Apr 30, 2002 at 06:02:03PM +0100, Angus Leeming wrote: > >> > Patch is large smply because I moved the findPos template to one place > >> > rather than four. > >> > >> Actually it's remarkably slender > >> > >> john > | > | Doh. > | A > > Have this patch been applied? Yes, this morning. Angus
Re: [PATCH] Internationalising the rotation origin strings in thegraphics dialog
Angus Leeming <[EMAIL PROTECTED]> writes: | On Tuesday 30 April 2002 6:03 pm, John Levon wrote: >> On Tue, Apr 30, 2002 at 06:02:03PM +0100, Angus Leeming wrote: >> > Patch is large smply because I moved the findPos template to one place >> > rather than four. >> >> Actually it's remarkably slender >> >> john > | Doh. | A Have this patch been applied? -- Lgb
[PATCH] keeping aspect ratio in the LyX view of a graphic
Attached is Herbert's patch from several days ago, stripped clean of all other changes he sent. Looks pretty straightforward to me and works fine. Lars, what say you? Are you happy for this to go in or should it wait? Angus ps Herbert, you make me work bloody hard sometimes... pps This leaves only the tooltips for the graphics dialog to be considered, right? A keeplyxaspectratio.diff.gz Description: GNU Zip compressed data
Re: [PATCH] Layout/Preferences: Other->Custom & US Page size consistent
On Wednesday 01 May 2002 11:09 am, R. Lahaye wrote: > Angus Leeming writes: > > On Wednesday 01 May 2002 10:35 am, R. Lahaye wrote: > > > It's actually like this: exchange "US letter" and "A4" in the list and > > > you'll get the letter layout when clicking on A4, and v.v. Apparently > > > only the order is important (A4 is number such and such in the list) > > > and the real page size is picked from another list, number such and > > > such. > > > > Indeed. Using the same mechanism as is used by f.ex the character dialog. > > (Receives a vector > from it's controller.) > > So my patch is totally safe with respect to Herbert's worries about > the space in "US letter". Anything will do here, "USletter", "US letter", > or even "You as ladder", would all select the letter layout, as long as > it's not moved to another place in the list :). > > Rob. Yes. That's why it's been committed. ;-) Angus
Re: Worm Klez.E immunity
Perhaps amavis could help? -- Lgb
Re: [PATCH] Layout/Preferences: Other->Custom & US Page size consistent
On Wednesday 01 May 2002 10:35 am, R. Lahaye wrote: > Angus Leeming writes: > > On Tuesday 30 April 2002 8:42 pm, Herbert Voss wrote: > > > > On Tuesday 30 April 2002 2:33 pm, R. Lahaye wrote: > > > >>This patch includes this and it makes the US page sizes > > > >>consistent; of the form "US [type]", in both, Preferences and > > > >>Document Layout. > > > > > > > > Nice work. Applied in my tree. > > > > > > are you sure, that there are no problems with the space, because > > > preferences is valid in all parts of LyX? > > > > > > Herbert > > > > I've been taking my time for exactly this reason. It transpires that none > > of the choices are used verbatim. Ie, the strings don't matter to LyX. > > It's actually like this: exchange "US letter" and "A4" in the list and > you'll get the letter layout when clicking on A4, and v.v. Apparently > only the order is important (A4 is number such and such in the list) and > the real page size is picked from another list, number such and such. > > I wanted to synchronize the order of the page sizes in Preferences and > Document Layout, but failed because I couldn't to find "the other list" > with the real page sizes. We should change this setup, so that A4 > automatically connects to its A4 page size, without using its position > in the page size list! > > Regards, > Rob. Indeed. Using the same mechanism as is used by f.ex the character dialog. (Receives a vector > from it's controller.) 1.3 Angus
Re: Language specific crash in LyX 1.2.0cvs
tir, 2002-04-30 kl. 17:47 skrev John Levon: > Can you please provide a screenshot. I've tried varying line lengths and > am unable to cause any problems Sure. This picture were made after: * Opening LyX * Deactivating "Rescale bitmap fonts" (so the bug351-file will load) * Opening bug351-2.lyx * Reactivating "Rescale bitmap fonts" (if this was done from the beginning, the file would'nt load.) I suspect the bug happen as the picture is loaded: First the graphics container adjusts its size to the text: "Converting to loadable format...", requiering the line to break. Shortly after the container shrinks to fit the text "No file found!", which cause the line to unbreak. LyX does'nt seem to handle this gracefully. Claus bug351.png Description: PNG image
Re: Mathed cursor goosed ??
On Wednesday 01 May 2002 5:18 am, John Levon wrote: > Load the attached then do export->ascii. The cursor ends up > above the top of the document somehow. > > Also the ascii export is not too stellar : > >t43t43t43t > 4t43t43t > > > > > > > > SOMEREBREB > > > ?? > > john Attachment please. Angus
Re: browse-pattern in graphics-gui
Angus Leeming wrote: > On Tuesday 30 April 2002 8:39 pm, Herbert Voss wrote: > >>this patch is fishy, because we get a list of ALL >>formats, inclusive latex, dvi, but we only want >>the graphic formats >> >>http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg36850.html >>http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg36815.html >> >>Herbert >> > > You're getting these patterns for the same reason that you got EPS, PNG etc > in the list of exportable formats. The converter path from a loadable format > to latex obviously exists. sure, but it's annoying to have a wrong endless list there. than we can have the easy one * Herbert -- http://www.lyx.org/help/
Re: [PATCH] Layout/Preferences: Other->Custom & US Page size consistent
On Tuesday 30 April 2002 8:42 pm, Herbert Voss wrote: > Angus Leeming wrote: > > On Tuesday 30 April 2002 2:33 pm, R. Lahaye wrote: > >>Hi, > >> > >>This patch makes my earlier patch redundant (the one that > >>changed the pulldown choice "Other" into "Custom" in Doc Layout). > >> > >>This patch includes this and it makes the US page sizes > >>consistent; of the form "US [type]", in both, Preferences and > >>Document Layout. > >> > >>On the fly I adjusted a few style inconsistencies in Preferences > >>and Document xform. > >> > >>The patch contains merely text/string changes, no code change. > >> > >>Patch attached. > >> > >>Rob. > > > > Nice work. Applied in my tree. > > are you sure, that there are no problems with the space, because > preferences is valid in all parts of LyX? > > Herbert I've been taking my time for exactly this reason. It transpires that none of the choices are used verbatim. Ie, the strings don't matter to LyX. Angus
