Re: annoying mathed-behaviour (was Re: The current char style UI)
On Fri, Dec 05, 2003 at 07:49:38PM +0100, Christian Ridderström spake thusly:
In case that was unclear, here's an example:
a^2+\textrm{aFunction}+2|
pressing backspace gives
a^2+\textrm{aFunction}+|
backspace again...
a^2+\textrm{aFunction}|
now when you press backspace, the textinset isn't deleted, but highlighted
and a cute text shows up on the statusbar saying Press delete again to
actually delete.
a^2+\textrm{aFunction}|
\---delete?--\
and then when you press delete again, you end up with
a^2+|
/Christian
This is actually not a bad idea. But we sort-of have this now already.
In MathEd, I never delete anything but single characters straightaway.
I don't dare to :-( If I want to delete a bracketed expression etc., I
always select it first to see its extent.
One could in the above situation make the first backspace invoke
selection of the previous bracketed expression. I don't know how hard
that is to implement.
--
Christian Ridderström http://www.md.kth.se/~chr
- Martin
pgp0.pgp
Description: PGP signature
Re: [Patch] Re: [Patch] Re: CharStyle discussion
On Fri, Dec 05, 2003 at 12:54:58PM +0200, Martin Vermeer spake thusly: Patch attached. As I haven't heard any real objections (just blue-sky ideas building on it) I'll commit later today. Committed. I fixed one more bug: now the labelfont definition is actually used for the label (blue default font for all styles; twice reduced). Also the underline (now having two little end hooks) takes the label's colour. - Martin pgp0.pgp Description: PGP signature
Re: [Patch] Re: [Patch] Re: CharStyle discussion
Martin Vermeer wrote: Committed. I fixed one more bug: now the labelfont definition is actually used for the label (blue default font for all styles; twice reduced). Also the underline (now having two little end hooks) takes the label's colour. Looks very promising! I found one bug though. Special characters are not escaped inside the char style (I have tested noun). Type \today inside noun (not in ert) and you'll see what I mean. Jürgen BTW is it possible to get rid of the space at the beginning of a char style inset?
Re: [Patch] Re: [Patch] Re: CharStyle discussion
Juergen Spitzmueller wrote: BTW is it possible to get rid of the space at the beginning of a char style inset? Apparently this has more than one source. One part of the problem is that the insettext inside the inset has indended paragraph if the document uses paragraph indendation. Jürgen
[PATCH] Minipage
One for Angus... Now that the box inset superceeded minipage, it can theoretically be removed (or should we wait a bit)? Jürgen. minipage.diff.gz Description: GNU Zip compressed data
Re: [PATCH] Minipage
-BEGIN PGP SIGNED MESSAGE- On Samstag, 6. Dezember 2003 12:26, Juergen Spitzmueller wrote: One for Angus... Now that the box inset superceeded minipage, it can theoretically be removed (or should we wait a bit)? With this patch, the minipages are read in as boxed. Also the width of this inset is changed to 100 col%. (With the CVS-Version the value is 70 col%) Should I try to provide a test-file? Jürgen. Kornel - -- Kornel Benko [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) iQCVAwUBP9HWjLewfbDGmeqhAQFKRwP9E7nsyhPrPn4ynqsFGOC58LCXpkDT2eAw oUsC4MEFWpH75/XtYE1AJ5Nfc+nJSy3of6joKeFF/h6RWPB4GTcaa+f2O2o3xKA8 dLXnqNf4o38n0/VWkTB9QQeXw8Po/d1rUf7564PeuyBadnBtl5jpeeFxltXNGLaZ EGOtYSYzFSc= =5U5k -END PGP SIGNATURE-
Re: [PATCH] Minipage
Juergen Spitzmueller wrote: One for Angus... Now that the box inset superceeded minipage, it can theoretically be removed (or should we wait a bit)? Yes please, until tex2lyx is adapted to output the box inset instead of minipage. Georg
Re: CharStyle discussion
On Fri, Dec 05, 2003 at 02:46:15PM +0100, Andre Poenitz wrote:
On Fri, Dec 05, 2003 at 12:53:04PM +0100, Christian Ridderström wrote:
Note: Isn't it overkill drawing something that's emphasized using a box
AND (e.g.) italics? We don't want to flood the user with visual info.
Interesting point. Hm, maybe. Maybe not, though...
Lyx knows that bold/italic/font/size/color shows visually, so not drawing
a box for those is possible. A language change or a user supplied
style (using \userunknownmarkup{}) could get a box/frame since there is no
way to distinguish it from other text.
There is also the option of light gray frames that aren't so striking.
They are weaker than the black text and therefore won't interfere much with reading.
Helge Hafting
Re: [PATCH] Minipage
Georg Baum wrote: (or should we wait a bit)? Yes please, until tex2lyx is adapted to output the box inset instead of minipage. ok. BTW what is the status of lyx2lyx in this regard? Do we need another file format change? Jürgen.
Re: [PATCH] Minipage
Kornel Benko wrote: With this patch, the minipages are read in as boxed. Also the width of this inset is changed to 100 col%. (With the CVS-Version the value is 70 col%) Should I try to provide a test-file? Yes please. I cannot reproduce. Here, a minipage from an 1.3.4 file with width=70 col% is read in correctly. Also examples/fr_Minipage.lyx. examples/ Minipage.lyx, however, is read in with a wrong width value, but this is the same in 1.3.4. Minipage.lyx uses width=45p%, which is not valid anymore (lyx2lyx issue?). Thanks, Jürgen.
Re: [PATCH] Minipage
-BEGIN PGP SIGNED MESSAGE- On Samstag, 6. Dezember 2003 15:51, Juergen Spitzmueller wrote: Kornel Benko wrote: With this patch, the minipages are read in as boxed. Also the width of this inset is changed to 100 col%. (With the CVS-Version the value is 70 col%) Should I try to provide a test-file? Yes please. I cannot reproduce. Here, a minipage from an 1.3.4 file with width=70 col% is read in correctly. Also examples/fr_Minipage.lyx. examples/ Minipage.lyx, however, is read in with a wrong width value, but this is the same in 1.3.4. Minipage.lyx uses width=45p%, which is not valid anymore (lyx2lyx issue?). This minipage example is a left over of previous lyx-1.4cvs versions. Kornel - -- Kornel Benko [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) iQCVAwUBP9Hug7ewfbDGmeqhAQGkCAP/R4kbMITD0u0blIJLJafBp6cMt7BXPzsP 6ouYQEIhrn2fIoWbXZguqvEA4L/UdblYCJFlMILTZWhEX6/ZSIYjwNTG3LJZ4Uge jlDnzejayhmS79M71cmV1yvDr61LEb7EZAy1YclIVJRUC1hHMYihtzE5bQjyXAFE LZnEbSK6gNE= =30sZ -END PGP SIGNATURE- #LyX 1.4.0cvs created this file. For more info see http://www.lyx.org/ \lyxformat 225 \textclass article \begin_preamble \end_preamble \language ngerman \inputencoding auto \fontscheme default \graphics default \paperfontsize default \spacing single \papersize Default \paperpackage a4 \use_geometry 0 \use_amsmath 1 \use_natbib 0 \use_numerical_citations 0 \paperorientation portrait \secnumdepth 3 \tocdepth 3 \paragraph_separation skip \defskip medskip \quotes_language english \quotes_times 2 \papercolumns 1 \papersides 1 \paperpagestyle default \bullet 2 0 9 -1 \end_bullet \tracking_changes 0 \end_header \begin_layout Standard \align center \begin_inset Minipage position 1 inner_position 0 height 0pt width 70col% collapsed false \begin_layout Standard oa_test soll ein plattformunabhngiges Testtool fr Optical Archive auf Basis des C++ Toolkits sein. Es benutzt die aktuelle Version von OA fr Linux in der Version 2.1 mit kleinen Anpassungen. \end_layout \end_inset \end_layout \end_document
Re: [PATCH] Minipage
Kornel Benko wrote: This minipage example is a left over of previous lyx-1.4cvs versions. OK, your file has \lyxformat 225, while the Minipage-(Frameless) Boxes conversion is 223 - 225. I'd say this is a bleeding edge result where I'd leave you on your own. If you change \lyxformat to 223, the minipage is read in correctly (also the width). Thanks, Jürgen.
Re: [PATCH] Minipage
Juergen Spitzmueller wrote: Minipage.lyx, however, is read in with a wrong width value, but this is the same in 1.3.4. Minipage.lyx uses width=45p%, which is not valid anymore (lyx2lyx issue?). This is where this changed btw: http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/src/ lengthcommon.C.diff?r1=1.2r2=1.3 Regards, Jürgen
Re: The current char style UI
Andre Poenitz [EMAIL PROTECTED] writes: What I'm telling you is that the problem goes completely away with ranges, because we then have a natural interface: Edit-Text_Style-Noun Emphasis Badger Other... | And? We just keep this. Clicking on this entry inserts a new inset of | this type. I am kindo with John, not that we must/should use ranges, but that the actual ui should not show that insets are used for this. In essence a LCS inset cannot just be a normal inset. -- Lgb
Re: The current char style UI
Andre Poenitz [EMAIL PROTECTED] writes: | If the overlapping stuff is out and physical position == locical | position is in, all-boxes is (a) natural, (b) simple. I am not convinced... OTOH what I am convinced about is that we don't need to support overlapping stuff/nested LCS. -- Lgb
Re: [patch] move ParagraphList of InsetText and Buffer to LyXText
Andre Poenitz [EMAIL PROTECTED] writes: | On Tue, Dec 02, 2003 at 04:49:26PM +0100, Lars Gullik Bjønnes wrote: Andre Poenitz [EMAIL PROTECTED] writes: | Step 2. Almost mechanical. I wonder why this is a good move. | Because it consolidates common code of InsetText and Buffer in a single | place (LyXText). But hasn't this rendered multiple views of the same buffer virtually impossible? -- Lgb
Re: [PATCH] Minipage
Georg Baum wrote: Yes please, until tex2lyx is adapted to output the box inset instead of minipage. Hm, my patch does not make anything worse. tex2lyx produces \lyxformat 225 files, while lyx2lyx's minipage-box conversion happens between 223 and 225. So files with minipages produced with this version of tex2lyx will cause problems (as Kornel's file) in any case, unless we bump version to 226 and shift the minipage-box conversion to 225-226. Jürgen.
Re: [PATCH] Minipage
Juergen Spitzmueller wrote: BTW what is the status of lyx2lyx in this regard? Do we need another file format change? I found it. Jürgen
Re: new layout files for g-brief2
Hello sorry for taking that long time. I was very busy. Here is the patch. (against lyx-cvs) thanks felix Jean-Marc Lasgouttes wrote: Felix == Felix Kurth [EMAIL PROTECTED] writes: Felix did you apply it ? Or there are any further thinks to do for me Felix ? I did not apply it yet, because I also need an entry for the LaTeXConfig.lyx.in file describing what it is good for, where to find it and (this is the part I cannot do myself) explaining how it relates to g-brief. Feel free to ask if you need help on doing that. JMarc -- Felix Kurth pgp public key: http://www.fkurth.de/keys/felix.fkurth.asc key fingerprint: D401 DCF8 2BF8 50DF 2FAD 8136 C29B 83EE C0A1 F2AD--- LaTeXConfig.lyx.in 2003-09-22 10:47:09.0 +0200 +++ LaTeXConfig.lyx.in.new 2003-12-06 18:38:34.447188105 +0100 @@ -1133,6 +1133,58 @@ \begin_layout Subsection +g-brief2-en +\end_layout + +\begin_layout Description + +Found: @chk_g-brief2-en@ +\end_layout + +\begin_layout Description + +CTAN: +\family typewriter +macros/latex/contrib/supported/g-brief/ +\end_layout + +\begin_layout Description + +Notes: The document class +\family sans +g-brief2 +\family default + can be used to type commercial letters with a nice outfit. It's the successor of g-brief, its better configurable, but not backward compatible to g-brief. +\end_layout + +\begin_layout Subsection + +g-brief2-de +\end_layout + +\begin_layout Description + +Found: @chk_g-brief2-de@ +\end_layout + +\begin_layout Description + +CTAN: +\family typewriter +macros/latex/contrib/supported/g-brief/ +\end_layout + +\begin_layout Description + +Notes: The document class +\family sans +g-brief2-de +\family default + is the same as the above g-brief2-en only with german labels. Best for german letters. +\end_layout + +\begin_layout Subsection + hollywood \end_layout
Re: [PATCH] Minipage
-BEGIN PGP SIGNED MESSAGE- On Samstag, 6. Dezember 2003 16:33, Juergen Spitzmueller wrote: Kornel Benko wrote: This minipage example is a left over of previous lyx-1.4cvs versions. OK, your file has \lyxformat 225, while the Minipage-(Frameless) Boxes conversion is 223 - 225. I'd say this is a bleeding edge result where I'd leave you on your own. If you change \lyxformat to 223, the minipage is read in correctly (also the width). I can live with this. Nonetheless it was still possible to insert such a minipage in current CVS (without your patch of course) Function minipage-insert. Kornel - -- Kornel Benko [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) iQCVAwUBP9Iql7ewfbDGmeqhAQGf7gP9Hh8IdEUi1pcVP6bpa7jnRxci3Y+dbRuL Lz4JeQ4wlLqzkBAFD//Nfpr/2eFsbCQGFtdz0eE/3g1HqtoZorkD2ZCcb4dX08+x +4Yk5oTrUA1idblFi4rjLJUC2NthpfRT467A8DlECf4t6fNxom3MPP0LqhTntkIf CB1nW8URgIM= =wAhp -END PGP SIGNATURE-
Re: Sheesh we've been busy --- or have we?
On Friday 05 December 2003 06:56 pm, Michael Schmitt wrote: Angus Leeming wrote: All that activity --- a whole year's worth --- and the source has grown by just 7373 lines!!! and if you strip out all comments, then there's even less: 113174 lines of code in 13x/src 117040 lines of code in 14x/src Net gain 3866 lines. and then, if you compile LyX 1.3/1.4 and strip all debug symbols, you will notice that the binary file has even become much smaller... -rwxr-xr-x1 programs users 6171740 2003-12-06 00:54 src/lyx -rwxr-xr-x1 programs users 4135128 2003-12-06 00:53 src/lyx-qt _This_ is what I call surprising! And, what's even more surprising, all of this happened in spite of numerous ramblings on the list how lyx developers are making it into bloatware, etc. I guess that in the end it's the design that counts, and there's no amount of overdoing towards a better, more streamlined design. One can ask whether it's because using C++ features correctly will in the end produce better code, or whether the developers really headed those ramblings. I guess it's a bit of both. So, LyX seems to be progressing nicely in the right direction and, at lest from coders perspective, 1.4 should be much easier to work on. I imagine that many new features will be way easier to add to the new 1.4 architecture. Cheers, Kuba
Re: [PATCH] Re: Format=Document=Page size not working
On Friday 05 December 2003 05:07 am, Juergen Spitzmueller wrote: Juergen Spitzmueller wrote: My question (for 1.4.0cvs) would be why this isn't entirely within the controller ? Yes, why not. Do you want to do it? My plan is to apply the 1.3 fix to 1.4 too for now. I don't have the time to do the controller thing right now, and I don't want to leave it unfixed in 1.4. It can always be improved. OK? I guess if you put a big // FIXME: this needs to go into the controller in some relevant place so that it's obvious which functionality one is talking about. Kuba
Re: CharStyle discussion
Insets are an appropriate means for structured editing but they are not suitable for writing consecutive text. If I had had to insert an inset for every emphasized term, for every capitalized product name, for every keyword in typewriter font, and for every figure reference in sans serif in my PhD, I would have jumped out of the window!!! I guess one should keep in mind that insets are 99% programming paradigms, and only about 1% user-visible things. User has no concept of an inset. It all boils down to making the interface to creating such character-style insets an easy one. In such a case we have two possible behaviours: 1. MicroPro WordStar (last time I used it on a CP/M machine in mid-80's) approach: all formatting is an invisible character, so both bold on and bold off is an invisible character, and you can both delete it and you have to jump over it with arrow cursors if say you're moving cursor in the text with arrows (^S/^D for left/right anyone? :). Apparently, thousands of users found that acceptable and this is directly modeled by right arrow only enters the inset, but it makes some problems with backspace -- essentially a backspace at the bold end character did expand the bold all the way to end of paragraph or somesuch, whereas in our case it would delete the whole inset. Not a nice thing. It may not be such a great idea nowadays methinks. 2. Your average editor approach - insets or whatever implements character styles are invisible. Backspace just outside of the right end of a bold inset should automatically enter the inset and then perform the action of backspace. I find that 2 is widely accepted nowadays. Implementation-wise I imagine that character-style insets are OK as long as certain things done just outside of both ends of the inset (say backspace on the right, delete on the left) first enter the inset and then feed-forward the action to the inset itself. There will also be some constraints as to how far a character style can go. I imagine we will artificially need to terminate all character styling at the end of the paragraph, otherwise it'll be an uncontainable mess. This may actually make sense for logical formatting - typically, you're making a word/sentence bolded, not the whole document; if it's the whole document you should adjust the default paragraph style properties (in LyX's case it would be more like document properties). I haven't read the whole thread yet, so if my points have already been raised, feel free to ignore me :) Cheers, Kuba
Re: The current char style UI
On Sat, Dec 06, 2003 at 04:53:05PM +0100, Lars Gullik Bjønnes spake thusly: Andre Poenitz [EMAIL PROTECTED] writes: | If the overlapping stuff is out and physical position == locical | position is in, all-boxes is (a) natural, (b) simple. I am not convinced... OTOH what I am convinced about is that we don't need to support overlapping stuff/nested LCS. Please elaborate. I think I agree (mostly), but want to see your arguments. - Martin pgp0.pgp Description: PGP signature
Re: [Patch] Re: [Patch] Re: CharStyle discussion
On Sat, Dec 06, 2003 at 01:10:29PM +0100, Juergen Spitzmueller spake thusly: Juergen Spitzmueller wrote: BTW is it possible to get rid of the space at the beginning of a char style inset? Apparently this has more than one source. One part of the problem is that the insettext inside the inset has indended paragraph if the document uses paragraph indendation. That is not the reason here. Irritating isn't it? Jürgen - Martin pgp0.pgp Description: PGP signature
Re: dvipng reports baseline
Angus Leeming wrote:
First, the preamble. I invoked dvipng so:
dvipng -bg 'rgb 0.980 0.941 0.902' -depth dvifile
OK, you do want the --height too, I guess?
[1 depth=13/home/angus/preview-latex/devel/dvipng/dvipng warning: at
(-155,18) unimplemented \special{ps::-32891 -32891 32891 32891 957561
564346 22609920}.
snip
1. Here I had colour specials in the latex file. In future I will not
need them, right? Instead I'll pass them direct to dvipng, as above.
Yes. You can do either.
2. I should prefer your -depth and -height flags, extracting the
metrics info from the output above, rather than extracting it from
the latex log file? Reason: the log file info is going to be wrong if
I invoke dvipng with the '-T tight' option, right? (and I would like
to do so so that I can strip off the front margin of a displaystyle
equation).
There are actually three ways to determine the boundingboxes.
1) -T tight which would make -depth -height necessary. You'd get
the boundingbox determined from the ink of the image.
2) From the output I see you have used the tightpage option to
preview, I have code lying around that will take the boundingboxes
from the specials instead, do you want that?
3) dvipng dvifile - will fire up the stdin interface where you
could input the dimensions yourself per page, as obtained from the
latex run. Once the stdin interface is up you give
-T 1in,1in -O 40sp,30sp -pp1 and then -T 3cm,3cm -O 3pt,5pt -pp2
and so on.
/JÅ
--
Death before dishonor. Nothing before coffee!
Re: [PATCH] Minipage
Am Samstag, 6. Dezember 2003 15:36 schrieb Juergen Spitzmueller: BTW what is the status of lyx2lyx in this regard? Do we need another file format change? We would have needed one when the box inset and the other changes were introduced. Now it is too late, because we have already several flavours of 225, and files do exist in these flavours. We gain nothing by creating a new file format subsequently now, we can as well declare the latest 225 to be the real 225 and consider tex2lyx and earlier versions of lyx that implement a different flavour broken. It would be nice if this could be handled better in the future. Georg
[PATCH] Inset VSpace for tex2lyx
The attached patch makes tex2lyx output an Inset VSpace where possible for
vertical spaces. Unfortunately it needed more code than I thought to handle
corner cases correctly. There are some overlaps with lyxlength.C
(translate_len() could vanish), but lyxlength.C needs some bufferview
stuff, so this cannot be used in the current form for tex2lyx.
However, I think that in the long term the length handling in LyX should be
unified. See the comment about text% in lengthcommon.h. I also see no
reason to disallow the use of \textheight etc. in the vspace inset, if
literal lengths are allowed.
A few testcases can be found in vspace-test2.tex.
Comments?
Georg
Index: lib/ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/lib/ChangeLog,v
retrieving revision 1.548
diff -u -p -r1.548 ChangeLog
--- lib/ChangeLog 2003/12/06 09:31:29 1.548
+++ lib/ChangeLog 2003/12/06 20:30:03
@@ -1,3 +1,7 @@
+2003-12-06 Georg Baum [EMAIL PROTECTED]
+
+ * reLyX/syntax.default: add \psfrag and \psfrag*
+
2003-12-06 Martin Vermeer [EMAIL PROTECTED]
* db_stdclass.inc:
Index: lib/reLyX/syntax.default
===
RCS file: /cvs/lyx/lyx-devel/lib/reLyX/syntax.default,v
retrieving revision 1.7
diff -u -p -r1.7 syntax.default
--- lib/reLyX/syntax.default 2003/02/11 13:32:13 1.7
+++ lib/reLyX/syntax.default 2003/12/06 20:30:11
@@ -545,6 +545,8 @@ $$
\providecommand{}[][]{}
\providecommand*{}[][]{}
\ps
+\psfrag{}[][][][]{translate}
+\psfrag*{}[][][][]{translate}
\pushtabs
% \put(,){} %picture
% \qbezier[](,)(,)(,) %picture
Index: src/tex2lyx/ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/src/tex2lyx/ChangeLog,v
retrieving revision 1.42
diff -u -p -r1.42 ChangeLog
--- src/tex2lyx/ChangeLog 2003/11/19 10:35:50 1.42
+++ src/tex2lyx/ChangeLog 2003/12/06 20:30:24
@@ -1,3 +1,14 @@
+2003-12-06 Georg Baum [EMAIL PROTECTED]
+
+ * text.C: Use the new VSpace inset (fixes a bug with added_space top)
+ * text.C: Fix \= in tabbing env again
+ * text.C: Fix invocation of parse_command()
+
2003-11-18 Georg Baum [EMAIL PROTECTED]
* tex2lyx.C:
Index: src/tex2lyx/Makefile.am
===
RCS file: /cvs/lyx/lyx-devel/src/tex2lyx/Makefile.am,v
retrieving revision 1.15
diff -u -p -r1.15 Makefile.am
--- src/tex2lyx/Makefile.am 2003/10/17 23:41:14 1.15
+++ src/tex2lyx/Makefile.am 2003/12/06 20:30:24
@@ -18,6 +19,7 @@ BUILT_SOURCES = \
FloatList.C \
Floating.C \
counters.C \
+ lengthcommon.C \
lyxlayout.h \
lyxlayout.C \
lyxtextclass.C \
Index: src/tex2lyx/text.C
===
RCS file: /cvs/lyx/lyx-devel/src/tex2lyx/text.C,v
retrieving revision 1.28
diff -u -p -r1.28 text.C
--- src/tex2lyx/text.C 2003/11/19 10:35:50 1.28
+++ src/tex2lyx/text.C 2003/12/06 20:30:33
@@ -16,6 +16,7 @@
#include tex2lyx.h
#include context.h
#include FloatList.h
+#include lengthcommon.h
#include support/lstrings.h
#include support/tostr.h
#include support/filetools.h
@@ -103,45 +104,80 @@ mapstring, string split_map(string con
return res;
}
-// A simple function to translate a latex length to something lyx can
-// understand. Not perfect, but rather best-effort.
-string translate_len(string const len)
+
+/*!
+ * Split a LaTeX length into value and unit.
+ * The latter can be a real unit like pt, or a latex length variable
+ * like \textwidth. The unit may contain additional stuff like glue
+ * lengths, but we don't care, because such lengths are ERT anyway.
+ * \return true if \param value and \param unit are valid.
+ */
+bool splitLatexLength(string const len, string value, string unit)
{
- const string::size_type i = len.find_first_not_of( -0123456789.,);
+ if (len.empty())
+ return false;
+ const string::size_type i = len.find_first_not_of( -+0123456789.,);
//'4,5' is a valid LaTeX length number. Change it to '4.5'
string const length = lyx::support::subst(len, ',', '.');
- // a normal length
- if (i == string::npos || len[i] != '\\')
- return length;
- double val;
+ if (i == string::npos)
+ return false;
if (i == 0) {
- // We had something like \textwidth without a factor
- val = 100;
+ if (len[0] == '\\') {
+ // We had something like \textwidth without a factor
+ value = 1.0;
+ } else {
+ return false;
+ }
} else {
- istringstream iss(string(length, 0, i));
- iss val;
- val = val * 100;
+ value = trim(string(length, 0, i));
}
+ if (value == -)
+ value = -1.0;
+ // 'cM' is a valid LaTeX length unit. Change it to 'cm'
+ if (lyx::support::contains(len, '\\'))
+ unit = trim(string(len, i));
+ else
+ unit = lyx::support::lowercase(trim(string(len, i)));
+ return true;
+}
+
+
+// A simple function to translate a latex length to something lyx can
+// understand. Not perfect, but rather best-effort.
+string
Re: [PATCH] Minipage
Am Samstag, 6. Dezember 2003 17:48 schrieb Juergen Spitzmueller: Georg Baum wrote: Yes please, until tex2lyx is adapted to output the box inset instead of minipage. Hm, my patch does not make anything worse. tex2lyx produces \lyxformat 225 files, while lyx2lyx's minipage-box conversion happens between 223 and 225. So files with minipages produced with this version of tex2lyx will cause problems (as Kornel's file) in any case, unless we bump version to 226 and shift the minipage-box conversion to 225-226. Try it: Current LyX without your patch can read the minipages that tex2lyx currently produces (although they cannot be inserted via menu anymore). Georg
Re: Sheesh we've been busy --- or have we?
On Fri, Dec 05, 2003 at 03:10:35PM +, Angus Leeming spake thusly: Angus Leeming wrote: All that activity --- a whole year's worth --- and the source has grown by just 7373 lines!!! and if you strip out all comments, then there's even less: 113174 lines of code in 13x/src 117040 lines of code in 14x/src Net gain 3866 lines. What I would especially like to see is how the 'core' has behaved on this score -- and the balance core/outside-core stuff, which generally is much better structured. Would core == src minus subdirectories hold approximately? - Martin pgp0.pgp Description: PGP signature
Re: [PATCH] Minipage
-BEGIN PGP SIGNED MESSAGE- On Samstag, 6. Dezember 2003 22:19, Georg Baum wrote: Am Samstag, 6. Dezember 2003 17:48 schrieb Juergen Spitzmueller: Georg Baum wrote: Yes please, until tex2lyx is adapted to output the box inset instead of minipage. Hm, my patch does not make anything worse. tex2lyx produces \lyxformat 225 files, while lyx2lyx's minipage-box conversion happens between 223 and 225. So files with minipages produced with this version of tex2lyx will cause problems (as Kornel's file) in any case, unless we bump version to 226 and shift the minipage-box conversion to 225-226. Try it: Current LyX without your patch can read the minipages that tex2lyx currently produces (although they cannot be inserted via menu anymore). You can produce them with M-x minipage-insert Georg Kornel - -- Kornel Benko [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) iQCVAwUBP9JRjLewfbDGmeqhAQGP8wP/X86A9MKGq+4GwUhCvJalyU4edtNGucnC 4dLJEjz6iX3yQxbnLzqKPKmdsH7ckW5T8Xlul3/hR5Mob7aWI7A74glKS94Bg1wy fhrCX5wZl/D+XhDZ/65RaQuIYIr7RwzbNWSFAE13Pc2aCdUHGM6rnB6mTBkqHZ9r 289PTaLo6pQ= =CXE9 -END PGP SIGNATURE-
Re: annoying mathed-behaviour (was Re: The current char style UI)
On Fri, Dec 05, 2003 at 07:49:38PM +0100, Christian Ridderström spake thusly:
> In case that was unclear, here's an example:
>
> a^2+\textrm{aFunction}+2|
>
> pressing backspace gives
>
> a^2+\textrm{aFunction}+|
>
> backspace again...
>
> a^2+\textrm{aFunction}|
>
> now when you press backspace, the textinset isn't deleted, but highlighted
> and a cute text shows up on the statusbar saying "Press delete again to
> actually delete".
>
> a^2+\textrm{aFunction}|
> \---delete?--\
>
> and then when you press delete again, you end up with
>
> a^2+|
>
> /Christian
This is actually not a bad idea. But we sort-of have this now already.
In MathEd, I never delete anything but single characters straightaway.
I don't dare to :-( If I want to delete a bracketed expression etc., I
always select it first to see its extent.
One could in the above situation make the first backspace invoke
selection of the previous bracketed expression. I don't know how hard
that is to implement.
> --
> Christian Ridderström http://www.md.kth.se/~chr
- Martin
pgp0.pgp
Description: PGP signature
Re: [Patch] Re: [Patch] Re: CharStyle discussion
On Fri, Dec 05, 2003 at 12:54:58PM +0200, Martin Vermeer spake thusly: > Patch attached. As I haven't heard any real objections (just blue-sky > ideas building on it) I'll commit later today. Committed. I fixed one more bug: now the labelfont definition is actually used for the label (blue default font for all styles; twice reduced). Also the underline (now having two little end hooks) takes the label's colour. - Martin pgp0.pgp Description: PGP signature
Re: [Patch] Re: [Patch] Re: CharStyle discussion
Martin Vermeer wrote: > Committed. I fixed one more bug: now the labelfont definition is > actually used for the label (blue default font for all styles; twice > reduced). Also the underline (now having two little end hooks) takes > the label's colour. Looks very promising! I found one bug though. Special characters are not escaped inside the char style (I have tested noun). Type \today inside noun (not in ert) and you'll see what I mean. Jürgen BTW is it possible to get rid of the space at the beginning of a char style inset?
Re: [Patch] Re: [Patch] Re: CharStyle discussion
Juergen Spitzmueller wrote: > BTW is it possible to get rid of the space at the beginning of a char style > inset? Apparently this has more than one source. One part of the problem is that the insettext inside the inset has indended paragraph if the document uses paragraph indendation. Jürgen
[PATCH] Minipage
One for Angus... Now that the box inset superceeded minipage, it can theoretically be removed (or should we wait a bit)? Jürgen. minipage.diff.gz Description: GNU Zip compressed data
Re: [PATCH] Minipage
-BEGIN PGP SIGNED MESSAGE- On Samstag, 6. Dezember 2003 12:26, Juergen Spitzmueller wrote: > One for Angus... > Now that the box inset superceeded minipage, it can theoretically be removed > (or should we wait a bit)? With this patch, the minipages are read in as "boxed". Also the width of this inset is changed to 100 col%. (With the CVS-Version the value is 70 col%) Should I try to provide a test-file? > Jürgen. > Kornel - -- Kornel Benko [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) iQCVAwUBP9HWjLewfbDGmeqhAQFKRwP9E7nsyhPrPn4ynqsFGOC58LCXpkDT2eAw oUsC4MEFWpH75/XtYE1AJ5Nfc+nJSy3of6joKeFF/h6RWPB4GTcaa+f2O2o3xKA8 dLXnqNf4o38n0/VWkTB9QQeXw8Po/d1rUf7564PeuyBadnBtl5jpeeFxltXNGLaZ EGOtYSYzFSc= =5U5k -END PGP SIGNATURE-
Re: [PATCH] Minipage
Juergen Spitzmueller wrote: > One for Angus... > Now that the box inset superceeded minipage, it can theoretically be > removed (or should we wait a bit)? Yes please, until tex2lyx is adapted to output the box inset instead of minipage. Georg
Re: CharStyle discussion
On Fri, Dec 05, 2003 at 02:46:15PM +0100, Andre Poenitz wrote:
> On Fri, Dec 05, 2003 at 12:53:04PM +0100, Christian Ridderström wrote:
>
> > Note: Isn't it overkill drawing something that's emphasized using a box
> > AND (e.g.) italics? We don't want to flood the user with visual info.
>
> Interesting point. Hm, maybe. Maybe not, though...
>
Lyx knows that bold/italic/font/size/color shows visually, so not drawing
a box for those is possible. A language change or a user supplied
style (using \userunknownmarkup{}) could get a box/frame since there is no
way to distinguish it from other text.
There is also the option of light gray frames that aren't so striking.
They are weaker than the black text and therefore won't interfere much with reading.
Helge Hafting
Re: [PATCH] Minipage
Georg Baum wrote: > (or should we wait a bit)? > > Yes please, until tex2lyx is adapted to output the box inset instead of > minipage. ok. BTW what is the status of lyx2lyx in this regard? Do we need another file format change? Jürgen.
Re: [PATCH] Minipage
Kornel Benko wrote: > With this patch, the minipages are read in as "boxed". > Also the width of this inset is changed to 100 col%. (With the > CVS-Version the value is 70 col%) > > Should I try to provide a test-file? Yes please. I cannot reproduce. Here, a minipage from an 1.3.4 file with width=70 col% is read in correctly. Also examples/fr_Minipage.lyx. examples/ Minipage.lyx, however, is read in with a wrong width value, but this is the same in 1.3.4. Minipage.lyx uses width="45p%", which is not valid anymore (lyx2lyx issue?). Thanks, Jürgen.
Re: [PATCH] Minipage
-BEGIN PGP SIGNED MESSAGE- On Samstag, 6. Dezember 2003 15:51, Juergen Spitzmueller wrote: > Kornel Benko wrote: > > With this patch, the minipages are read in as "boxed". > > Also the width of this inset is changed to 100 col%. (With the > > CVS-Version the value is 70 col%) > > > > Should I try to provide a test-file? > > Yes please. I cannot reproduce. Here, a minipage from an 1.3.4 file with > width=70 col% is read in correctly. Also examples/fr_Minipage.lyx. examples/ > Minipage.lyx, however, is read in with a wrong width value, but this is the > same in 1.3.4. Minipage.lyx uses width="45p%", which is not valid anymore > (lyx2lyx issue?). This minipage example is a left over of previous lyx-1.4cvs versions. Kornel - -- Kornel Benko [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) iQCVAwUBP9Hug7ewfbDGmeqhAQGkCAP/R4kbMITD0u0blIJLJafBp6cMt7BXPzsP 6ouYQEIhrn2fIoWbXZguqvEA4L/UdblYCJFlMILTZWhEX6/ZSIYjwNTG3LJZ4Uge jlDnzejayhmS79M71cmV1yvDr61LEb7EZAy1YclIVJRUC1hHMYihtzE5bQjyXAFE LZnEbSK6gNE= =30sZ -END PGP SIGNATURE- #LyX 1.4.0cvs created this file. For more info see http://www.lyx.org/ \lyxformat 225 \textclass article \begin_preamble \end_preamble \language ngerman \inputencoding auto \fontscheme default \graphics default \paperfontsize default \spacing single \papersize Default \paperpackage a4 \use_geometry 0 \use_amsmath 1 \use_natbib 0 \use_numerical_citations 0 \paperorientation portrait \secnumdepth 3 \tocdepth 3 \paragraph_separation skip \defskip medskip \quotes_language english \quotes_times 2 \papercolumns 1 \papersides 1 \paperpagestyle default \bullet 2 0 9 -1 \end_bullet \tracking_changes 0 \end_header \begin_layout Standard \align center \begin_inset Minipage position 1 inner_position 0 height "0pt" width "70col%" collapsed false \begin_layout Standard oa_test soll ein plattformunabhängiges Testtool für Optical Archive auf Basis des C++ Toolkits sein. Es benutzt die aktuelle Version von OA für Linux in der Version 2.1 mit kleinen Anpassungen. \end_layout \end_inset \end_layout \end_document
Re: [PATCH] Minipage
Kornel Benko wrote: > This minipage example is a left over of previous lyx-1.4cvs versions. OK, your file has \lyxformat 225, while the Minipage->(Frameless) Boxes conversion is 223 -> 225. I'd say this is a bleeding edge result where I'd leave you on your own. If you change \lyxformat to 223, the minipage is read in correctly (also the width). Thanks, Jürgen.
Re: [PATCH] Minipage
Juergen Spitzmueller wrote: > Minipage.lyx, however, is read in with a wrong width value, but this is the > same in 1.3.4. Minipage.lyx uses width="45p%", which is not valid anymore > (lyx2lyx issue?). This is where this changed btw: http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/src/ lengthcommon.C.diff?r1=1.2=1.3 Regards, Jürgen
Re: The current char style UI
Andre Poenitz <[EMAIL PROTECTED]> writes: >> What I'm telling you is that the problem goes completely away with >> ranges, because we then have a natural interface: >> >> Edit->Text_Style->Noun >> Emphasis >> Badger >> Other... > | And? We just keep this. Clicking on this entry inserts a new inset of | this type. I am kindo with John, not that we must/should use ranges, but that the actual ui should not show that insets are used for this. In essence a LCS "inset" cannot just be a normal inset. -- Lgb
Re: The current char style UI
Andre Poenitz <[EMAIL PROTECTED]> writes: | If the overlapping stuff is out and physical position == locical | position is in, all-boxes is (a) natural, (b) simple. I am not convinced... OTOH what I am convinced about is that we don't need to support overlapping stuff/nested LCS. -- Lgb
Re: [patch] move ParagraphList of InsetText and Buffer to LyXText
Andre Poenitz <[EMAIL PROTECTED]> writes: | On Tue, Dec 02, 2003 at 04:49:26PM +0100, Lars Gullik Bjønnes wrote: >> Andre Poenitz <[EMAIL PROTECTED]> writes: >> >> | Step 2. Almost mechanical. >> >> I wonder why this is a good move. > | Because it consolidates common code of InsetText and Buffer in a single | place (LyXText). But hasn't this rendered multiple views of the same buffer virtually impossible? -- Lgb
Re: [PATCH] Minipage
Georg Baum wrote: > Yes please, until tex2lyx is adapted to output the box inset instead of > minipage. Hm, my patch does not make anything worse. tex2lyx produces \lyxformat 225 files, while lyx2lyx's minipage->box conversion happens between 223 and 225. So files with minipages produced with this version of tex2lyx will cause problems (as Kornel's file) in any case, unless we bump version to 226 and shift the minipage->box conversion to 225->226. Jürgen.
Re: [PATCH] Minipage
Juergen Spitzmueller wrote: > BTW what is the status of lyx2lyx in this regard? Do we need another file > format change? I found it. Jürgen
Re: new layout files for g-brief2
Hello sorry for taking that long time. I was very busy. Here is the patch. (against lyx-cvs) thanks felix Jean-Marc Lasgouttes wrote: >> "Felix" == Felix Kurth <[EMAIL PROTECTED]> writes: > > Felix> did you apply it ? Or there are any further thinks to do for me > Felix> ? > > I did not apply it yet, because I also need an entry for the > LaTeXConfig.lyx.in file describing what it is good for, where to find > it and (this is the part I cannot do myself) explaining how it relates > to g-brief. > > Feel free to ask if you need help on doing that. > > JMarc -- Felix Kurth pgp public key: http://www.fkurth.de/keys/felix.fkurth.asc key fingerprint: D401 DCF8 2BF8 50DF 2FAD 8136 C29B 83EE C0A1 F2AD--- LaTeXConfig.lyx.in 2003-09-22 10:47:09.0 +0200 +++ LaTeXConfig.lyx.in.new 2003-12-06 18:38:34.447188105 +0100 @@ -1133,6 +1133,58 @@ \begin_layout Subsection +g-brief2-en +\end_layout + +\begin_layout Description + +Found: @chk_g-brief2-en@ +\end_layout + +\begin_layout Description + +CTAN: +\family typewriter +macros/latex/contrib/supported/g-brief/ +\end_layout + +\begin_layout Description + +Notes: The document class +\family sans +g-brief2 +\family default + can be used to type commercial letters with a nice outfit. It's the successor of g-brief, its better configurable, but not backward compatible to g-brief. +\end_layout + +\begin_layout Subsection + +g-brief2-de +\end_layout + +\begin_layout Description + +Found: @chk_g-brief2-de@ +\end_layout + +\begin_layout Description + +CTAN: +\family typewriter +macros/latex/contrib/supported/g-brief/ +\end_layout + +\begin_layout Description + +Notes: The document class +\family sans +g-brief2-de +\family default + is the same as the above g-brief2-en only with german labels. Best for german letters. +\end_layout + +\begin_layout Subsection + hollywood \end_layout
Re: [PATCH] Minipage
-BEGIN PGP SIGNED MESSAGE- On Samstag, 6. Dezember 2003 16:33, Juergen Spitzmueller wrote: > Kornel Benko wrote: > > This minipage example is a left over of previous lyx-1.4cvs versions. > > OK, your file has \lyxformat 225, while the Minipage->(Frameless) Boxes > conversion is 223 -> 225. I'd say this is a bleeding edge result where I'd > leave you on your own. If you change \lyxformat to 223, the minipage is read > in correctly (also the width). I can live with this. Nonetheless it was still possible to insert such a minipage in current CVS (without your patch of course) Function "minipage-insert". Kornel - -- Kornel Benko [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) iQCVAwUBP9Iql7ewfbDGmeqhAQGf7gP9Hh8IdEUi1pcVP6bpa7jnRxci3Y+dbRuL Lz4JeQ4wlLqzkBAFD//Nfpr/2eFsbCQGFtdz0eE/3g1HqtoZorkD2ZCcb4dX08+x +4Yk5oTrUA1idblFi4rjLJUC2NthpfRT467A8DlECf4t6fNxom3MPP0LqhTntkIf CB1nW8URgIM= =wAhp -END PGP SIGNATURE-
Re: Sheesh we've been busy --- or have we?
On Friday 05 December 2003 06:56 pm, Michael Schmitt wrote: > > Angus Leeming wrote: > >>> All that activity --- a whole year's worth --- and the source has > >>> grown by just 7373 lines!!! > > > > and if you strip out all comments, then there's even less: > > 113174 lines of code in 13x/src > > 117040 lines of code in 14x/src > > Net gain 3866 lines. > > and then, if you compile LyX 1.3/1.4 and strip all debug symbols, you > will notice that the binary file has even become much smaller... > > -rwxr-xr-x1 programs users 6171740 2003-12-06 00:54 src/lyx > -rwxr-xr-x1 programs users 4135128 2003-12-06 00:53 src/lyx-qt > > _This_ is what I call surprising! And, what's even more surprising, all of this happened in spite of numerous ramblings on the list how lyx developers are making it into bloatware, etc. I guess that in the end it's the design that counts, and there's no amount of overdoing towards a better, more streamlined design. One can ask whether it's because using C++ features correctly will in the end produce better code, or whether the developers really headed those ramblings. I guess it's a bit of both. So, LyX seems to be progressing nicely in the right direction and, at lest from coders perspective, 1.4 should be much easier to work on. I imagine that many new features will be way easier to add to the new 1.4 architecture. Cheers, Kuba
Re: [PATCH] Re: Format=>Document=>Page size not working
On Friday 05 December 2003 05:07 am, Juergen Spitzmueller wrote: > Juergen Spitzmueller wrote: > > > My question (for 1.4.0cvs) would be why this isn't entirely within the > > > controller ? > > > > Yes, why not. Do you want to do it? > > My plan is to apply the 1.3 fix to 1.4 too for now. I don't have the time > to do the controller thing right now, and I don't want to leave it unfixed > in 1.4. It can always be improved. > > OK? I guess if you put a big // FIXME: this needs to go into the controller in some relevant place so that it's obvious which functionality one is talking about. Kuba
Re: CharStyle discussion
> Insets are an appropriate means for structured editing but they are not > suitable for writing consecutive text. If I had had to insert an inset > for every emphasized term, for every capitalized product name, for every > keyword in typewriter font, and for every figure reference in sans serif > in my PhD, I would have jumped out of the window!!! I guess one should keep in mind that insets are 99% programming paradigms, and only about 1% user-visible things. User has no concept of an inset. It all boils down to making the interface to creating such character-style insets an easy one. In such a case we have two possible behaviours: 1. MicroPro WordStar (last time I used it on a CP/M machine in mid-80's) approach: all formatting is an invisible character, so both "bold on" and "bold off" is an invisible character, and you can both delete it and you have to "jump over" it with arrow cursors if say you're moving cursor in the text with arrows (^S/^D for left/right anyone? :). Apparently, thousands of users found that acceptable and this is directly modeled by "right arrow only enters the inset", but it makes some problems with backspace -- essentially a backspace at the "bold end" character did expand the "bold" all the way to end of paragraph or somesuch, whereas in our case it would delete the whole inset. Not a nice thing. It may not be such a great idea nowadays methinks. 2. Your average editor approach - "insets" or whatever implements character styles are invisible. Backspace just outside of the right end of a "bold" inset should automatically enter the inset and then perform the action of backspace. I find that "2" is widely accepted nowadays. Implementation-wise I imagine that character-style insets are OK as long as certain things done just outside of both ends of the inset (say backspace on the right, delete on the left) first enter the inset and then feed-forward the action to the inset itself. There will also be some constraints as to how far a character style can go. I imagine we will artificially need to terminate all character styling at the end of the paragraph, otherwise it'll be an uncontainable mess. This may actually make sense for logical formatting - typically, you're making a word/sentence bolded, not the whole document; if it's the whole document you should adjust the default paragraph style properties (in LyX's case it would be more like document properties). I haven't read the whole thread yet, so if my points have already been raised, feel free to ignore me :) Cheers, Kuba
Re: The current char style UI
On Sat, Dec 06, 2003 at 04:53:05PM +0100, Lars Gullik Bjønnes spake thusly: > Andre Poenitz <[EMAIL PROTECTED]> writes: > > | If the overlapping stuff is out and physical position == locical > | position is in, all-boxes is (a) natural, (b) simple. > > I am not convinced... > > OTOH what I am convinced about is that we don't need to support > overlapping stuff/nested LCS. Please elaborate. I think I agree (mostly), but want to see your arguments. - Martin pgp0.pgp Description: PGP signature
Re: [Patch] Re: [Patch] Re: CharStyle discussion
On Sat, Dec 06, 2003 at 01:10:29PM +0100, Juergen Spitzmueller spake thusly: > > Juergen Spitzmueller wrote: > > BTW is it possible to get rid of the space at the beginning of a char style > > inset? > > Apparently this has more than one source. One part of the problem is that the > insettext inside the inset has indended paragraph if the document uses > paragraph indendation. That is not the reason here. Irritating isn't it? > Jürgen - Martin pgp0.pgp Description: PGP signature
Re: dvipng reports baseline
Angus Leeming wrote:
> First, the preamble. I invoked dvipng so:
> dvipng -bg 'rgb 0.980 0.941 0.902' -depth
OK, you do want the --height too, I guess?
> [1 depth=13/home/angus/preview-latex/devel/dvipng/dvipng warning: at
> (-155,18) unimplemented \special{ps::-32891 -32891 32891 32891 957561
> 564346 22609920}.
> 1. Here I had colour specials in the latex file. In future I will not
> need them, right? Instead I'll pass them direct to dvipng, as above.
Yes. You can do either.
> 2. I should prefer your -depth and -height flags, extracting the
> metrics info from the output above, rather than extracting it from
> the latex log file? Reason: the log file info is going to be wrong if
> I invoke dvipng with the '-T tight' option, right? (and I would like
> to do so so that I can strip off the front margin of a displaystyle
> equation).
There are actually three ways to determine the boundingboxes.
1) "-T tight" which would make "-depth -height" necessary. You'd get
the boundingbox determined from the ink of the image.
2) From the output I see you have used the "tightpage" option to
preview, I have code lying around that will take the boundingboxes
from the specials instead, do you want that?
3) "dvipng -" will fire up the stdin interface where you
could input the dimensions yourself per page, as obtained from the
latex run. Once the stdin interface is up you give
"-T 1in,1in -O 40sp,30sp -pp1" and then "-T 3cm,3cm -O 3pt,5pt -pp2"
and so on.
/JÅ
--
Death before dishonor. Nothing before coffee!
Re: [PATCH] Minipage
Am Samstag, 6. Dezember 2003 15:36 schrieb Juergen Spitzmueller: > BTW what is the status of lyx2lyx in this regard? Do we need another file > format change? We would have needed one when the box inset and the other changes were introduced. Now it is too late, because we have already several "flavours" of 225, and files do exist in these "flavours". We gain nothing by creating a new file format subsequently now, we can as well declare the "latest 225" to be the "real 225" and consider tex2lyx and earlier versions of lyx that implement a different flavour broken. It would be nice if this could be handled better in the future. Georg
[PATCH] Inset VSpace for tex2lyx
The attached patch makes tex2lyx output an Inset VSpace where possible for
vertical spaces. Unfortunately it needed more code than I thought to handle
corner cases correctly. There are some overlaps with lyxlength.C
(translate_len() could vanish), but lyxlength.C needs some bufferview
stuff, so this cannot be used in the current form for tex2lyx.
However, I think that in the long term the length handling in LyX should be
unified. See the comment about "text%" in lengthcommon.h. I also see no
reason to disallow the use of \textheight etc. in the vspace inset, if
literal lengths are allowed.
A few testcases can be found in vspace-test2.tex.
Comments?
Georg
Index: lib/ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/lib/ChangeLog,v
retrieving revision 1.548
diff -u -p -r1.548 ChangeLog
--- lib/ChangeLog 2003/12/06 09:31:29 1.548
+++ lib/ChangeLog 2003/12/06 20:30:03
@@ -1,3 +1,7 @@
+2003-12-06 Georg Baum <[EMAIL PROTECTED]>
+
+ * reLyX/syntax.default: add \psfrag and \psfrag*
+
2003-12-06 Martin Vermeer <[EMAIL PROTECTED]>
* db_stdclass.inc:
Index: lib/reLyX/syntax.default
===
RCS file: /cvs/lyx/lyx-devel/lib/reLyX/syntax.default,v
retrieving revision 1.7
diff -u -p -r1.7 syntax.default
--- lib/reLyX/syntax.default 2003/02/11 13:32:13 1.7
+++ lib/reLyX/syntax.default 2003/12/06 20:30:11
@@ -545,6 +545,8 @@ $$
\providecommand{}[][]{}
\providecommand*{}[][]{}
\ps
+\psfrag{}[][][][]{translate}
+\psfrag*{}[][][][]{translate}
\pushtabs
% \put(,){} %picture
% \qbezier[](,)(,)(,) %picture
Index: src/tex2lyx/ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/src/tex2lyx/ChangeLog,v
retrieving revision 1.42
diff -u -p -r1.42 ChangeLog
--- src/tex2lyx/ChangeLog 2003/11/19 10:35:50 1.42
+++ src/tex2lyx/ChangeLog 2003/12/06 20:30:24
@@ -1,3 +1,14 @@
+2003-12-06 Georg Baum <[EMAIL PROTECTED]>
+
+ * text.C: Use the new VSpace inset (fixes a bug with added_space top)
+ * text.C: Fix \= in tabbing env again
+ * text.C: Fix invocation of parse_command()
+
2003-11-18 Georg Baum <[EMAIL PROTECTED]>
* tex2lyx.C:
Index: src/tex2lyx/Makefile.am
===
RCS file: /cvs/lyx/lyx-devel/src/tex2lyx/Makefile.am,v
retrieving revision 1.15
diff -u -p -r1.15 Makefile.am
--- src/tex2lyx/Makefile.am 2003/10/17 23:41:14 1.15
+++ src/tex2lyx/Makefile.am 2003/12/06 20:30:24
@@ -18,6 +19,7 @@ BUILT_SOURCES = \
FloatList.C \
Floating.C \
counters.C \
+ lengthcommon.C \
lyxlayout.h \
lyxlayout.C \
lyxtextclass.C \
Index: src/tex2lyx/text.C
===
RCS file: /cvs/lyx/lyx-devel/src/tex2lyx/text.C,v
retrieving revision 1.28
diff -u -p -r1.28 text.C
--- src/tex2lyx/text.C 2003/11/19 10:35:50 1.28
+++ src/tex2lyx/text.C 2003/12/06 20:30:33
@@ -16,6 +16,7 @@
#include "tex2lyx.h"
#include "context.h"
#include "FloatList.h"
+#include "lengthcommon.h"
#include "support/lstrings.h"
#include "support/tostr.h"
#include "support/filetools.h"
@@ -103,45 +104,80 @@ map split_map(string con
return res;
}
-// A simple function to translate a latex length to something lyx can
-// understand. Not perfect, but rather best-effort.
-string translate_len(string const & len)
+
+/*!
+ * Split a LaTeX length into value and unit.
+ * The latter can be a real unit like "pt", or a latex length variable
+ * like "\textwidth". The unit may contain additional stuff like glue
+ * lengths, but we don't care, because such lengths are ERT anyway.
+ * \return true if \param value and \param unit are valid.
+ */
+bool splitLatexLength(string const & len, string & value, string & unit)
{
- const string::size_type i = len.find_first_not_of(" -0123456789.,");
+ if (len.empty())
+ return false;
+ const string::size_type i = len.find_first_not_of(" -+0123456789.,");
//'4,5' is a valid LaTeX length number. Change it to '4.5'
string const length = lyx::support::subst(len, ',', '.');
- // a normal length
- if (i == string::npos || len[i] != '\\')
- return length;
- double val;
+ if (i == string::npos)
+ return false;
if (i == 0) {
- // We had something like \textwidth without a factor
- val = 100;
+ if (len[0] == '\\') {
+ // We had something like \textwidth without a factor
+ value = "1.0";
+ } else {
+ return false;
+ }
} else {
- istringstream iss(string(length, 0, i));
- iss >> val;
- val = val * 100;
+ value = trim(string(length, 0, i));
}
+ if (value == "-")
+ value = "-1.0";
+ // 'cM' is a valid LaTeX length unit. Change it to 'cm'
+ if (lyx::support::contains(len, '\\'))
+ unit = trim(string(len, i));
+ else
+ unit = lyx::support::lowercase(trim(string(len, i)));
+ return true;
+}
+
+
+// A simple function to translate a latex length to something lyx can
+// understand. Not
Re: [PATCH] Minipage
Am Samstag, 6. Dezember 2003 17:48 schrieb Juergen Spitzmueller: > Georg Baum wrote: > > Yes please, until tex2lyx is adapted to output the box inset instead of > > minipage. > > Hm, my patch does not make anything worse. tex2lyx produces \lyxformat > 225 files, while lyx2lyx's minipage->box conversion happens between 223 > and 225. So files with minipages produced with this version of tex2lyx > will cause problems (as Kornel's file) in any case, unless we bump > version to 226 and shift the minipage->box conversion to 225->226. Try it: Current LyX without your patch can read the minipages that tex2lyx currently produces (although they cannot be inserted via menu anymore). Georg
Re: Sheesh we've been busy --- or have we?
On Fri, Dec 05, 2003 at 03:10:35PM +, Angus Leeming spake thusly: > Angus Leeming wrote: > > All that activity --- a whole year's worth --- and the source has > > grown by just 7373 lines!!! > > and if you strip out all comments, then there's even less: > 113174 lines of code in 13x/src > 117040 lines of code in 14x/src > Net gain 3866 lines. What I would especially like to see is how the 'core' has behaved on this score -- and the balance core/outside-core stuff, which generally is much better structured. Would core == src minus subdirectories hold approximately? - Martin pgp0.pgp Description: PGP signature
Re: [PATCH] Minipage
-BEGIN PGP SIGNED MESSAGE- On Samstag, 6. Dezember 2003 22:19, Georg Baum wrote: > Am Samstag, 6. Dezember 2003 17:48 schrieb Juergen Spitzmueller: > > Georg Baum wrote: > > > Yes please, until tex2lyx is adapted to output the box inset instead of > > > minipage. > > > > Hm, my patch does not make anything worse. tex2lyx produces \lyxformat > > 225 files, while lyx2lyx's minipage->box conversion happens between 223 > > and 225. So files with minipages produced with this version of tex2lyx > > will cause problems (as Kornel's file) in any case, unless we bump > > version to 226 and shift the minipage->box conversion to 225->226. > > Try it: Current LyX without your patch can read the minipages that tex2lyx > currently produces (although they cannot be inserted via menu anymore). > You can produce them with M-x minipage-insert > Georg > Kornel - -- Kornel Benko [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) iQCVAwUBP9JRjLewfbDGmeqhAQGP8wP/X86A9MKGq+4GwUhCvJalyU4edtNGucnC 4dLJEjz6iX3yQxbnLzqKPKmdsH7ckW5T8Xlul3/hR5Mob7aWI7A74glKS94Bg1wy fhrCX5wZl/D+XhDZ/65RaQuIYIr7RwzbNWSFAE13Pc2aCdUHGM6rnB6mTBkqHZ9r 289PTaLo6pQ= =CXE9 -END PGP SIGNATURE-
