Re: Unlocalizable menu entries
On ke, 2002-03-27 at 02:01, Jean-Marc Lasgouttes wrote: Pauli Virtanen wrote: Hello, Currently (as in CVS) the entries (e.g. Table, Figure, etc.) in Insert-Floats menu cannot be translated. They also appear in Navigate menu. I think that these should be made translatable since they are quite visible to the user. There are also some not-so-visible untranslatable strings in the type list (TOC, figure, ...) in table of contents dialog. Should be fixed after my next commit. I'm sorry I forgot to mention that these same strings also appear untranslated in Insert-Lists TOC menu. Adding _() around cit-second.name() on src/MenuBackend.C:380 seems to fix this. -- Pauli Virtanen -- mailto:[EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: minipage wierdness
On 28-Mar-2002 Garst R. Reese wrote: bring it up to: |minipage|--|minipage| With the new code, the backspace deleted the hfill, and it was tricky to ge the cursor in the right place to re-insert it. That is why I Enter first minipage and press ESC that should bring you at the right position, shouldn't it? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Whistler's Law: You never know who is right, but you always know who is in charge.
Re: Unlocalizable menu entries
On to, 2002-03-28 at 11:08, Pauli Virtanen wrote: On ke, 2002-03-27 at 02:01, Jean-Marc Lasgouttes wrote: Pauli Virtanen wrote: Hello, Currently (as in CVS) the entries (e.g. Table, Figure, etc.) in Insert-Floats menu cannot be translated. They also appear in Navigate menu. I think that these should be made translatable since they are quite visible to the user. There are also some not-so-visible untranslatable strings in the type list (TOC, figure, ...) in table of contents dialog. Should be fixed after my next commit. I'm sorry I forgot to mention that these same strings also appear untranslated in Insert-Lists TOC menu. Adding _() around cit-second.name() on src/MenuBackend.C:380 seems to fix this. And guiName on src/insets/insetfloatlist.C:38 should probably also have _() to translate the strings appearing in inset boxes. -- Pauli Virtanen -- mailto:[EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: More eye candy
John == John Levon [EMAIL PROTECTED] writes: I thought that all toolbar in KDE apps were supposed to be setable by the user as floating top, bottom, whatever... However, we could have John right, but it is up to the app to store the state of the session John ... Feel free to have a qt2-specific pref file. Angus already did that for setting xforms-specific colors. John I don't get you. I am trying to /expand/ a menu. This will crash John if there's no buffer currently : see expand:ExportFormats John besides, the menu code should not know about buffers, readonly John etc. - the core should provide only enabled/disabled info for John this. (as it does now afaik) I see now. Why did not yoou say it upfront: there is a bug in Menubackend::expand! It should be fixed in cvs. Undoubtedly, you will find many of those, since you are bound to do things differently that what I did. Yes, but we will have to eventually find a solution. John couldn't we connecto to Angu's updateParagraph signal ? That John seems good enough doesn't it ? Or does it not do what it sounds John like ? Maybe, I do not know this code. Convince me. John I would if I was sure myself ... That's the point. I am not either. John I certainly think we can take a signal approach for say, John lastfiles. It's easy to do and not intrusive I don't think. Don't bother with it. generating this does not cost anything. The only proble is with the various TOCS, I think (although I'd like to have hard numbers on a large file: how much does TOC generation cost?). If menubackend where to cache the TOCS, using some signal, would regenerating the menus at each Menu::update() really cost too much? The time will depend on the number of headings, not number of paragraphs in document. JMarc
Re: lyx-devel lib/: ChangeLog lib/layouts/: kluwer.layout
[EMAIL PROTECTED] wrote: Log message: small fix to kluwer style I thought that a TocDepth -1 is the right value to get no counting. but maybe I'm wrong and it works with 0 Herbert -- http://www.lyx.org/help/
[PATCH] more length-stuff
the last one (hopefully):
1. simplifies the code: use always the choice from
xforms_helpers and don't build them everytime new
2. reorder the choicelist to get the most common length
first and move the excotic ones to the end
Herbert
--
http://www.lyx.org/help/
Index: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.651
diff -u -r1.651 ChangeLog
--- src/ChangeLog 27 Mar 2002 23:27:12 - 1.651
+++ src/ChangeLog 28 Mar 2002 10:44:51 -
@@ -1,3 +1,8 @@
+2002-03-28 Herbert Voss [EMAIL PROTECTED]
+
+ * lengthcommon.C: change the order of the length to get
+ a one which shows the most common ones first
+
2002-03-28 Herbert Voss [EMAIL PROTECTED]
* lyxlength.C: compatibility stuff for old 1.2.0 files which
Index: src/lengthcommon.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lengthcommon.C,v
retrieving revision 1.3
diff -u -r1.3 lengthcommon.C
--- src/lengthcommon.C 27 Mar 2002 12:27:17 - 1.3
+++ src/lengthcommon.C 28 Mar 2002 10:44:51 -
@@ -6,9 +6,11 @@
// I am not sure if mu should be possible to select (Lgb)
char const * unit_name[num_units] = {
- sp, pt, bp, dd, mm, pc, cc, cm,
- in, ex, em, mu,
- text%, col%, page%, line% };
+ cm, mm, in, // standard
+ col%, line%, text%, page%, // relative
+ ex, em, // TeX
+ pt, sp, bp, // other
+ dd, pc, cc, mu }; // excotic
LyXLength::UNIT unitFromString(string const data)
Index: src/frontends/xforms/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/ChangeLog,v
retrieving revision 1.338
diff -u -r1.338 ChangeLog
--- src/frontends/xforms/ChangeLog 27 Mar 2002 12:27:17 - 1.338
+++ src/frontends/xforms/ChangeLog 28 Mar 2002 10:44:53 -
@@ -1,3 +1,13 @@
+2002-03-28 Herbert Voss [EMAIL PROTECTED]
+
+ * FormMinipage.C:
+ * FormDocument.C:
+ * FormParagraph.C: use the Length-choices from xforms_helpers.h
+ and don't build these new.
+
+ * xforms_helpers.h: change the order of the length to get
+ a one which shows the most common ones first
+
2002-03-27 Herbert Voss [EMAIL PROTECTED]
* xforms_helpers.h:
Index: src/frontends/xforms/FormDocument.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/FormDocument.C,v
retrieving revision 1.93
diff -u -r1.93 FormDocument.C
--- src/frontends/xforms/FormDocument.C 21 Mar 2002 21:18:02 - 1.93
+++ src/frontends/xforms/FormDocument.C 28 Mar 2002 10:44:53 -
@@ -136,31 +136,24 @@
// Create the contents of the unit choices
// Don't include the % terms...
- vectorstring units_vec = getLatexUnits();
-#if 0
- for (vectorstring::iterator it = units_vec.begin();
-it != units_vec.end(); ++it) {
- if (contains(*it, %))
- it = units_vec.erase(it, it+1) - 1;
- }
-#else
- vectorstring::iterator ret =
- std::remove_if(units_vec.begin(),
- units_vec.end(),
- bind2nd(contains_functor(), %));
- units_vec.erase(ret, units_vec.end());
-#endif
- string units = getStringFromVector(units_vec, |);
-
- fl_addto_choice(paper_-choice_custom_width_units, units.c_str());
- fl_addto_choice(paper_-choice_custom_height_units, units.c_str());
- fl_addto_choice(paper_-choice_top_margin_units,units.c_str());
- fl_addto_choice(paper_-choice_bottom_margin_units, units.c_str());
- fl_addto_choice(paper_-choice_inner_margin_units, units.c_str());
- fl_addto_choice(paper_-choice_outer_margin_units, units.c_str());
- fl_addto_choice(paper_-choice_head_height_units, units.c_str());
- fl_addto_choice(paper_-choice_head_sep_units, units.c_str());
- fl_addto_choice(paper_-choice_foot_skip_units, units.c_str());
+ fl_addto_choice(paper_-choice_custom_width_units,
+ choice_Length_WithUnit.c_str());
+ fl_addto_choice(paper_-choice_custom_height_units,
+ choice_Length_WithUnit.c_str());
+ fl_addto_choice(paper_-choice_top_margin_units,
+ choice_Length_WithUnit.c_str());
+ fl_addto_choice(paper_-choice_bottom_margin_units,
+ choice_Length_WithUnit.c_str());
+ fl_addto_choice(paper_-choice_inner_margin_units,
+ choice_Length_WithUnit.c_str());
+ fl_addto_choice(paper_-choice_outer_margin_units,
+ choice_Length_WithUnit.c_str());
+
Re: [PATCH] Speed up parsing of documents
Allan == Allan Rae [EMAIL PROTECTED] writes:
Allan On Thu, 28 Mar 2002, Jean-Marc Lasgouttes wrote: [...]
Therefore I moved the fonts, insets and backslash (useful for ERT)
tests to the top of the method.
The result is that Buffer::parseSingleLyXformat2Token takes 16.2%
of the time, and the 404503 string comparisons now take less time
than InsertChar, which makes more sense.
Allan Clever optimisation.
However, it seem that the huge amount of font tokens we get in this
case is related to the fact that textinsets do not make any effort to
reduce their fonts agains outside world (look at UserGuide.lyx...).
Presumably the code should differentiate between insets which inherit
font from the outside (are there some) and those who reset fonts.
There is really a lot of bloat in lyx files due to that.
I attach the patch instead of commiting it, because I want to have
a virtual nod from Lars before. I would not want to break the
carefully crafted compatibility reading...
Allan Just looking at the patch I notice that there seems to be some
Allan nesting of preprocessor directives like:
Allan #ifndef NO_COMPATABILITY + ... + #ifndef NO_COMPATABILITY + ...
Allan + #endif + ...
Oops! It was probably too late in the evening to re-read my patch. Try
this one instead. Lars, would that be OK?
ANother candidate would be Paragraph::insertChar, which is called a
lot during parsing (and maybe other places) for inserting at the end
of paragraph. Obviously in this case there is no need to search/update
the fonttable/insettable. Luckily enough for 1.2.0 release date, I
will not have time to look at it :)
JMarc
Index: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.651
diff -u -p -r1.651 ChangeLog
--- src/ChangeLog 27 Mar 2002 23:27:12 - 1.651
+++ src/ChangeLog 28 Mar 2002 10:54:34 -
@@ -1,3 +1,9 @@
+2002-03-28 Jean-Marc Lasgouttes [EMAIL PROTECTED]
+
+ * buffer.C (parseSingleLyXformat2Token): reorder a bit the tests
+ in order to reduce drastically the number of comparisons needed to
+ parse a large document
+
2002-03-27 Jean-Marc Lasgouttes [EMAIL PROTECTED]
* lyxfunc.C (getStatus): return 'disabled' early for LFUN_NOACTION
Index: src/buffer.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/buffer.C,v
retrieving revision 1.322
diff -u -p -r1.322 buffer.C
--- src/buffer.C 25 Mar 2002 11:15:25 - 1.322
+++ src/buffer.C 28 Mar 2002 10:54:34 -
@@ -563,6 +563,102 @@ Buffer::parseSingleLyXformat2Token(LyXLe
}
#endif
+ } else if (token == \\end_inset) {
+ lyxerr Solitary \\end_inset. Missing \\begin_inset?.\n
+ Last inset read was: last_inset_read
+ endl;
+ // Simply ignore this. The insets do not have
+ // to read this.
+ // But insets should read it, it is a part of
+ // the inset isn't it? Lgb.
+ } else if (token == \\begin_inset) {
+#ifndef NO_COMPABILITY
+ insertErtContents(par, pos, false);
+ ert_stack.push(ert_comp);
+ ert_comp = ErtComp();
+#endif
+ readInset(lex, par, pos, font);
+#ifndef NO_COMPABILITY
+ ert_comp = ert_stack.top();
+ ert_stack.pop();
+ insertErtContents(par, pos);
+#endif
+ } else if (token == \\family) {
+ lex.next();
+ font.setLyXFamily(lex.getString());
+ } else if (token == \\series) {
+ lex.next();
+ font.setLyXSeries(lex.getString());
+ } else if (token == \\shape) {
+ lex.next();
+ font.setLyXShape(lex.getString());
+ } else if (token == \\size) {
+ lex.next();
+ font.setLyXSize(lex.getString());
+#ifndef NO_COMPABILITY
+ } else if (token == \\latex) {
+ lex.next();
+ string const tok = lex.getString();
+ if (tok == no_latex) {
+ // Do the insetert.
+ insertErtContents(par, pos);
+ } else if (tok == latex) {
+ ert_comp.active = true;
+ ert_comp.font = font;
+ } else if (tok == default) {
+ // Do the insetert.
+ insertErtContents(par, pos);
+ } else {
+ lex.printError(Unknown LaTeX font flag
+ `$$Token');
+ }
+#endif
+ } else if (token == \\lang) {
+ lex.next();
+ string const tok = lex.getString();
+ Language const * lang = languages.getLanguage(tok);
+ if (lang) {
+ font.setLanguage(lang);
+ } else {
+ font.setLanguage(params.language);
+ lex.printError(Unknown language `$$Token');
+ }
+ } else if (token == \\numeric) {
+ lex.next();
+ font.setNumber(font.setLyXMisc(lex.getString()));
+ } else if (token == \\emph) {
+ lex.next();
+ font.setEmph(font.setLyXMisc(lex.getString()));
+ } else if (token == \\bar) {
+ lex.next();
+ string const tok = lex.getString();
+ // This is dirty, but gone with LyX3. (Asger)
+ if (tok == under)
+ font.setUnderbar(LyXFont::ON);
+ else if (tok == no)
+ font.setUnderbar(LyXFont::OFF);
+ else if (tok == default)
+ font.setUnderbar(LyXFont::INHERIT);
+ else
+ lex.printError(Unknown bar font flag
+ `$$Token');
+ } else if (token
Re: minipage wierdness
Herbert == Herbert Voss [EMAIL PROTECTED] writes: Herbert Garst R. Reese wrote: At the time of the %t - %text patch, something went weird with my mini-pages. Two minipages with 44%t separated by an hfil used to appear side by side in lyx. The %t went to pt, but changing it to %text made one appear under the other and lost half of the minipages. This could also be related to the isLineSeparator stuff. Definitely a regression. Herbert try the patch. Do we really want that? These units only appeared in 1.2.0cvs, right? In this case, we do not want code for compatibility with non-released versions. If this is needed for 1.1.x files, things are different. JMarc
Re: minipage wierdness
Garst == Garst R Reese [EMAIL PROTECTED] writes: Garst This could also be related to the Garst isLineSeparator stuff. Definitely a regression. All the isLineSeparator stuff did is disable the code which allowed for line breaks after Menu Separator or hyphenation marker. If you do not have one of those, it is irrelevant. JMarc
Re: [PATCH] simplify code
Herbert == Herbert Voss [EMAIL PROTECTED] writes:
Herbert here is a real latex solution for a output when a graphic
Herbert file doesn't exist. In this case I set the boundingbox to
Herbert external values and the draft mode. Than we can have any
Herbert possible filename and need no translation like latexify() or
Herbert tricks with \verb{}. latex does it all: puts an rectangle
Herbert with filename not found in it.
THis a great idea... However, could you update the code to either not
add \n in the command or account for them in the return value of the
method (I prefer the first solution).
As it is, it _seems_ to me (I have not tried it) that it will confuse
the error insets placement.
JMarc
Re: Breaking paragraph in a keepempty Section
On Thu, 28 Mar 2002 02:04:18 + wrote John Levon [EMAIL PROTECTED]: If this is the case why on earth didn't you open a bug ?! Becouse I am lazy (and did not have access when I recovered this one). However, now I did: http://bugzilla.lyx.org/show_bug.cgi?id=313 Guenter -- [EMAIL PROTECTED]
Re: [PATCH] Speed up parsing of documents
On Thu, Mar 28, 2002 at 12:21:20PM +0100, Jean-Marc Lasgouttes wrote: However, it seem that the huge amount of font tokens we get in this case is related to the fact that textinsets do not make any effort to reduce their fonts agains outside world (look at UserGuide.lyx...). Presumably the code should differentiate between insets which inherit font from the outside (are there some) and those who reset fonts. There is really a lot of bloat in lyx files due to that. I fiddled around with font insets for mathed lately, and by now I am fairly convinced that this is the Right Thing to do. It is much more logical Markup, it is basically what LaTeX does, and it is what Docbook does (if that's what José said). I don't think it is what conventional word processors do, but to be honest, I don't care. I don't know how big a change this would be for 'main LyX', as it is already such a big change for mathed that I won't try to sneak it into 1.2.0 [and new insets are really easy in mathed nowadays...] The change, however, _is_ nice: It's about 200 lines _less_ code right now and it removes almost all font related hacks (like passing a font change through macro arguments...). So the change just 'feels good'. ANother candidate would be Paragraph::insertChar, which is called a lot during parsing (and maybe other places) for inserting at the end of paragraph. Obviously in this case there is no need to search/update the fonttable/insettable. Luckily enough for 1.2.0 release date, I will not have time to look at it :) This problem, e.g. is magically solved by simply doing font related stuff only if drawing is requested. Just push_back() the char to the container... - For the 'speed of string comparison matter': Somewhere in one of my older projects I had some class wrapping a 'const char *' and a hash values of the string for exactly that purpose. I seem to remember a speedup of four or five or so. So if this is really crucial, I can dig this out (or re-invent the wheel which is probably better for the stomach contents than looking at six years old code...) 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: minipage wierdness
Jean-Marc Lasgouttes wrote: Herbert == Herbert Voss [EMAIL PROTECTED] writes: Herbert Garst R. Reese wrote: At the time of the %t - %text patch, something went weird with my mini-pages. Two minipages with 44%t separated by an hfil used to appear side by side in lyx. The %t went to pt, but changing it to %text made one appear under the other and lost half of the minipages. This could also be related to the isLineSeparator stuff. Definitely a regression. Herbert try the patch. Do we really want that? These units only appeared in 1.2.0cvs, right? In this case, we do not want code for compatibility with non-released versions. If this is needed for 1.1.x files, things are different. we need it anyway: changing pextraWidthp() or in this way. I totally agree with you, that a development version is a development version, so the fileformat maybe dynamically! If we do it in this way than Garst and others are happy ... it's your turn ... ;-) Herbert -- http://www.lyx.org/help/
Re: [PATCH] simplify code
Jean-Marc Lasgouttes wrote:
Herbert == Herbert Voss [EMAIL PROTECTED] writes:
Herbert here is a real latex solution for a output when a graphic
Herbert file doesn't exist. In this case I set the boundingbox to
Herbert external values and the draft mode. Than we can have any
Herbert possible filename and need no translation like latexify() or
Herbert tricks with \verb{}. latex does it all: puts an rectangle
Herbert with filename not found in it.
THis a great idea... However, could you update the code to either not
add \n in the command or account for them in the return value of the
method (I prefer the first solution).
As it is, it _seems_ to me (I have not tried it) that it will confuse
the error insets placement.
no, I do not think so, because we return the inserted lines!
remember that bug hunting is much more easier when I have an output
like
\includegraphics[
bb = 0 0 200 100,
draft,
type=eps]{rose2.eps not found!}
and not
\includegraphics[bb = 0 0 200 100, draft, type=eps]{rose2.eps not found!}
but anyway, here is the patch
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.371
diff -u -r1.371 ChangeLog
--- src/insets/ChangeLog27 Mar 2002 12:27:17 - 1.371
+++ src/insets/ChangeLog28 Mar 2002 12:09:46 -
@@ -1,3 +1,8 @@
+2002-03-28 Herbert Voss [EMAIL PROTECTED]
+
+ * insetgraphic.C: (latex) simplify the code for the latex
+ output when the file doesn't exist
+
2002-03-27 Herbert Voss [EMAIL PROTECTED]
* insetgraphicsparam.C: change c%, p% to col%, page%
Index: src/insets/insetgraphics.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetgraphics.C,v
retrieving revision 1.99
diff -u -r1.99 insetgraphics.C
--- src/insets/insetgraphics.C 26 Mar 2002 18:20:11 - 1.99
+++ src/insets/insetgraphics.C 28 Mar 2002 12:09:46 -
@@ -648,71 +648,20 @@
}
-namespace {
-
-string const latexify(string const str)
-{
- ostringstream out;
-
- string::const_iterator it = str.begin();
- string::const_iterator end = str.end();
-
- for (; it != end; ++it) {
- switch (*it) {
-
- case ('$'):
- case (''):
- case ('%'):
- case ('#'):
- case ('_'):
- case ('{'):
- case ('}'):
- out '\\' *it;
- break;
-
- case ('~'):
- case ('^'):
- out '\\' *it {};
- break;
-
- case ('\\'):
- out \textbackslash ;
- break;
-
- default:
- out *it;
- break;
- }
- }
-
- return out.str().c_str();
-}
-
-} // namespace anon
-
-
int InsetGraphics::latex(Buffer const *buf, ostream os,
bool /*fragile*/, bool/*fs*/) const
{
- // If there is no file specified, just output a message about it in
- // the latex output.
- if (params().filename.empty()) {
- os \\fbox{\\rule[-0.5in]{0pt}{1in}
-_(empty figure path) }\n;
- return 1; // One end-of-line marker added to the stream.
- }
-
- // Enable these helper functions to find the file if it is stored as
- // a relative path.
- Path p(buf-filePath());
+ // If there is no file specified or not existing,
+ // just output a message about it in the latex output.
+ lyxerr[Debug::GRAPHICS] [latex]filename =
+params().filename endl;
+ string const message =
+ (IsFileReadable(MakeAbsPath(params().filename, buf-filePath()))
+!params().filename.empty()) ?
+ string() :
+ string(bb = 0 0 200 100, draft, type=eps]);
+ lyxerr[Debug::GRAPHICS] [latex]Messagestring = message endl;
+
- // Ditto if the file is not there.
- if (!IsFileReadable(params().filename)) {
- os \\fbox{\\rule[-0.5in]{0pt}{1in}
-latexify(MakeRelPath(params().filename, buf-filePath()))
-_( not found) }\n;
- return 1; // One end-of-line marker added to the stream.
- }
// These variables collect all the latex code that should be before and
// after the actual includegraphics command.
string before;
@@ -724,15 +673,25 @@
}
// We never use the starred form, we use the clip option instead.
before += \\includegraphics;
+
// Write the
Re: [PATCH] Speed up parsing of documents
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre I fiddled around with font insets for mathed lately, and by Andre now I am fairly convinced that this is the Right Thing to do. Andre It is much more logical Markup, it is basically what LaTeX Andre does, and it is what Docbook does (if that's what José said). I Andre don't think it is what conventional word processors do, but Andre to be honest, I don't care. The problem is probably to see what kind of reasonable user interface we can give to this. ANother candidate would be Paragraph::insertChar, which is called a lot during parsing (and maybe other places) for inserting at the end of paragraph. Obviously in this case there is no need to search/update the fonttable/insettable. Luckily enough for 1.2.0 release date, I will not have time to look at it :) Andre This problem, e.g. is magically solved by simply doing font Andre related stuff only if drawing is requested. Just push_back() Andre the char to the container... Huh? You have to fill in the data structure to indicate where font changes are, isn't it? Drawing is not relevant here. Andre For the 'speed of string comparison matter': Somewhere in one Andre of my older projects I had some class wrapping a 'const char *' Andre and a hash values of the string for exactly that purpose. I Andre seem to remember a speedup of four or five or so. So if this is Andre really crucial, I can dig this out (or re-invent the wheel Andre which is probably better for the stomach contents than looking Andre at six years old code...) Note that we are talking about lots of compares of rather small (less than 10 chars) strings. JMarc
Re: [PATCH] Re: [Devel] Bug list update
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes: Juergen John Levon wrote: - The list of font size options (e.g. AMS allows 9pt) is not updated immediately in the document layout dialog when you change the document class bug #306 Juergen It seems to me that the attached patch fixes this bug. But I Juergen am not shure that I interpret the function of Juergen params.textclass and params.UseClassDefault right. I think it is right indeed. If you did test it and it did as intended anyway it has to be right. I'll apply it. JMArc
Re: lyx-devel lib/: ChangeLog lib/layouts/: kluwer.layout
Herbert == Herbert Voss [EMAIL PROTECTED] writes: Herbert [EMAIL PROTECTED] wrote: Log message: small fix to kluwer style Herbert I thought that a TocDepth -1 Herbert is the right value to get no counting. but maybe I'm wrong Herbert and it works with 0 The goal was to _have_ counting, actually. Therefore I removed the TOCDepth. AFAIK nobody want a TOC, but it allows navigation in the document. JMarc
Re: [PATCH] Speed up parsing of documents
On Thu, Mar 28, 2002 at 01:27:51PM +0100, Jean-Marc Lasgouttes wrote: The problem is probably to see what kind of reasonable user interface we can give to this. I attach a diff of my 'fontinset' tree vs CVS head. Just try it. C-m, and type \bf, \textrm etc. Andre This problem, e.g. is magically solved by simply doing font Andre related stuff only if drawing is requested. Just push_back() Andre the char to the container... Huh? You have to fill in the data structure to indicate where font changes are, isn't it? If font changes are realized by insets, you do not have to indicate where font changes are when ordinary chars are inserted. If a font change is need, one has to insert a new inset... 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] Speed up parsing of documents
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre On Thu, Mar 28, 2002 at 01:27:51PM +0100, Jean-Marc Lasgouttes Andre wrote: The problem is probably to see what kind of reasonable user interface we can give to this. Andre I attach a diff of my 'fontinset' tree vs CVS head. Just try Andre it. C-m, and type \bf, \textrm etc. It is not attached, if I may object. And unfortunately, I will not have time to try it out. Note that since mathed is already the world of nested boxen, people will certainly not object to a few more. For text, it is different. Moreover, we would need insets which can spread on several lines inside a paragraph, and we do not have that. Andre If font changes are realized by insets, you do not have to Andre indicate where font changes are when ordinary chars are Andre inserted. If a font change is need, one has to insert a new Andre inset... Yes, but you add complexity somewhere else, so it is not really relevant to this particular problem. JMarc
urgs...
Maybe I should leave for today. 137k to the list was not really intended, but I was not aware that the patch was _that_ big already... Sorry. 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: urgs...
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre Maybe I should leave for today. 137k to the list was not really Andre intended, but I was not aware that the patch was _that_ big Andre already... When you are not sure your patches are, probably they should be reworked... JMarc
Re: urgs...
On Thu, Mar 28, 2002 at 02:25:33PM +0100, Jean-Marc Lasgouttes wrote: When you are not sure your patches are, probably they should be reworked... Hey, this was just a snapshot. Not meant for anything but to give you an impression how using fonts as insets feels. You were asking for a 'user interface' to such insets after all. Did I suggest in any way that the patch was ready for anything else? 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: Unlocalizable menu entries
Pauli == Pauli Virtanen [EMAIL PROTECTED] writes: I'm sorry I forgot to mention that these same strings also appear untranslated in Insert-Lists TOC menu. Adding _() around cit-second.name() on src/MenuBackend.C:380 seems to fix this. Pauli And guiName on src/insets/insetfloatlist.C:38 should probably Pauli also have _() to translate the strings appearing in inset Pauli boxes. Both problems fixed. Thanks. JMarc
Re: urgs...
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre Hey, this was just a snapshot. Andre Not meant for anything but to give you an impression how using Andre fonts as insets feels. Andre You were asking for a 'user interface' to such insets after Andre all. So tell us all. Is it yet another boxing level? Andre Did I suggest in any way that the patch was ready for anything Andre else? Why do you feel the need to defend yourself? Do you feel guilty for something we do not know yet? JMarc PS: I'll be away tomorrow. So it's kind of friday today.
Re: [PATCH] simplify code
Herbert == Herbert Voss [EMAIL PROTECTED] writes:
Herbert no, I do not think so, because we return the inserted lines!
I stand corrected.
Herbert remember that bug hunting is much more easier when I have an
Herbert output like \includegraphics[ bb = 0 0 200 100, draft,
Herbert type=eps]{rose2.eps not found!}
I understand that, but the output is a bit nicer on one line.
Herbert but anyway, here is the patch
I will not have time to test and apply it until tueasday, I think. So
Angus, if you want to take a look, you're welcome.
JMarc
PS: what about just outputting the file name? This would maybe help reLyX?
PPS: I do not see what is the magical code in graphic[sx].sty that
helps typesetting foo_bar.eps correctly. Does it really work?
Re: minipage wierdness
Herbert == Herbert Voss [EMAIL PROTECTED] writes: Herbert we need it anyway: changing pextraWidthp() or in this way. I Herbert totally agree with you, that a development version is a Herbert development version, so the fileformat maybe dynamically! Herbert If we do it in this way than Garst and others are happy ... Herbert it's your turn ... ;-) I see. If the code is needed, it is needed. JMarc
Re: [PATCH] simplify code
On 28 Mar 2002, Jean-Marc Lasgouttes wrote:
Herbert == Herbert Voss [EMAIL PROTECTED] writes:
Herbert no, I do not think so, because we return the inserted lines!
I stand corrected.
Herbert remember that bug hunting is much more easier when I have an
Herbert output like \includegraphics[ bb = 0 0 200 100, draft,
Herbert type=eps]{rose2.eps not found!}
I understand that, but the output is a bit nicer on one line.
no, this are these endless long lines when I have
some more options
Herbert but anyway, here is the patch
I will not have time to test and apply it until tueasday, I think. So
Angus, if you want to take a look, you're welcome.
JMarc
PS: what about just outputting the file name? This would maybe help reLyX?
this is an output made by lyx via graphicx. why should anybody
do a relyx? on the other hand the not found is part of the
filename! So relyx should work
PPS: I do not see what is the magical code in graphic[sx].sty that
helps typesetting foo_bar.eps correctly. Does it really work?
absolutely, do you nee a screenshot ;-)
Herbert
Re: urgs...
On Thu, Mar 28, 2002 at 02:42:04PM +0100, Jean-Marc Lasgouttes wrote:
Andre You were asking for a 'user interface' to such insets after
Andre all.
So tell us all. Is it yet another boxing level?
Yes. At least currently, but I am getting used to it, so it might as well
be permanent...
For /entering/ text this can be even implemented without requiring any
additional keystrokes. For navigation there will be two cursor positions
between normal text and 'special font' text corresponding to [1] and [2]
in: normal text [1]\emph{[2]and some emphasized text}
At least that's the canonical solution. If that is not wanted, special
code is needed. OTOH I really like the two positions...
Andre Did I suggest in any way that the patch was ready for anything
Andre else?
Why do you feel the need to defend yourself? Do you feel guilty for
something we do not know yet?
I felt guilty for sending 130k to the list.
PS: I'll be away tomorrow. So it's kind of friday today.
You should have mention this earlier.
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] simplify code
Herbert == Herbert Voss [EMAIL PROTECTED] writes: I understand that, but the output is a bit nicer on one line. Herbert no, this are these endless long lines when I have some more Herbert options You use too many options ;) PS: what about just outputting the file name? This would maybe help reLyX? Herbert this is an output made by lyx via graphicx. why should Herbert anybody do a relyx? on the other hand the not found is part Herbert of the filename! So relyx should work OK. PPS: I do not see what is the magical code in graphic[sx].sty that helps typesetting foo_bar.eps correctly. Does it really work? Herbert absolutely, do you nee a screenshot ;-) No, but I'll definitely try it before applying. In fact my question is more because I am curious of how graphics.sty achieves that. JMarc
Re: UI request
Garst == Garst R Reese [EMAIL PROTECTED] writes: What's so difficult with www.ctan.org and the LaTeX catalogue? Garst The catalogue is great, but it sent me to an out-of-date Garst mirror. You should contact the administrators of these mirrors. It happens currently that they do not know it is out of date. Otherwise, you can tell ctan that the mirror is not reliable. What happens if people begin to rely on some bugs which are in the float.sty we distribute? Shall we keep it forever to ensure backward compatibility? Garst No, just update it to the version that lyx does rely on, which Garst is currently more recent than the one in the teTeX-1.07 Garst release. The 1.0.7 I have in mandrake 8.1 is up to date enough. Probably they updated it. Garst It would appear that Suse has fixed the problem, maybe with a Garst beta release of teTeX. As things now stand, you will get bug Garst reports like the one that started this. Maybe something in Garst REQUIRED PACKAGES. We could had a small warning about that in LaTeXConfig.lyx.in. JMarc
Re: [PATCH] Re: minipage wierdness
Jean-Marc Lasgouttes wrote: Herbert == Herbert Voss [EMAIL PROTECTED] writes: Herbert Another topic: during testing this patch I had following Herbert output Herbert oldData= -8mu --- WHAT IS Herbert I never used such length in my testdoc??? In what context does it appear in the doc? mu is math unit, should only be useful in maths. than it's okay Herbert -- http://www.lyx.org/help/
Re: INSTALL question
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus I think that compiling on Tru64 is now sufficiently Angus straightforward that users should be able to do it with the Angus help of a Readme only. Nonetheless, it's still sufficiently Angus convoluted that this info is probably best placed in a separate Angus INSTALL.Tru64 file. Angus What do you think of the attached patch? Why do you need to set CPP? Why do you need to set -I and -L options? --with-extra-prefix does it perfectly well (it is your right to do as you wish, but I do not want to advise to do that in a README). Is the problem with std::count still relevant now that we have lyx::count? Tell me (again?) what the problem was with autoconf 2.13. The lyxsum.C problem should be investigated, methinks JMarc
Re: [PATCH] simplify code
Jean-Marc Lasgouttes wrote:
Herbert absolutely, do you nee a screenshot ;-)
No, but I'll definitely try it before applying. In fact my question is
more because I am curious of how graphics.sty achieves that.
from graphics.sty
[...]
\ifGin@draft
\hb@xt\Gin@reqwidth{%
\vrule\hss
\vbox to \Gin@reqheight{%
\hrule \@width \Gin@reqwidth
\vss
\edef\@tempa{#3}%
\rlap{ \ttfamily\expandafter\strip@prefix\meaning\tempa}%
\vss
\hrule}%
\hss\vrule}%
[...]
Herbert
--
http://www.lyx.org/help/
Re: [PATCH] simplify code
Herbert == Herbert Voss [EMAIL PROTECTED] writes: Herbert Jean-Marc Lasgouttes wrote: absolutely, do you nee a Herbert screenshot ;-) No, but I'll definitely try it before applying. In fact my question is more because I am curious of how graphics.sty achieves that. Herbert from graphics.sty Yes, I've seen that. As I understand it, what it does is just typeset the text in tt font... Weird. JMarc
Re: INSTALL question
On Thursday 28 March 2002 2:48 pm, Jean-Marc Lasgouttes wrote: Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus I think that compiling on Tru64 is now sufficiently Angus straightforward that users should be able to do it with the Angus help of a Readme only. Nonetheless, it's still sufficiently Angus convoluted that this info is probably best placed in a separate Angus INSTALL.Tru64 file. Angus What do you think of the attached patch? Why do you need to set CPP? I found that the configure script failed without this. It uses the prepreocessor to check whether header files exist, not the c compiler. Why do you need to set -I and -L options? --with-extra-prefix does it perfectly well (it is your right to do as you wish, but I do not want to advise to do that in a README). Ditto. Else the preprocesor can't find stuff. Having said that, I discovered all this by trial and error. It's possible that things will work without CPP. Will investigate. Is the problem with std::count still relevant now that we have lyx::count? I believe that we check only for the existence of std::count, not whether it returns a sane value. Tell me (again?) what the problem was with autoconf 2.13. In what regard? The lyxsum.C problem should be investigated, methinks So do I. After Easter. Angus
Re: INSTALL question
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus On Thursday 28 March 2002 2:48 pm, Jean-Marc Lasgouttes wrote: Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus I think that compiling on Tru64 is now sufficiently Angus straightforward that users should be able to do it with the Angus help of a Readme only. Nonetheless, it's still sufficiently Angus convoluted that this info is probably best placed in a separate Angus INSTALL.Tru64 file. Angus What do you think of the attached patch? Why do you need to set CPP? Angus I found that the configure script failed without this. It uses Angus the prepreocessor to check whether header files exist, not the Angus c compiler. configure is supposed to set CPP to $CC -E by itself. Why do you need to set -I and -L options? --with-extra-prefix does it perfectly well (it is your right to do as you wish, but I do not want to advise to do that in a README). Angus Ditto. Else the preprocesor can't find stuff. But --with-extra-prefix does exactly what you want: add the -I and -L. Is the problem with std::count still relevant now that we have lyx::count? Angus I believe that we check only for the existence of std::count, Angus not whether it returns a sane value. Indeed. That's just stupid. Tell me (again?) what the problem was with autoconf 2.13. Angus In what regard? I mean is there a reason why autoconf2.13 does not work on tru64 unix? This is probably the configure scriipt that will go in the distribution, anyway. The lyxsum.C problem should be investigated, methinks Angus So do I. After Easter. Good. JMarc
Re: [PATCH] Re: minipage wierdness
Garst == Garst R Reese [EMAIL PROTECTED] writes: Garst I think math would be clearer. My first thought on seeing it Garst was milli-microns. Garst You don't want to use any of these units, anyway. So why worry :) JMarc
Re: INSTALL question
On Thursday 28 March 2002 3:11 pm, Jean-Marc Lasgouttes wrote: Why do you need to set CPP? [snip...] as I said, I'll check. Is the problem with std::count still relevant now that we have lyx::count? Angus I believe that we check only for the existence of std::count, Angus not whether it returns a sane value. Indeed. That's just stupid. It's stupid to check for a sane value? Fair enough; then the comment should stay. I mean is there a reason why autoconf2.13 does not work on tru64 unix? This is probably the configure scriipt that will go in the distribution, anyway. It did work fine; then Lars started playing with Makefile.am et al, and broke everything. I tried to track down the problem and in the process upgraded autoconf. I subsequently found that the real problem lay elsewhere (ie, Lars introdued a bug). Squashing this bug meant that I could configure again using autoconf 2.52. I have no idea if I could still configure with 2.13; probably yes. I'm not particularly keen to investigate! Angus
1.2 ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there. Is there anything horrible in the code preventing you from releasing lyx-1.2.0-prerelease-beta-alpha-gamma? In other words, is lyx-devel usable already? When is the next stable or instable release planned? I have been lurking on this list for over a year, but I have not even heard of a release plan. I and many other users would appreciate a release to see what we are anxiously waiting for. Especially the QT-GUII sounds interesting because in all seriousness xforms suck compared to GTK/QT. - -- Moritz Moeller-Herrmann ICQ #3585990 (wiss. Mitarbeiter, IMGB, Mannheim) -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8ozWJNK5F2s9Xe10RAiOlAJ9qbRkjJfvXbFjOlNmg+FYUV2YKGgCeJzDn dp6CJR9N8inYPPVX6pxUFRk= =VqUo -END PGP SIGNATURE-
Re: [PATCH] Re: [Devel] Bug list update
Jean-Marc Lasgouttes wrote: Juergen It seems to me that the attached patch fixes this bug. But I Juergen am not shure that I interpret the function of Juergen params.textclass and params.UseClassDefault right. I think it is right indeed. If you did test it and it did as intended anyway it has to be right. Of course I tested it and it seems to do the right thing. Only thing is that I was not shure if we set things we do not want to with params.textclass. But as far as I remember your explanations, all those things are set by params.UseClassDefaults. I'll apply it. Thanks. Juergen.
Re: [PATCH] simplify code
Jean-Marc Lasgouttes wrote: Herbert == Herbert Voss [EMAIL PROTECTED] writes: Herbert Jean-Marc Lasgouttes wrote: absolutely, do you nee a Herbert screenshot ;-) No, but I'll definitely try it before applying. In fact my question is more because I am curious of how graphics.sty achieves that. Herbert from graphics.sty Yes, I've seen that. As I understand it, what it does is just typeset the text in tt font... Weird. it's not ttfamily, you can delete it and get the same in roman it's the \expandafter\strip@prefix\meaning\@tempa which scans the string for each character. Herbert -- http://www.lyx.org/help/
Re: INSTALL question
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus I believe that we check only for the existence of std::count, Angus not whether it returns a sane value. Indeed. That's just stupid. Angus It's stupid to check for a sane value? Fair enough; then the Angus comment should stay. No, I was actually agreeing with you. If it were just me, we'd just always use our own code instead of std::count. Of course, if this prolbem is fixed in cxx 6.2 (I think it is) or cxx 6.3, then there are less reasons for installing a workaround. Angus I have no idea if I could still configure with 2.13; probably Angus yes. I'm not particularly keen to investigate! I think it would work. It did work for me. JMarc
Re: [PATCH] simplify code
Herbert == Herbert Voss [EMAIL PROTECTED] writes: Herbert it's not ttfamily, you can delete it and get the same in Herbert roman it's the Herbert \expandafter\strip@prefix\meaning\@tempa Herbert which scans the string for each character. Ahh. Here lies the magic, then. JMarc
Re: 1.2 ?
On Thu, Mar 28, 2002 at 04:23:52PM +0100, Moritz Moeller-Herrmann wrote: Is there anything horrible in the code preventing you from releasing lyx-1.2.0-prerelease-beta-alpha-gamma? In other words, is lyx-devel usable already? Check the bug tracker ! http://bugzilla.lyx.org/ Basically, pre1 is almost ready, and 1.2final is as well, depending on the bugs pre1 testers unearth. a release plan. we plan to release when it's ready :) I and many other users would appreciate a release to see what we are anxiously waiting for. Especially the QT-GUII sounds interesting because in all seriousness xforms suck compared to GTK/QT. and that will happen for 1.3 release ... john -- To the untrained eye it might seem as though Quality programs and ISO 9000 are not related. I was confused too until one consultant explained it to me this way : 'ISO 9000 is closely related to Quality because everything you do is Quality and ISO 9000 documents everything you do, therefore give us money.' - Scott Adams
Re: 1.2 ?
On Thu, Mar 28, 2002 at 04:23:52PM +0100, Moritz Moeller-Herrmann wrote: In other words, is lyx-devel usable already? IMO yes. It is not worse than 1.1.6 anyway... When is the next stable or instable release planned? I have been lurking on this list for over a year, but I have not even heard of a release plan. Soon. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
»¶Óϲ»¶»³¾ÉÓÎÏ·ROMºÍϲ»¶GBA ROMÓÎÏ·µÄÅóÓÑÇë¿´¡£¡£¡£
http://gosnk.126.com»¶Óϲ»¶»³¾ÉÓÎÏ·ROMºÍϲ»¶GBA ROMÓÎÏ·µÄÅóÓÑÇë¿´¡£¡£¡£ ÏÂÃæÊDZ¾ÈË×öºÃ²»¾ÃµÄ»³¾ÉÄ£ÄâÆ÷ÓÎÏ·µÄÍøÒ³£¬ÓкܶàGBA ROMSÏÂÔغ͸öÖÖÄ£ÄâÆ÷ÓÎÏ·µÄROMÏÂÔغͽéÉܵÄŶ¡£ÎÞÂÛÊÇоÉÓÎÏ·»òÖÐÎÄÓÎÏ·±¾Õ¾¶¼Ò»Íø´ò¾¡¡£Çëµã»÷½øÈ롣лл£¬Ï£Íû²»»áÈø÷λÅóÓÑʧÍû¡£ÉùÃ÷£¬Ò»½øÈ¥µ¯³öµÄÁ½¸öС´°¿Ú²¢·ÇÊDZ¾ÈËÔ¸ÒâµÄÄÇÒòΪ±¾È˵ÄÖ÷Ò³ÊÇÃâ·ÑÖ÷Ò³ºÍÃâ·Ñ»òÃû.ËùÒԲűÆÆȵ¯³öÀ´µÄ¡£Çë¸÷λÅóÓÑÄÜÁ½⡣µÈ±¾ÈËÖ÷Ò³Óиü¶àÁ÷Á¿ºó²ÅÈ¥ÉêÇëÒ»¸öÊշѵÄÖ÷Ò³À´Îª¸÷λ·þÎñ.лл!´ó¸÷λµÄµ½À´,ÈçÓв»×ãºÍÎÊÌâÇë¸æÖ®. http://gosnk.126.com ÖÐ×ÊÔ´¹«Ë¾http://www.net001.net ÌṩÓòÃûÏÈ×¢²áºó¸¶¿î;Ö÷»úÏÈ¿ªÍ¨ºóÊÕ·Ñ·þÎñ,ÖÐ;¿ÉÍË¿î¡£ÌØ»ÝÍƼö£ºÓòÃû+100MÖ÷»ú²¢¸½ËÍ5¸ö10MÆóÒµÓÊÏ䣬ÿÄêÖ»Ðè350Ôª£¡£¡ ʹÓü«ÐÇÓʼþȺ·¢£¬ÎÞÐëͨ¹ýÓʼþ·þÎñÆ÷£¬Ö±´ï¶Ô·½ÓÊÏ䣬ËٶȾø¶ÔÒ»Á÷£¡ÏÂÔØÍøÖ·£º[ÐÄÁ¬ÐÂ]Çé¸ÐÔÚÏߣ¬¸ü¶àÃâ·ÑµÄ³¬¿áÈí¼þµÈÄãÀ´Ï¡¡
Re: [PATCH] simplify code
Jean-Marc Lasgouttes wrote:
Herbert == Herbert Voss [EMAIL PROTECTED] writes:
Herbert it's not ttfamily, you can delete it and get the same in
Herbert roman it's the
Herbert \expandafter\strip@prefix\meaning\@tempa
Herbert which scans the string for each character.
Ahh. Here lies the magic, then.
a view into the magic is attached ... :-)
Herbert
--
http://www.lyx.org/help/
#LyX 1.2 created this file. For more info see http://www.lyx.org/
\lyxformat 220
\textclass article
\begin_preamble
\newcommand{\jmarc}[1]{%
\hb@xt@200pt{%
\vrule\hss
\vbox to 100pt{%
\hrule \@width 200pt
\vss
\edef\@tempa{#1}%
\rlap{ \ttfamily\expandafter\strip@prefix\meaning\@tempa}%
\vss
\hrule%
}%
\hss\vrule
}%
}
\newcommand{\jmarcroman}[1]{%
\hb@xt@200pt{%
\vrule\hss
\vbox to 100pt{%
\hrule \@width 200pt
\vss%
\edef\@tempa{#1}%
\rlap{ \expandafter\strip@prefix\meaning\@tempa}%
\vss
\hrule%
}%
\hss\vrule
}%
}
\newcommand{\jmarcc}[1]{%
\hb@xt@200pt{%
\vrule\hss
\vbox to 100pt{%
\hrule \@width 200pt
\vss%
\rlap{ #1}%
\vss
\hrule%
}%
\hss\vrule
}%
}
\end_preamble
\language ngerman
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\spacing single
\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
test for some filenames
\layout Standard
\begin_inset ERT
status Open
\layout Standard
\backslash
jmarc{fi_let
\backslash
$e{}s.eps}
\end_inset
\layout Standard
\begin_inset ERT
status Open
\layout Standard
\backslash
jmarc{fi_let
\backslash
$e{}s.eps}
\end_inset
\layout Standard
\begin_inset ERT
status Open
\layout Standard
\backslash
jmarcc{filet
\backslash
es.eps}
\end_inset
\the_end
Underfull boxes
Hi all. I threw together a little document which explains how to deal with under/overfull boxes in LyX, with the intention of making it part of the LyX documentations, stand alone or as a chapter of something bigger. Please tell me what you think. Thanks. Gady (please CC to [EMAIL PROTECTED], thanks) _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx underfull.lyx.gz Description: GNU Zip compressed data
PS
±¾³§ÎªÁËÀ©Õ¹ÒµÎñ£¬ÌØÏòÈ«¹ú¸÷µØ³ÏÕ÷´úÀíºÍÕÐÊÕÒµÎñÔ±£¬ ÏêÇéÇë¼ûhttp://www.ag888.comÖеÄÉÌÎñºÏ×÷À¸£¬Í¬Ê±ÇëÄú£¬ ÔÚ¿´¹ýÍøÒ³ºÍÁ˽âµÄÏêϸÇé¿öºó£¬¸øÎÒÃÇÀ´ÐÅ£¬ÔÚÀ´ÐÅÖÐÄúÒª ÁôÏÂÐÕÃû£¬µØÖ·£¬µç»°£¬»òÕß¹«Ë¾Ãû³Æ£¬µØÖ·£¬µç»°£¬ÈôÓÐʲ ôÒÉÎÊÇëÔÚÎÒÃǵÄÂÛ̳»òÊÇÁôÑÔ°å·¢±í¡£ лл! ÈôÊDZ¾Óʼþ¸øÄú´øÀ´²»¿ì£¬ÇëÄúɾ³ý¼´¿É£¬Í¬Ê±µ½ http://www.ag888.comÖеÄÂÛ̳ÀïÁôÑÔ¸øÎÒÃǾÍÐÐÁËÒÔºó£¬Äú ½«²»»áÔÙÊÕµ½±¾¹«Ë¾µÄÐÅÁË Brief Introduction To Wenzhou Aolong Printing Materials Co.,Ltd. Wenzhou Aolong Printing Materials Co.,Ltd. is a professinal manufacturer of Aoguang Brand PS plate products,its production base covers a land area of 19800 m2.Besides,the Company has a modern multifunctional office building and employs a group of technical talents and managing professionals.The Company is located in Aojiang Town of Wenzhou City, a place titled asContinuable Developing Chinese Small Town. UN andState-level Mass Zone of Spark Technologies, enjoying very conventient sea,land and air communications.The Company is well-equipped in production facilties and solld in technical force as it has a modermized high-tecjh automatic confined continuous-rolling PS production line,the self-controlling system of which is introduced from abroad. At present. the Company is in a position to produca a wide range of PS plates at width below 1400mm and thickness between 0.15-0.3mm,reaching the annual output of 2.6 million square.Most of all,the products is reliable and stable in quality and performs at world-advanced level,.In Oct,2001,the Company was appraised as quality and measure trustworthy unit in provincial market.Meanwhile it has got the certification of ISO9001 Quality System. Under guidance of business principle of scientific management,perfect quality, honest service and expanding business in overseas markets,the Company is dedicated to supplying you with the best quality products and after-sales services. The Company sincerely hopes to set uo close business cooperation with clients in printing circles from home and abroad. Email: [EMAIL PROTECTED] homepage: http://www.ag888.com ¹« ˾ ¼ò ½é ÎÂÖÝÊÐ÷¡ÁúÓ¡Ë¢Æ÷²ÄÓÐÏÞ¹«Ë¾ÊÇרҵÉú²ú¡°°Â¹â¡±ÅÆPS°æµÄ³§¼Ò¡£³§ÇøÕ¼µØ Ãæ»ý19800ƽ·½Ã×£¬½¨ÖþÃæ»ý6100ƽ·½Ã×£¬ÓµÓÐÏÖ´ú»¯¡¢¶à¹¦ÄܵÄ×ۺϰ칫´óÂ¥£¬ ¼¯¹úÄÚÒ»Á÷µÄ¼¼Êõ¹ÜÀíÈ˲š£±¾¹«Ë¾Î»ÓÚ¡°ÁªºÏ¹ú¿É³ÖÐø·¢Õ¹µÄÖйúС³ÇÕò¡±¡¢ ¡°¹ú¼Ò¼¶ÐÇ»ð¼¼ÊõÃܼ¯Çø¡±££ÎÂÖÝÊа½½Õò£¬º£¡¢Â½£¬¿Õ½»Í¨Ê®·Ö±ãÀû¡£±¾¹« ˾Éú²úÉ豸¾«Á¼£¬¼¼ÊõÁ¦Á¿ÐÛºñ£¬ÓµÓйúÄÚÍâÒ»Á÷µÄÏÖ´ú»¯È«×Ô¶¯¡¢È«·â±ÕÁ¬Ðø ¾í¼òʽPS°æÉú²úÏߣ¬Æä×Ô¿ØϵͳȫÌ×½ø¿Ú£¬ÄÜÉú²ú¿í¶ÈΪ1400mmÒÔÏ¡¢ºñ¶ÈΪ 0.15-0.3mmµÄ¸÷ÖÖ¹æ¸ñ°æ£¬Äê²ú¡°°Â¹â¡±ÅÆPS°æ200Íòƽ·½Ãס£²úÆ·ÖÊÁ¿Îȶ¨£¬ ´ïµ½¹úÄÚÏȽøˮƽ¡£±¾¹«Ë¾²úÆ·ÓÚ2001Äê10Ô·ÝÈÙ»ñÊ¡Êг¡ÖÊÁ¿¼ÆÁ¿Ðŵùýµ¥Î»£¬ ͬʱ£¬Í¨¹ýÁËISO9001¹ú¼ÊÖÊÁ¿ÌåϵµÄÈÏÖ¤¡£ ÎÒ¹«Ë¾±¾×Åʵʩ¿Æѧ¹ÜÀí¡¢´´Ôì׿ԽƷÖÊ¡¢³ÏÐÅ·þÎñ¿Í»§¡¢¿ªÍعú¼ÊÊг¡µÄ ÖÊÁ¿·½ÕëΪÄúÌṩ×îÓÅÖʵIJúÆ·£¬×îÍêÃÀµÄÊÛºó·þÎñ¡£ ½ß³Ï»¶Ó¹úÄÚÍâÓ¡Ë¢½çÅóÓѺ͹ã´óÓû§¹âÁٻݹˣ¬Ç×ÃܺÏ×÷¡£ ¹ã¸æ·¢²¼ÈË£ºÎÂÖÝ°½ÁúÓ¡Ë¢Æ÷²ÄÓÐÏÞ¹«Ë¾µçÄÔ²¿ Ö÷Ò³ÖÆ×÷ά»¤£ºÎÂÖÝ°½ÁúÓ¡Ë¢Æ÷²ÄÓÐÏÞ¹«Ë¾µçÄÔ²¿
[GNOME-patch] Rename the classes and implement preamble
Hey guys, I've renamed all the classes in the gnome frontend, renamed the dialog files implemented the preamble. The patch is at: http://www.koziarski.org/gnome-class-rename-and-preamble.tar.bz2 please look over and apply. cheers -- | Michael Koziarski |Conventional wisdom is often | | Data Engineer, Linux user | long on convention and short | | Objectivist. | on wisdom -- | | http://www.koziarski.com| Warren E. Buffett, BRK.A |
Re: Underfull boxes
Gady Kozma wrote: I threw together a little document which explains how to deal with under/overfull boxes in LyX, with the intention of making it part of the LyX documentations, stand alone or as a chapter of something bigger. I put it in http://www.lyx.org/help/docs/LyXdocs.php Herbert
Re: Underfull boxes
Herbert Voss wrote: http://www.lyx.org/help/docs/LyXdocs.php btw some of your links there (tugboard and dtk article) are messed up. Happy Easter :-) Juergen.
RE: [Devel] SuSE 8.0 and KLyX
On 28-Mar-2002 Michael Schmitt wrote: People! Look at this page: http://www.suse.de/de/products/suse_linux/i386/susetour/tour41.html First time, I almost fall from my chair. We have to do something! #:O) If I'm not totatly mistaken the screenshot there isn't from KLyX, is it? It seems a normal LyX screen ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Why won't you let me kiss you goodnight? Is it something I said? -- Tom Ryan
Re: Unlocalizable menu entries
On ke, 2002-03-27 at 02:01, Jean-Marc Lasgouttes wrote:
> Pauli Virtanen wrote:
> > Hello,
> >
> > Currently (as in CVS) the entries (e.g. "Table", "Figure", etc.) in
> > Insert->Floats menu cannot be translated. They also appear in Navigate
> > menu. I think that these should be made translatable since they are
> > quite visible to the user.
> >
> > There are also some not-so-visible untranslatable strings in the type
> > list ("TOC", "figure", ...) in table of contents dialog.
> >
>
> Should be fixed after my next commit.
I'm sorry I forgot to mention that these same strings also appear
untranslated in Insert->Lists & TOC menu. Adding _() around cit->second.name()
on src/MenuBackend.C:380 seems to fix this.
--
Pauli Virtanen -- mailto:[EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
Re: minipage wierdness
On 28-Mar-2002 Garst R. Reese wrote: > bring it up to: >|minipage|--|minipage| > With the new code, the backspace deleted the hfill, and it was tricky to > ge the cursor in the right place to re-insert it. That is why I Enter first minipage and press "ESC" that should bring you at the right position, shouldn't it? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Whistler's Law: You never know who is right, but you always know who is in charge.
Re: Unlocalizable menu entries
On to, 2002-03-28 at 11:08, Pauli Virtanen wrote:
> On ke, 2002-03-27 at 02:01, Jean-Marc Lasgouttes wrote:
> > Pauli Virtanen wrote:
> > > Hello,
> > >
> > > Currently (as in CVS) the entries (e.g. "Table", "Figure", etc.) in
> > > Insert->Floats menu cannot be translated. They also appear in Navigate
> > > menu. I think that these should be made translatable since they are
> > > quite visible to the user.
> > >
> > > There are also some not-so-visible untranslatable strings in the type
> > > list ("TOC", "figure", ...) in table of contents dialog.
> > >
> >
> > Should be fixed after my next commit.
>
> I'm sorry I forgot to mention that these same strings also appear
> untranslated in Insert->Lists & TOC menu. Adding _() around cit->second.name()
> on src/MenuBackend.C:380 seems to fix this.
And guiName on src/insets/insetfloatlist.C:38 should probably also have
_() to translate the strings appearing in inset boxes.
--
Pauli Virtanen -- mailto:[EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
Re: More eye candy
> "John" == John Levon <[EMAIL PROTECTED]> writes: >> I thought that all toolbar in KDE apps were supposed to be setable >> by the user as floating top, bottom, whatever... However, we could >> have John> right, but it is up to the app to store the state of the session John> ... Feel free to have a qt2-specific pref file. Angus already did that for setting xforms-specific colors. John> I don't get you. I am trying to /expand/ a menu. This will crash John> if there's no buffer currently : see expand:ExportFormats John> besides, the menu code should not know about buffers, readonly John> etc. - the core should provide only enabled/disabled info for John> this. (as it does now afaik) I see now. Why did not yoou say it upfront: there is a bug in Menubackend::expand! It should be fixed in cvs. Undoubtedly, you will find many of those, since you are bound to do things differently that what I did. >> Yes, but we will have to eventually find a solution. John> couldn't we connecto to Angu's updateParagraph signal ? That John> seems good enough doesn't it ? Or does it not do what it sounds John> like ? Maybe, I do not know this code. >> Convince me. John> I would if I was sure myself ... That's the point. I am not either. John> I certainly think we can take a signal approach for say, John> lastfiles. It's easy to do and not intrusive I don't think. Don't bother with it. generating this does not cost anything. The only proble is with the various TOCS, I think (although I'd like to have hard numbers on a large file: how much does TOC generation cost?). If menubackend where to cache the TOCS, using some signal, would regenerating the menus at each Menu::update() really cost too much? The time will depend on the number of headings, not number of paragraphs in document. JMarc
Re: lyx-devel lib/: ChangeLog lib/layouts/: kluwer.layout
[EMAIL PROTECTED] wrote: > Log message: > small fix to kluwer style I thought that a TocDepth -1 is the right value to get no counting. but maybe I'm wrong and it works with 0 Herbert -- http://www.lyx.org/help/
[PATCH] more length-stuff
the last one (hopefully):
1. simplifies the code: use always the choice from
xforms_helpers and don't build them everytime new
2. reorder the choicelist to get the most common length
first and move the excotic ones to the end
Herbert
--
http://www.lyx.org/help/
Index: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.651
diff -u -r1.651 ChangeLog
--- src/ChangeLog 27 Mar 2002 23:27:12 - 1.651
+++ src/ChangeLog 28 Mar 2002 10:44:51 -
@@ -1,3 +1,8 @@
+2002-03-28 Herbert Voss <[EMAIL PROTECTED]>
+
+ * lengthcommon.C: change the order of the length to get
+ a one which shows the most common ones first
+
2002-03-28 Herbert Voss <[EMAIL PROTECTED]>
* lyxlength.C: compatibility stuff for "old" 1.2.0 files which
Index: src/lengthcommon.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lengthcommon.C,v
retrieving revision 1.3
diff -u -r1.3 lengthcommon.C
--- src/lengthcommon.C 27 Mar 2002 12:27:17 - 1.3
+++ src/lengthcommon.C 28 Mar 2002 10:44:51 -
@@ -6,9 +6,11 @@
// I am not sure if "mu" should be possible to select (Lgb)
char const * unit_name[num_units] = {
- "sp", "pt", "bp", "dd", "mm", "pc", "cc", "cm",
- "in", "ex", "em", "mu",
- "text%", "col%", "page%", "line%" };
+ "cm", "mm", "in", // standard
+ "col%", "line%", "text%", "page%", // relative
+ "ex", "em", // TeX
+ "pt", "sp", "bp", // other
+ "dd", "pc", "cc", "mu" }; // excotic
LyXLength::UNIT unitFromString(string const & data)
Index: src/frontends/xforms/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/ChangeLog,v
retrieving revision 1.338
diff -u -r1.338 ChangeLog
--- src/frontends/xforms/ChangeLog 27 Mar 2002 12:27:17 - 1.338
+++ src/frontends/xforms/ChangeLog 28 Mar 2002 10:44:53 -
@@ -1,3 +1,13 @@
+2002-03-28 Herbert Voss <[EMAIL PROTECTED]>
+
+ * FormMinipage.C:
+ * FormDocument.C:
+ * FormParagraph.C: use the Length-choices from xforms_helpers.h
+ and don't build these new.
+
+ * xforms_helpers.h: change the order of the length to get
+ a one which shows the most common ones first
+
2002-03-27 Herbert Voss <[EMAIL PROTECTED]>
* xforms_helpers.h:
Index: src/frontends/xforms/FormDocument.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/FormDocument.C,v
retrieving revision 1.93
diff -u -r1.93 FormDocument.C
--- src/frontends/xforms/FormDocument.C 21 Mar 2002 21:18:02 - 1.93
+++ src/frontends/xforms/FormDocument.C 28 Mar 2002 10:44:53 -
@@ -136,31 +136,24 @@
// Create the contents of the unit choices
// Don't include the "%" terms...
- vector units_vec = getLatexUnits();
-#if 0
- for (vector::iterator it = units_vec.begin();
-it != units_vec.end(); ++it) {
- if (contains(*it, "%"))
- it = units_vec.erase(it, it+1) - 1;
- }
-#else
- vector::iterator ret =
- std::remove_if(units_vec.begin(),
- units_vec.end(),
- bind2nd(contains_functor(), "%"));
- units_vec.erase(ret, units_vec.end());
-#endif
- string units = getStringFromVector(units_vec, "|");
-
- fl_addto_choice(paper_->choice_custom_width_units, units.c_str());
- fl_addto_choice(paper_->choice_custom_height_units, units.c_str());
- fl_addto_choice(paper_->choice_top_margin_units,units.c_str());
- fl_addto_choice(paper_->choice_bottom_margin_units, units.c_str());
- fl_addto_choice(paper_->choice_inner_margin_units, units.c_str());
- fl_addto_choice(paper_->choice_outer_margin_units, units.c_str());
- fl_addto_choice(paper_->choice_head_height_units, units.c_str());
- fl_addto_choice(paper_->choice_head_sep_units, units.c_str());
- fl_addto_choice(paper_->choice_foot_skip_units, units.c_str());
+ fl_addto_choice(paper_->choice_custom_width_units,
+ choice_Length_WithUnit.c_str());
+ fl_addto_choice(paper_->choice_custom_height_units,
+ choice_Length_WithUnit.c_str());
+ fl_addto_choice(paper_->choice_top_margin_units,
+ choice_Length_WithUnit.c_str());
+ fl_addto_choice(paper_->choice_bottom_margin_units,
+ choice_Length_WithUnit.c_str());
+ fl_addto_choice(paper_->choice_inner_margin_units,
+ choice_Length_WithUnit.c_str());
+
Re: [PATCH] Speed up parsing of documents
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
Allan> On Thu, 28 Mar 2002, Jean-Marc Lasgouttes wrote: [...]
>> Therefore I moved the fonts, insets and backslash (useful for ERT)
>> tests to the top of the method.
>>
>> The result is that Buffer::parseSingleLyXformat2Token takes 16.2%
>> of the time, and the 404503 string comparisons now take less time
>> than InsertChar, which makes more sense.
Allan> Clever optimisation.
However, it seem that the huge amount of font tokens we get in this
case is related to the fact that textinsets do not make any effort to
reduce their fonts agains outside world (look at UserGuide.lyx...).
Presumably the code should differentiate between insets which inherit
font from the outside (are there some) and those who reset fonts.
There is really a lot of bloat in lyx files due to that.
>> I attach the patch instead of commiting it, because I want to have
>> a virtual nod from Lars before. I would not want to break the
>> carefully crafted compatibility reading...
Allan> Just looking at the patch I notice that there seems to be some
Allan> nesting of preprocessor directives like:
Allan> #ifndef NO_COMPATABILITY + ... + #ifndef NO_COMPATABILITY + ...
Allan> + #endif + ...
Oops! It was probably too late in the evening to re-read my patch. Try
this one instead. Lars, would that be OK?
ANother candidate would be Paragraph::insertChar, which is called a
lot during parsing (and maybe other places) for inserting at the end
of paragraph. Obviously in this case there is no need to search/update
the fonttable/insettable. Luckily enough for 1.2.0 release date, I
will not have time to look at it :)
JMarc
Index: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.651
diff -u -p -r1.651 ChangeLog
--- src/ChangeLog 27 Mar 2002 23:27:12 - 1.651
+++ src/ChangeLog 28 Mar 2002 10:54:34 -
@@ -1,3 +1,9 @@
+2002-03-28 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
+
+ * buffer.C (parseSingleLyXformat2Token): reorder a bit the tests
+ in order to reduce drastically the number of comparisons needed to
+ parse a large document
+
2002-03-27 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
* lyxfunc.C (getStatus): return 'disabled' early for LFUN_NOACTION
Index: src/buffer.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/buffer.C,v
retrieving revision 1.322
diff -u -p -r1.322 buffer.C
--- src/buffer.C 25 Mar 2002 11:15:25 - 1.322
+++ src/buffer.C 28 Mar 2002 10:54:34 -
@@ -563,6 +563,102 @@ Buffer::parseSingleLyXformat2Token(LyXLe
}
#endif
+ } else if (token == "\\end_inset") {
+ lyxerr << "Solitary \\end_inset. Missing \\begin_inset?.\n"
+ << "Last inset read was: " << last_inset_read
+ << endl;
+ // Simply ignore this. The insets do not have
+ // to read this.
+ // But insets should read it, it is a part of
+ // the inset isn't it? Lgb.
+ } else if (token == "\\begin_inset") {
+#ifndef NO_COMPABILITY
+ insertErtContents(par, pos, false);
+ ert_stack.push(ert_comp);
+ ert_comp = ErtComp();
+#endif
+ readInset(lex, par, pos, font);
+#ifndef NO_COMPABILITY
+ ert_comp = ert_stack.top();
+ ert_stack.pop();
+ insertErtContents(par, pos);
+#endif
+ } else if (token == "\\family") {
+ lex.next();
+ font.setLyXFamily(lex.getString());
+ } else if (token == "\\series") {
+ lex.next();
+ font.setLyXSeries(lex.getString());
+ } else if (token == "\\shape") {
+ lex.next();
+ font.setLyXShape(lex.getString());
+ } else if (token == "\\size") {
+ lex.next();
+ font.setLyXSize(lex.getString());
+#ifndef NO_COMPABILITY
+ } else if (token == "\\latex") {
+ lex.next();
+ string const tok = lex.getString();
+ if (tok == "no_latex") {
+ // Do the insetert.
+ insertErtContents(par, pos);
+ } else if (tok == "latex") {
+ ert_comp.active = true;
+ ert_comp.font = font;
+ } else if (tok == "default") {
+ // Do the insetert.
+ insertErtContents(par, pos);
+ } else {
+ lex.printError("Unknown LaTeX font flag "
+ "`$$Token'");
+ }
+#endif
+ } else if (token == "\\lang") {
+ lex.next();
+ string const tok = lex.getString();
+ Language const * lang = languages.getLanguage(tok);
+ if (lang) {
+ font.setLanguage(lang);
+ } else {
+ font.setLanguage(params.language);
+ lex.printError("Unknown language `$$Token'");
+ }
+ } else if (token == "\\numeric") {
+ lex.next();
+ font.setNumber(font.setLyXMisc(lex.getString()));
+ } else if (token == "\\emph") {
+ lex.next();
+ font.setEmph(font.setLyXMisc(lex.getString()));
+ } else if (token == "\\bar") {
+ lex.next();
+ string const tok = lex.getString();
+ // This is dirty, but gone with LyX3. (Asger)
+ if (tok == "under")
+ font.setUnderbar(LyXFont::ON);
+ else if (tok == "no")
+ font.setUnderbar(LyXFont::OFF);
+ else if (tok == "default")
+ font.setUnderbar(LyXFont::INHERIT);
+
Re: minipage wierdness
> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes: Herbert> Garst R. Reese wrote: >> At the time of the %t -> %text patch, something went weird with my >> mini-pages. Two minipages with 44%t separated by an hfil used to >> appear side by side in lyx. The %t went to pt, but changing it to >> %text made one appear under the other and lost half of the >> minipages. This could also be related to the isLineSeparator stuff. >> Definitely a regression. Herbert> try the patch. Do we really want that? These units only appeared in 1.2.0cvs, right? In this case, we do not want code for compatibility with non-released versions. If this is needed for 1.1.x files, things are different. JMarc
Re: minipage wierdness
> "Garst" == Garst R Reese <[EMAIL PROTECTED]> writes: Garst> This could also be related to the Garst> isLineSeparator stuff. Definitely a regression. All the isLineSeparator stuff did is disable the code which allowed for line breaks after Menu Separator or hyphenation marker. If you do not have one of those, it is irrelevant. JMarc
Re: [PATCH] simplify code
> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
Herbert> here is a real latex solution for a output when a graphic
Herbert> file doesn't exist. In this case I set the boundingbox to
Herbert> external values and the draft mode. Than we can have any
Herbert> possible filename and need no translation like latexify() or
Herbert> tricks with \verb{}. latex does it all: puts an rectangle
Herbert> with "filename not found" in it.
THis a great idea... However, could you update the code to either not
add \n in the command or account for them in the return value of the
method (I prefer the first solution).
As it is, it _seems_ to me (I have not tried it) that it will confuse
the error insets placement.
JMarc
Re: Breaking paragraph in a keepempty Section
On Thu, 28 Mar 2002 02:04:18 + wrote John Levon <[EMAIL PROTECTED]>: > If this is the case why on earth didn't you open a bug ?! Becouse I am lazy (and did not have access when I recovered this one). However, now I did: http://bugzilla.lyx.org/show_bug.cgi?id=313 Guenter -- [EMAIL PROTECTED]
Re: [PATCH] Speed up parsing of documents
On Thu, Mar 28, 2002 at 12:21:20PM +0100, Jean-Marc Lasgouttes wrote: > However, it seem that the huge amount of font tokens we get in this > case is related to the fact that textinsets do not make any effort to > reduce their fonts agains outside world (look at UserGuide.lyx...). > > Presumably the code should differentiate between insets which inherit > font from the outside (are there some) and those who reset fonts. > There is really a lot of bloat in lyx files due to that. I fiddled around with "font insets" for mathed lately, and by now I am fairly convinced that this is the Right Thing to do. It is much more "logical Markup", it is basically what LaTeX does, and it is what Docbook does (if that's what José said). I don't think it is what "conventional word processors" do, but to be honest, I don't care. I don't know how big a change this would be for 'main LyX', as it is already such a big change for mathed that I won't try to sneak it into 1.2.0 [and new insets are really easy in mathed nowadays...] The change, however, _is_ nice: It's about 200 lines _less_ code right now and it removes almost all font related hacks (like passing a font change through macro arguments...). So the change just 'feels good'. > ANother candidate would be Paragraph::insertChar, which is called a > lot during parsing (and maybe other places) for inserting at the end > of paragraph. Obviously in this case there is no need to search/update > the fonttable/insettable. Luckily enough for 1.2.0 release date, I > will not have time to look at it :) This problem, e.g. is magically solved by simply doing font related stuff only if drawing is requested. Just push_back() the char to the container... - For the 'speed of string comparison matter': Somewhere in one of my older projects I had some class wrapping a 'const char *' and a hash values of the string for exactly that purpose. I seem to remember a speedup of four or five or so. So if this is really crucial, I can dig this out (or re-invent the wheel which is probably better for the stomach contents than looking at six years old code...) 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: minipage wierdness
Jean-Marc Lasgouttes wrote: >>"Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes: >> > > Herbert> Garst R. Reese wrote: > >>>At the time of the %t -> %text patch, something went weird with my >>>mini-pages. Two minipages with 44%t separated by an hfil used to >>>appear side by side in lyx. The %t went to pt, but changing it to >>>%text made one appear under the other and lost half of the >>>minipages. This could also be related to the isLineSeparator stuff. >>>Definitely a regression. >>> > > > Herbert> try the patch. > > Do we really want that? These units only appeared in 1.2.0cvs, right? > In this case, we do not want code for compatibility with non-released > versions. If this is needed for 1.1.x files, things are different. we need it anyway: changing pextraWidthp() or in this way. I totally agree with you, that a development version is a development version, so the fileformat maybe dynamically! If we do it in this way than Garst and others are happy ... it's your turn ... ;-) Herbert -- http://www.lyx.org/help/
Re: [PATCH] simplify code
Jean-Marc Lasgouttes wrote:
>>"Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
>>
>
> Herbert> here is a real latex solution for a output when a graphic
> Herbert> file doesn't exist. In this case I set the boundingbox to
> Herbert> external values and the draft mode. Than we can have any
> Herbert> possible filename and need no translation like latexify() or
> Herbert> tricks with \verb{}. latex does it all: puts an rectangle
> Herbert> with "filename not found" in it.
>
> THis a great idea... However, could you update the code to either not
> add \n in the command or account for them in the return value of the
> method (I prefer the first solution).
>
> As it is, it _seems_ to me (I have not tried it) that it will confuse
> the error insets placement.
no, I do not think so, because we return the inserted lines!
remember that bug hunting is much more easier when I have an output
like
\includegraphics[
bb = 0 0 200 100,
draft,
type=eps]{rose2.eps not found!}
and not
\includegraphics[bb = 0 0 200 100, draft, type=eps]{rose2.eps not found!}
but anyway, here is the patch
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.371
diff -u -r1.371 ChangeLog
--- src/insets/ChangeLog27 Mar 2002 12:27:17 - 1.371
+++ src/insets/ChangeLog28 Mar 2002 12:09:46 -
@@ -1,3 +1,8 @@
+2002-03-28 Herbert Voss <[EMAIL PROTECTED]>
+
+ * insetgraphic.C: (latex) simplify the code for the latex
+ output when the file doesn't exist
+
2002-03-27 Herbert Voss <[EMAIL PROTECTED]>
* insetgraphicsparam.C: change c%, p% to col%, page%
Index: src/insets/insetgraphics.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetgraphics.C,v
retrieving revision 1.99
diff -u -r1.99 insetgraphics.C
--- src/insets/insetgraphics.C 26 Mar 2002 18:20:11 - 1.99
+++ src/insets/insetgraphics.C 28 Mar 2002 12:09:46 -
@@ -648,71 +648,20 @@
}
-namespace {
-
-string const latexify(string const & str)
-{
- ostringstream out;
-
- string::const_iterator it = str.begin();
- string::const_iterator end = str.end();
-
- for (; it != end; ++it) {
- switch (*it) {
-
- case ('$'):
- case ('&'):
- case ('%'):
- case ('#'):
- case ('_'):
- case ('{'):
- case ('}'):
- out << '\\' << *it;
- break;
-
- case ('~'):
- case ('^'):
- out << '\\' << *it << "{}";
- break;
-
- case ('\\'):
- out << "\textbackslash ";
- break;
-
- default:
- out << *it;
- break;
- }
- }
-
- return out.str().c_str();
-}
-
-} // namespace anon
-
-
int InsetGraphics::latex(Buffer const *buf, ostream & os,
bool /*fragile*/, bool/*fs*/) const
{
- // If there is no file specified, just output a message about it in
- // the latex output.
- if (params().filename.empty()) {
- os << "\\fbox{\\rule[-0.5in]{0pt}{1in}"
- << _("empty figure path") << "}\n";
- return 1; // One end-of-line marker added to the stream.
- }
-
- // Enable these helper functions to find the file if it is stored as
- // a relative path.
- Path p(buf->filePath());
+ // If there is no file specified or not existing,
+ // just output a message about it in the latex output.
+ lyxerr[Debug::GRAPHICS] << "[latex]filename = "
+ << params().filename << endl;
+ string const message =
+ (IsFileReadable(MakeAbsPath(params().filename, buf->filePath()))
+ && !params().filename.empty()) ?
+ string() :
+ string("bb = 0 0 200 100, draft, type=eps]");
+ lyxerr[Debug::GRAPHICS] << "[latex]Messagestring = " << message << endl;
+
- // Ditto if the file is not there.
- if (!IsFileReadable(params().filename)) {
- os << "\\fbox{\\rule[-0.5in]{0pt}{1in}"
- << latexify(MakeRelPath(params().filename, buf->filePath()))
- << _(" not found") << "}\n";
- return 1; // One end-of-line marker added to the stream.
- }
// These variables collect all the latex code that should be before and
// after the actual includegraphics command.
string before;
@@ -724,15 +673,25 @@
}
// We never use
Re: [PATCH] Speed up parsing of documents
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> I fiddled around with "font insets" for mathed lately, and by Andre> now I am fairly convinced that this is the Right Thing to do. Andre> It is much more "logical Markup", it is basically what LaTeX Andre> does, and it is what Docbook does (if that's what José said). I Andre> don't think it is what "conventional word processors" do, but Andre> to be honest, I don't care. The problem is probably to see what kind of reasonable user interface we can give to this. >> ANother candidate would be Paragraph::insertChar, which is called a >> lot during parsing (and maybe other places) for inserting at the >> end of paragraph. Obviously in this case there is no need to >> search/update the fonttable/insettable. Luckily enough for 1.2.0 >> release date, I will not have time to look at it :) Andre> This problem, e.g. is magically solved by simply doing font Andre> related stuff only if drawing is requested. Just push_back() Andre> the char to the container... Huh? You have to fill in the data structure to indicate where font changes are, isn't it? Drawing is not relevant here. Andre> For the 'speed of string comparison matter': Somewhere in one Andre> of my older projects I had some class wrapping a 'const char *' Andre> and a hash values of the string for exactly that purpose. I Andre> seem to remember a speedup of four or five or so. So if this is Andre> really crucial, I can dig this out (or re-invent the wheel Andre> which is probably better for the stomach contents than looking Andre> at six years old code...) Note that we are talking about lots of compares of rather small (less than 10 chars) strings. JMarc
Re: [PATCH] Re: [Devel] Bug list update
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes: Juergen> John Levon wrote: >> > - The list of font size options (e.g. AMS allows 9pt) is not > >> updated immediately in the document layout dialog when you change > >> the document class >> >> bug #306 Juergen> It seems to me that the attached patch fixes this bug. But I Juergen> am not shure that I interpret the function of Juergen> params.textclass and params.UseClassDefault right. I think it is right indeed. If you did test it and it did as intended anyway it has to be right. I'll apply it. JMArc
Re: lyx-devel lib/: ChangeLog lib/layouts/: kluwer.layout
> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes: Herbert> [EMAIL PROTECTED] wrote: >> Log message: small fix to kluwer style Herbert> I thought that a TocDepth -1 Herbert> is the right value to get no counting. but maybe I'm wrong Herbert> and it works with 0 The goal was to _have_ counting, actually. Therefore I removed the TOCDepth. AFAIK nobody want a TOC, but it allows navigation in the document. JMarc
Re: [PATCH] Speed up parsing of documents
On Thu, Mar 28, 2002 at 01:27:51PM +0100, Jean-Marc Lasgouttes wrote: > The problem is probably to see what kind of reasonable user interface we > can give to this. I attach a diff of my 'fontinset' tree vs CVS head. Just try it. C-m, and type \bf, \textrm etc. > Andre> This problem, e.g. is magically solved by simply doing font > Andre> related stuff only if drawing is requested. Just push_back() > Andre> the char to the container... > > Huh? You have to fill in the data structure to indicate where font > changes are, isn't it? If font changes are realized by insets, you do not have to indicate where font changes are when ordinary chars are inserted. If a font change is need, one has to insert a new inset... 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] Speed up parsing of documents
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> On Thu, Mar 28, 2002 at 01:27:51PM +0100, Jean-Marc Lasgouttes Andre> wrote: >> The problem is probably to see what kind of reasonable user >> interface we can give to this. Andre> I attach a diff of my 'fontinset' tree vs CVS head. Just try Andre> it. C-m, and type \bf, \textrm etc. It is not attached, if I may object. And unfortunately, I will not have time to try it out. Note that since mathed is already the world of nested boxen, people will certainly not object to a few more. For text, it is different. Moreover, we would need insets which can spread on several lines inside a paragraph, and we do not have that. Andre> If font changes are realized by insets, you do not have to Andre> indicate where font changes are when ordinary chars are Andre> inserted. If a font change is need, one has to insert a new Andre> inset... Yes, but you add complexity somewhere else, so it is not really relevant to this particular problem. JMarc
urgs...
Maybe I should leave for today. 137k to the list was not really intended, but I was not aware that the patch was _that_ big already... Sorry. 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: urgs...
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> Maybe I should leave for today. 137k to the list was not really Andre> intended, but I was not aware that the patch was _that_ big Andre> already... When you are not sure your patches are, probably they should be reworked... JMarc
Re: urgs...
On Thu, Mar 28, 2002 at 02:25:33PM +0100, Jean-Marc Lasgouttes wrote: > When you are not sure your patches are, probably they should be > reworked... Hey, this was just a snapshot. Not meant for anything but to give you an impression how using fonts as insets feels. You were asking for a 'user interface' to such insets after all. Did I suggest in any way that the patch was ready for anything else? 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: Unlocalizable menu entries
> "Pauli" == Pauli Virtanen <[EMAIL PROTECTED]> writes: >> I'm sorry I forgot to mention that these same strings also appear >> untranslated in Insert->Lists & TOC menu. Adding _() around >> cit->second.name() on src/MenuBackend.C:380 seems to fix this. Pauli> And guiName on src/insets/insetfloatlist.C:38 should probably Pauli> also have _() to translate the strings appearing in inset Pauli> boxes. Both problems fixed. Thanks. JMarc
Re: urgs...
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> Hey, this was just a snapshot. Andre> Not meant for anything but to give you an impression how using Andre> fonts as insets feels. Andre> You were asking for a 'user interface' to such insets after Andre> all. So tell us all. Is it yet another boxing level? Andre> Did I suggest in any way that the patch was ready for anything Andre> else? Why do you feel the need to defend yourself? Do you feel guilty for something we do not know yet? JMarc PS: I'll be away tomorrow. So it's kind of friday today.
Re: [PATCH] simplify code
> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
Herbert> no, I do not think so, because we return the inserted lines!
I stand corrected.
Herbert> remember that bug hunting is much more easier when I have an
Herbert> output like \includegraphics[ bb = 0 0 200 100, draft,
Herbert> type=eps]{rose2.eps not found!}
I understand that, but the output is a bit nicer on one line.
Herbert> but anyway, here is the patch
I will not have time to test and apply it until tueasday, I think. So
Angus, if you want to take a look, you're welcome.
JMarc
PS: what about just outputting the file name? This would maybe help reLyX?
PPS: I do not see what is the magical code in graphic[sx].sty that
helps typesetting foo_bar.eps correctly. Does it really work?
Re: minipage wierdness
> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes: Herbert> we need it anyway: changing pextraWidthp() or in this way. I Herbert> totally agree with you, that a development version is a Herbert> development version, so the fileformat maybe dynamically! Herbert> If we do it in this way than Garst and others are happy ... Herbert> it's your turn ... ;-) I see. If the code is needed, it is needed. JMarc
Re: [PATCH] simplify code
On 28 Mar 2002, Jean-Marc Lasgouttes wrote:
> > "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
>
> Herbert> no, I do not think so, because we return the inserted lines!
>
> I stand corrected.
>
> Herbert> remember that bug hunting is much more easier when I have an
> Herbert> output like \includegraphics[ bb = 0 0 200 100, draft,
> Herbert> type=eps]{rose2.eps not found!}
>
> I understand that, but the output is a bit nicer on one line.
no, this are these endless long lines when I have
some more options
>
> Herbert> but anyway, here is the patch
>
> I will not have time to test and apply it until tueasday, I think. So
> Angus, if you want to take a look, you're welcome.
>
> JMarc
>
> PS: what about just outputting the file name? This would maybe help reLyX?
this is an output made by lyx via graphicx. why should anybody
do a relyx? on the other hand the "not found" is part of the
filename! So relyx should work
>
> PPS: I do not see what is the magical code in graphic[sx].sty that
> helps typesetting foo_bar.eps correctly. Does it really work?
absolutely, do you nee a screenshot ;-)
Herbert
Re: urgs...
On Thu, Mar 28, 2002 at 02:42:04PM +0100, Jean-Marc Lasgouttes wrote:
> Andre> You were asking for a 'user interface' to such insets after
> Andre> all.
>
> So tell us all. Is it yet another boxing level?
Yes. At least currently, but I am getting used to it, so it might as well
be permanent...
For /entering/ text this can be even implemented without requiring any
additional keystrokes. For navigation there will be two cursor positions
between normal text and 'special font' text corresponding to [1] and [2]
in: "normal text [1]\emph{[2]and some emphasized text}...".
At least that's the "canonical" solution. If that is not wanted, special
code is needed. OTOH I really like the two positions...
> Andre> Did I suggest in any way that the patch was ready for anything
> Andre> else?
>
> Why do you feel the need to defend yourself? Do you feel guilty for
> something we do not know yet?
I felt guilty for sending 130k to the list.
> PS: I'll be away tomorrow. So it's kind of friday today.
You should have mention this earlier.
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] simplify code
> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes: >> I understand that, but the output is a bit nicer on one line. Herbert> no, this are these endless long lines when I have some more Herbert> options You use too many options ;) >> PS: what about just outputting the file name? This would maybe help >> reLyX? Herbert> this is an output made by lyx via graphicx. why should Herbert> anybody do a relyx? on the other hand the "not found" is part Herbert> of the filename! So relyx should work OK. >> PPS: I do not see what is the magical code in graphic[sx].sty that >> helps typesetting foo_bar.eps correctly. Does it really work? Herbert> absolutely, do you nee a screenshot ;-) No, but I'll definitely try it before applying. In fact my question is more because I am curious of how graphics.sty achieves that. JMarc
Re: UI request
> "Garst" == Garst R Reese <[EMAIL PROTECTED]> writes: >> What's so difficult with www.ctan.org and the LaTeX catalogue? Garst> The catalogue is great, but it sent me to an out-of-date Garst> mirror. You should contact the administrators of these mirrors. It happens currently that they do not know it is out of date. Otherwise, you can tell ctan that the mirror is not reliable. >> What happens if people begin to rely on some bugs which are in the >> float.sty we distribute? Shall we keep it forever to ensure >> backward compatibility? Garst> No, just update it to the version that lyx does rely on, which Garst> is currently more recent than the one in the teTeX-1.07 Garst> release. The 1.0.7 I have in mandrake 8.1 is up to date enough. Probably they updated it. Garst> It would appear that Suse has fixed the problem, maybe with a Garst> beta release of teTeX. As things now stand, you will get bug Garst> reports like the one that started this. Maybe something in Garst> REQUIRED PACKAGES. We could had a small warning about that in LaTeXConfig.lyx.in. JMarc
Re: [PATCH] Re: minipage wierdness
Jean-Marc Lasgouttes wrote: >>"Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes: >> > > Herbert> Another topic: during testing this patch I had following > Herbert> output > > Herbert> oldData= -8mu <--- WHAT IS > > Herbert> I never used such length in my testdoc??? > > In what context does it appear in the doc? "mu" is math unit, should > only be useful in maths. than it's okay Herbert -- http://www.lyx.org/help/
Re: INSTALL question
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> I think that compiling on Tru64 is now sufficiently Angus> straightforward that users should be able to do it with the Angus> help of a Readme only. Nonetheless, it's still sufficiently Angus> convoluted that this info is probably best placed in a separate Angus> INSTALL.Tru64 file. Angus> What do you think of the attached patch? Why do you need to set CPP? Why do you need to set -I and -L options? --with-extra-prefix does it perfectly well (it is your right to do as you wish, but I do not want to advise to do that in a README). Is the problem with std::count still relevant now that we have lyx::count? Tell me (again?) what the problem was with autoconf 2.13. The lyxsum.C problem should be investigated, methinks JMarc
Re: [PATCH] simplify code
Jean-Marc Lasgouttes wrote:
> Herbert> absolutely, do you nee a screenshot ;-)
>
> No, but I'll definitely try it before applying. In fact my question is
> more because I am curious of how graphics.sty achieves that.
from graphics.sty
[...]
\ifGin@draft
\hb@xt@\Gin@req@width{%
\vrule\hss
\vbox to \Gin@req@height{%
\hrule \@width \Gin@req@width
\vss
\edef\@tempa{#3}%
\rlap{ \ttfamily\expandafter\strip@prefix\meaning\@tempa}%
\vss
\hrule}%
\hss\vrule}%
[...]
Herbert
--
http://www.lyx.org/help/
Re: [PATCH] simplify code
> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes: Herbert> Jean-Marc Lasgouttes wrote: absolutely, do you nee a Herbert> screenshot ;-) >> No, but I'll definitely try it before applying. In fact my question >> is more because I am curious of how graphics.sty achieves that. Herbert> from graphics.sty Yes, I've seen that. As I understand it, what it does is just typeset the text in tt font... Weird. JMarc
Re: INSTALL question
On Thursday 28 March 2002 2:48 pm, Jean-Marc Lasgouttes wrote: > > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> I think that compiling on Tru64 is now sufficiently > Angus> straightforward that users should be able to do it with the > Angus> help of a Readme only. Nonetheless, it's still sufficiently > Angus> convoluted that this info is probably best placed in a separate > Angus> INSTALL.Tru64 file. > > Angus> What do you think of the attached patch? > > Why do you need to set CPP? I found that the configure script failed without this. It uses the prepreocessor to check whether header files exist, not the c compiler. > Why do you need to set -I and -L options? --with-extra-prefix does it > perfectly well (it is your right to do as you wish, but I do not want > to advise to do that in a README). Ditto. Else the preprocesor can't find stuff. Having said that, I discovered all this by trial and error. It's possible that things will work without CPP. Will investigate. > Is the problem with std::count still relevant now that we have > lyx::count? I believe that we check only for the existence of std::count, not whether it returns a sane value. > Tell me (again?) what the problem was with autoconf 2.13. In what regard? > The lyxsum.C problem should be investigated, methinks So do I. After Easter. Angus
Re: INSTALL question
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> On Thursday 28 March 2002 2:48 pm, Jean-Marc Lasgouttes wrote: >> > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: >> Angus> I think that compiling on Tru64 is now sufficiently Angus> straightforward that users should be able to do it with the Angus> help of a Readme only. Nonetheless, it's still sufficiently Angus> convoluted that this info is probably best placed in a separate Angus> INSTALL.Tru64 file. >> Angus> What do you think of the attached patch? >> Why do you need to set CPP? Angus> I found that the configure script failed without this. It uses Angus> the prepreocessor to check whether header files exist, not the Angus> c compiler. configure is supposed to set CPP to $CC -E by itself. >> Why do you need to set -I and -L options? --with-extra-prefix does >> it perfectly well (it is your right to do as you wish, but I do not >> want to advise to do that in a README). Angus> Ditto. Else the preprocesor can't find stuff. But --with-extra-prefix does exactly what you want: add the -I and -L. >> Is the problem with std::count still relevant now that we have >> lyx::count? Angus> I believe that we check only for the existence of std::count, Angus> not whether it returns a sane value. Indeed. That's just stupid. >> Tell me (again?) what the problem was with autoconf 2.13. Angus> In what regard? I mean is there a reason why autoconf2.13 does not work on tru64 unix? This is probably the configure scriipt that will go in the distribution, anyway. >> The lyxsum.C problem should be investigated, methinks Angus> So do I. After Easter. Good. JMarc
Re: [PATCH] Re: minipage wierdness
> "Garst" == Garst R Reese <[EMAIL PROTECTED]> writes: Garst> I think "math" would be clearer. My first thought on seeing it Garst> was milli-microns. Garst You don't want to use any of these units, anyway. So why worry :) JMarc
Re: INSTALL question
On Thursday 28 March 2002 3:11 pm, Jean-Marc Lasgouttes wrote: > >> Why do you need to set CPP? [snip...] as I said, I'll check. > >> Is the problem with std::count still relevant now that we have > >> lyx::count? > > Angus> I believe that we check only for the existence of std::count, > Angus> not whether it returns a sane value. > > Indeed. That's just stupid. It's stupid to check for a sane value? Fair enough; then the comment should stay. > I mean is there a reason why autoconf2.13 does not work on tru64 unix? > This is probably the configure scriipt that will go in the > distribution, anyway. It did work fine; then Lars started playing with Makefile.am et al, and broke everything. I tried to track down the problem and in the process upgraded autoconf. I subsequently found that the real problem lay elsewhere (ie, Lars introdued a bug). Squashing this bug meant that I could configure again using autoconf 2.52. I have no idea if I could still configure with 2.13; probably yes. I'm not particularly keen to investigate! Angus
1.2 ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there. Is there anything horrible in the code preventing you from releasing lyx-1.2.0-prerelease-beta-alpha-gamma? In other words, is lyx-devel usable already? When is the next stable or instable release planned? I have been lurking on this list for over a year, but I have not even heard of a release plan. I and many other users would appreciate a release to see what we are anxiously waiting for. Especially the QT-GUII sounds interesting because in all seriousness xforms suck compared to GTK/QT. - -- Moritz Moeller-Herrmann ICQ #3585990 (wiss. Mitarbeiter, IMGB, Mannheim) -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8ozWJNK5F2s9Xe10RAiOlAJ9qbRkjJfvXbFjOlNmg+FYUV2YKGgCeJzDn dp6CJR9N8inYPPVX6pxUFRk= =VqUo -END PGP SIGNATURE-
Re: [PATCH] Re: [Devel] Bug list update
Jean-Marc Lasgouttes wrote: > Juergen> It seems to me that the attached patch fixes this bug. But I > Juergen> am not shure that I interpret the function of > Juergen> params.textclass and params.UseClassDefault right. > > I think it is right indeed. If you did test it and it did as intended > anyway it has to be right. Of course I tested it and it seems to do the right thing. Only thing is that I was not shure if we set things we do not want to with params.textclass. But as far as I remember your explanations, all those things are set by params.UseClassDefaults. > I'll apply it. Thanks. Juergen.
Re: [PATCH] simplify code
Jean-Marc Lasgouttes wrote: >>"Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes: >> > > Herbert> Jean-Marc Lasgouttes wrote: absolutely, do you nee a > Herbert> screenshot ;-) > >>>No, but I'll definitely try it before applying. In fact my question >>>is more because I am curious of how graphics.sty achieves that. >>> > > > Herbert> from graphics.sty > > Yes, I've seen that. As I understand it, what it does is just typeset > the text in tt font... Weird. it's not ttfamily, you can delete it and get the same in roman it's the \expandafter\strip@prefix\meaning\@tempa which scans the string for each character. Herbert -- http://www.lyx.org/help/
Re: INSTALL question
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> I believe that we check only for the existence of std::count, Angus> not whether it returns a sane value. >> Indeed. That's just stupid. Angus> It's stupid to check for a sane value? Fair enough; then the Angus> comment should stay. No, I was actually agreeing with you. If it were just me, we'd just always use our own code instead of std::count. Of course, if this prolbem is fixed in cxx 6.2 (I think it is) or cxx 6.3, then there are less reasons for installing a workaround. Angus> I have no idea if I could still configure with 2.13; probably Angus> yes. I'm not particularly keen to investigate! I think it would work. It did work for me. JMarc
Re: [PATCH] simplify code
> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes: Herbert> it's not ttfamily, you can delete it and get the same in Herbert> roman it's the Herbert> \expandafter\strip@prefix\meaning\@tempa Herbert> which scans the string for each character. Ahh. Here lies the magic, then. JMarc
Re: 1.2 ?
On Thu, Mar 28, 2002 at 04:23:52PM +0100, Moritz Moeller-Herrmann wrote: > Is there anything horrible in the code preventing you from releasing > lyx-1.2.0-prerelease-beta-alpha-gamma? In other words, is lyx-devel usable > already? Check the bug tracker ! http://bugzilla.lyx.org/ Basically, pre1 is almost ready, and 1.2final is as well, depending on the bugs pre1 testers unearth. > a release plan. we plan to release when it's ready :) > I and many other users would appreciate a release to see what we are anxiously > waiting for. Especially the QT-GUII sounds interesting because in all > seriousness xforms suck compared to GTK/QT. and that will happen for 1.3 release ... john -- "To the untrained eye it might seem as though Quality programs and ISO 9000 are not related. I was confused too until one consultant explained it to me this way : 'ISO 9000 is closely related to Quality because everything you do is Quality and ISO 9000 documents everything you do, therefore give us money.'" - Scott Adams
Re: 1.2 ?
On Thu, Mar 28, 2002 at 04:23:52PM +0100, Moritz Moeller-Herrmann wrote: > In other words, is lyx-devel usable already? IMO yes. It is not worse than 1.1.6 anyway... > When is the next stable or instable release planned? I have been > lurking on this list for over a year, but I have not even heard of a > release plan. "Soon". Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
»¶Óϲ»¶»³¾ÉÓÎÏ·ROMºÍϲ»¶GBA ROMÓÎÏ·µÄÅóÓÑÇë¿´¡£¡£¡£
http://gosnk.126.com»¶Óϲ»¶»³¾ÉÓÎÏ·ROMºÍϲ»¶GBA ROMÓÎÏ·µÄÅóÓÑÇë¿´¡£¡£¡£ ÏÂÃæÊDZ¾ÈË×öºÃ²»¾ÃµÄ»³¾ÉÄ£ÄâÆ÷ÓÎÏ·µÄÍøÒ³£¬ÓкܶàGBA ROMSÏÂÔغ͸öÖÖÄ£ÄâÆ÷ÓÎÏ·µÄROMÏÂÔغͽéÉܵÄŶ¡£ÎÞÂÛÊÇоÉÓÎÏ·»òÖÐÎÄÓÎÏ·±¾Õ¾¶¼Ò»Íø´ò¾¡¡£Çëµã»÷½øÈ롣лл£¬Ï£Íû²»»áÈø÷λÅóÓÑʧÍû¡£ÉùÃ÷£¬Ò»½øÈ¥µ¯³öµÄÁ½¸öС´°¿Ú²¢·ÇÊDZ¾ÈËÔ¸ÒâµÄÄÇÒòΪ±¾È˵ÄÖ÷Ò³ÊÇÃâ·ÑÖ÷Ò³ºÍÃâ·Ñ»òÃû.ËùÒԲűÆÆȵ¯³öÀ´µÄ¡£Çë¸÷λÅóÓÑÄÜÁ½⡣µÈ±¾ÈËÖ÷Ò³Óиü¶àÁ÷Á¿ºó²ÅÈ¥ÉêÇëÒ»¸öÊշѵÄÖ÷Ò³À´Îª¸÷λ·þÎñ.лл!´ó¸÷λµÄµ½À´,ÈçÓв»×ãºÍÎÊÌâÇë¸æÖ®. http://gosnk.126.com ÖÐ×ÊÔ´¹«Ë¾http://www.net001.net ÌṩÓòÃûÏÈ×¢²áºó¸¶¿î;Ö÷»úÏÈ¿ªÍ¨ºóÊÕ·Ñ·þÎñ,ÖÐ;¿ÉÍË¿î¡£ÌØ»ÝÍƼö£ºÓòÃû+100MÖ÷»ú²¢¸½ËÍ5¸ö10MÆóÒµÓÊÏ䣬ÿÄêÖ»Ðè350Ôª£¡£¡ ʹÓü«ÐÇÓʼþȺ·¢£¬ÎÞÐëͨ¹ýÓʼþ·þÎñÆ÷£¬Ö±´ï¶Ô·½ÓÊÏ䣬ËٶȾø¶ÔÒ»Á÷£¡ÏÂÔØÍøÖ·£º[ÐÄÁ¬ÐÂ]Çé¸ÐÔÚÏߣ¬¸ü¶àÃâ·ÑµÄ³¬¿áÈí¼þµÈÄãÀ´Ï¡¡
Re: [PATCH] simplify code
Jean-Marc Lasgouttes wrote:
>>"Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
>>
>
> Herbert> it's not ttfamily, you can delete it and get the same in
> Herbert> roman it's the
>
> Herbert> \expandafter\strip@prefix\meaning\@tempa
>
> Herbert> which scans the string for each character.
>
> Ahh. Here lies the magic, then.
a view into the magic is attached ... :-)
Herbert
--
http://www.lyx.org/help/
#LyX 1.2 created this file. For more info see http://www.lyx.org/
\lyxformat 220
\textclass article
\begin_preamble
\newcommand{\jmarc}[1]{%
\hb@xt@200pt{%
\vrule\hss
\vbox to 100pt{%
\hrule \@width 200pt
\vss
\edef\@tempa{#1}%
\rlap{ \ttfamily\expandafter\strip@prefix\meaning\@tempa}%
\vss
\hrule%
}%
\hss\vrule
}%
}
\newcommand{\jmarcroman}[1]{%
\hb@xt@200pt{%
\vrule\hss
\vbox to 100pt{%
\hrule \@width 200pt
\vss%
\edef\@tempa{#1}%
\rlap{ \expandafter\strip@prefix\meaning\@tempa}%
\vss
\hrule%
}%
\hss\vrule
}%
}
\newcommand{\jmarcc}[1]{%
\hb@xt@200pt{%
\vrule\hss
\vbox to 100pt{%
\hrule \@width 200pt
\vss%
\rlap{ #1}%
\vss
\hrule%
}%
\hss\vrule
}%
}
\end_preamble
\language ngerman
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\spacing single
\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
test for some filenames
\layout Standard
\begin_inset ERT
status Open
\layout Standard
\backslash
jmarc{fi_let
\backslash
$e{}s.eps}
\end_inset
\layout Standard
\begin_inset ERT
status Open
\layout Standard
\backslash
jmarc{fi_let
\backslash
$e{}s.eps}
\end_inset
\layout Standard
\begin_inset ERT
status Open
\layout Standard
\backslash
jmarcc{filet
\backslash
es.eps}
\end_inset
\the_end
