[PATCH] small change to tabular to write attributes in XML style
Hello,
I noticed that the change was both backward and forward compatible (I
did not need to change the methods for reading) so I did it.
I have added 2 local methods to write attributes because using "<<"
would have been awkward : there would have been so many "\"" all around.
I believe it would be nice to create a LyxOutputStream replacement for
ostream that would contain such methods. This way we would make it
easier to write XML-like everywhere in LyX.
Then we could add methods like :
- outputInset(char * buff)
etc.
And we should choose something similar for the input. If you agree, we
could probably make most of the LyX file format XML-like in a few weeks.
This would be a great asset for those who need to transform LyX files.
sincerely,
P.O. Gaillard
915c915,922
<
---
> void LyXTabular::write_attribute( ostream & os, const char *name, int value) const
> {
> os << " " << name << "=\"" << value << "\"";
> }
> void LyXTabular::write_attribute( ostream & os, const char *name, const string
>&value) const
> {
> os << " " << name << "=\"" << value << "\"";
> }
921,922c928,932
< os << "" << endl;
---
> os << " write_attribute(os,"version",1);
> write_attribute(os,"rows", rows_);
> write_attribute(os,"columns", columns_);
> os <<">" << endl;
924,928c934,941
< os << "" << endl << endl;
---
> os << " write_attribute(os,"rotate",rotate);
> write_attribute(os,"islongtable",is_long_tabular);
> write_attribute(os,"endhead",endhead );
> write_attribute(os,"endfirsthead", endfirsthead);
> write_attribute(os,"endfoot", endfoot);
> write_attribute(os,"endlastfoot", endlastfoot);
> os << ">" << endl << endl;
930,933c943,947
< os << "" << endl;
---
> os << " write_attribute(os,"topline",row_info[i].top_line);
> write_attribute(os,"bottomline" , row_info[i].bottom_line);
> write_attribute(os,"newpage" , row_info[i].newpage);
> os << ">" << endl;
936,942c950,957
< os << "" << endl;
---
> os << " write_attribute(os,"alignment", column_info[j].alignment );
> write_attribute(os,"valignment", column_info[j].valignment);
> write_attribute(os," leftline", column_info[j].left_line);
> write_attribute(os," rightline", column_info[j].right_line);
> write_attribute(os," width",
>VSpace(column_info[j].p_width).asLyXCommand());
> write_attribute(os,"special" , column_info[j].align_special);
> os << ">" << endl;
946,957c961,973
< os << "" << endl;
---
> os << " write_attribute(os, "multicolumn", cell_info[i][j].multicolumn);
> write_attribute(os, "alignment", cell_info[i][j].alignment );
> write_attribute(os, "valignment", cell_info[i][j].valignment);
> write_attribute(os, "topline", cell_info[i][j].top_line);
> write_attribute(os, "bottomline", cell_info[i][j].bottom_line);
> write_attribute(os, "leftline", cell_info[i][j].left_line );
> write_attribute(os, "rightline", cell_info[i][j].right_line);
> write_attribute(os, "rotate", cell_info[i][j].rotate);
> write_attribute(os, "usebox", (int)cell_info[i][j].usebox);
> write_attribute(os, "width", cell_info[i][j].p_width );
> write_attribute(os, "special", cell_info[i][j].align_special);
> os << ">" << endl;
266a267,270
> void write_attribute(std::ostream &, const char* name, int value ) const;
> ///
> void write_attribute(std::ostream &, const char* name, const string & value )
>const;
> ///
Re: small problem in lyxstring constructor
> I have anoter proposal: Since there is a n argument, we can expect
> this to be meeningful, so:
I think so, too.
> lyxstring::lyxstring(value_type const * s, size_type n)
> {
> Assert(s && n < npos); // STD!
> static Srep empty_rep(0, "");
> if (*s && n) { // s is not empty string and n > 0
> rep = new Srep(n, s);
> } else {
> ++empty_rep.ref;
> rep = &empty_rep;
> }
> }
>
> But we should check the standard, and see if a '\0' teminated string
> is required, and wat values of n is allowed.
'n' is the authority in question here. You can store and retrieve as many
'\0' char in a std::string. They are 'ordinary' characters there.
Andre'
--
Andre' Poenitz [EMAIL PROTECTED]
Re: Another memory leak (LyXParagraph::SetFont)
> This shouldn't leak. And yes, it is a copy of FontTable(pos, font) > which is inserted into the fontlist. But the FontTable destructor and > LyXfont's destructor should take care of cleaning up in this case. > > This could be a but in te vector template. I doubt that. If it was a leak in vector, it'd quite probably leak in other cases, too. I rather suspect something fishy in the respective items of the vector. I had a look but did not find anything. Anyway, I would suggest to change a couple of pointers to references just to remove sources of potential problems. E.g. Language could have an Encoding _reference_. It is never changed after construction. Andre' -- Andre' Poenitz [EMAIL PROTECTED]
Re: Insets, changebars, XML
> 3) I did not find command-line options to get lyx to print a document > and exit without open any X display. >How hard would that be to achieve ? Running LyX without X is still difficult. You might want to experiment with something like Xvfb :1 800x600x16 ; lyx -display :1 --export ps file.lyx ; lpr file.ps or browse the mailing list archive for hints concerning the exact syntax. Andre' -- Andre' Poenitz [EMAIL PROTECTED]
Re: inset questions
On Fri, 22 Sep 2000, Angus Leeming wrote: > 5. We need some method of toggling between the three LaTeX output states. As > the left mouse button opens the inset, this leaves the right mouse button. > Jürgen seems very against using this to toggle between states, so RMB will > launch a (very small) dialog containing only a "choice of output" menu. No > "Ok" or "Cancel" buttons are needed, I think. (Now I think of it, haven't I > just defined a context-sensitive menu form?) It seems to me that "Cancel" is needed always. In this case, it will be the same for user as to close context-sensitive menu without selecting anything by pressing mouse button outside the menu area. Marko
Re: Lost math bindings
On Fri, 22 Sep 2000, Garst R. Reese wrote: > I'll expand my earlier suggestion. > Let menu shortcuts be M-Uppercase letter > bindings M-lowercase letter > The menus all start with an uppercase letter anyway. > When in math mode in particular I prefer not to have to resort to the > menu and want things as simple as possible. > Going to a menu my expectation is to use the mouse and I am there much > less often than in the middle of a doc, so the extra key to press is no > problem > M-"S-f" > I would not like to see the math menu nuked. And LyX will be the only program I know to do that :). Actually, I know a lot of people who open menu and select menu item by keyboard only using M-f o, for example. Marko
Re: Lost math bindings
Marko Vendelin wrote: > > On Fri, 22 Sep 2000, Garst R. Reese wrote: > > > I'll expand my earlier suggestion. > > Let menu shortcuts be M-Uppercase letter > > bindings M-lowercase letter > > The menus all start with an uppercase letter anyway. > > When in math mode in particular I prefer not to have to resort to the > > menu and want things as simple as possible. > > Going to a menu my expectation is to use the mouse and I am there much > > less often than in the middle of a doc, so the extra key to press is no > > problem > > M-"S-f" > > I would not like to see the math menu nuked. > > And LyX will be the only program I know to do that :). LyX is the only program that does a lot of things right :)! File Edit ... Help, all begin with caps. > Actually, I know a lot of people who open menu and select menu item by keyboard > >only using M-f o, for example. Yes, but the point is that you open files much less often than you input text to files, and for math and ERT junkies the text is mostly g(r)eek :) > Marko
Re: Lost math bindings
lars lamented, > Alejandro Aguilar Sierra <[EMAIL PROTECTED]> writes: > | Yes, LyX had the hability to give users the choice to use the interface > | they liked the more. Is really necessary to take away that? > We won't take away _anything_ from the user. The question is how LyX > should be configured by default. In this particualr case, though, I think we need to do something quickly. Without the bindings, LyX is currently unusable for us keystroke junkies whow write math . . . I'm forced to use the older version fromm debian, wiht the incompatible tables . . . I'd label restoration of keybindings as a "must" before release. --
Re: Lost math bindings
[EMAIL PROTECTED] wrote: > > lars lamented, > > > Alejandro Aguilar Sierra <[EMAIL PROTECTED]> writes: > > > | Yes, LyX had the hability to give users the choice to use the interface > > | they liked the more. Is really necessary to take away that? > > > We won't take away _anything_ from the user. The question is how LyX > > should be configured by default. > > In this particualr case, though, I think we need to do something > quickly. Without the bindings, LyX is currently unusable for us > keystroke junkies whow write math . . . I'm forced to use the older > version fromm debian, wiht the incompatible tables . . . > > I'd label restoration of keybindings as a "must" before release. > > -- Did you see my proposal to use M-capital-letters for menu shortcuts, which would leave M-m available for math key bindings. Would you find that acceptable? Marko observed: And LyX will be the only program I know to do that :). Actually, I know a lot of people who open menu and select menu item by keyboard only using M-f o, for example. - But LyX does not have rulers, tabs, doublespaces after periods either. And how many other programs have hollywood and broadway :) Garst
Re: cvs --with-pspell no go
Juergen Vigna wrote:
>
> On 22-Sep-2000 Juergen Vigna wrote:
>
> > Any idea?
>
> I got it working (just followed the pspell manual ;), now we can
> spellcheck also other language directories (or canadian for Garst :)
> with the pspell module.
>
> What now is missing is:
>
> - multi language documents
> - pspell-library not segfaulting on us on long documents
>
> Jürgen
I had to make the change in the attached diff to language.C.
This lets aspell work. Kevin says pspell will still not work, but will
be fixed in his next release.
There are probably other changes needed. I have obtained the ISO
language and country codes and will peruse the list.
Garst
--- language.C Sat Sep 23 02:22:57 2000
+++ language.C.new Sat Sep 23 02:22:39 2000
@@ -61,6 +61,7 @@
{ "bahasa", N_("Bahasa"), false, &iso8859_1, "" },
{ "brazil", N_("Brazil"), false, &iso8859_1, "" },
{ "breton", N_("Breton"), false, &iso8859_1, "" },
+ { "canadian", N_("Canadian"), false, &iso8859_1, "en_CA" },
{ "catalan", N_("Catalan"), false, &iso8859_1, "" },
{ "croatian", N_("Croatian"), false, &iso8859_2, "" },
{ "czech", N_("Czech"), false, &iso8859_2, "" },
Re: Lost math bindings
On 23 Sep 2000, Lars Gullik Bjønnes wrote: > I hope you realize that one of the reasons for our "great" flexibility > was a bug in XForms. > > Currently menu shortcuts are caught by _XForms_ not by LyX. This is > because of the new menucode that is heaps better than the old one. That is ok and it's not the point of the discussion. Will I be able to use M-m for math commands if I like so, even if that's not the default configuration? Alejandro
Re: Lost math bindings
garst gabbed, > > I'd label restoration of keybindings as a "must" before release. > Did you see my proposal to use M-capital-letters for menu shortcuts, > which would leave M-m available for math key bindings. > Would you find that acceptable? I *think* so, but in all honesty, I'd probably have to give it a try. Even though I use the bindings all the time, I really have no idea how many(iv any) actually use upper case bindings (a summation is M-m U, isn't it? My fingers know, but I don't :) But my fingers knowing leasds to the crux of the problem: changes in commands are *bad* and should be avoided if at all possible. To change from what works now, we should seriously believe that the new version will be enough *forever*. Also, I think it leaves room for user confusion; as someone mentioned, it isn't how people expect most programs to work (though I doubt I'd be bothered by it). I'd lean towards either the M-a for math or eliminating the math menu altogether. Probably the latter, as it strikes me that the whole floating set of tools will be necessary when folks start working with math. It will also cause less problems with obstruction of the text . . . hawk --
language.C
Attached is a proposed replacement for language.C ChangeLog Add langage_country codes to satisfy the requirements of aspell/pspell delete english (this could be just a problem with the default config of aspell. english gets the american dict.) add british (this is certainly less ambiguous. en_EN changed to en_GB) add canadian (english) add canadien (french) Problems: What country code to assign to esperanto? I don't have a clue to lsorbian or usorbian. Garst language.C.gz
Re: Tasks for 1.1.6!
InsetGraphics has two important features that are still missing but is supposedly mostly ready besides them, it might need some cleaning up and verifying that it still works (I haven't touched it in the last three weeks or so). The two features that need to be done for it directly are: 1. Automatic conversion of image formats, this is used to support image formats other than EPS and PNG and to use EPS in PDF production seamlessly. 2. Inline viewing of the graphics, including the transformations (rotation and scaling). Work that is dependend upon by InsetGraphics includes the Convertor of Dekel Tsur and the needed support for configuration scripts to add the convertors of various image formats. The inline viewing is dependent upon the convertor and some not so small foundation in order to make it GUII. It is possible to ADD the InsetGraphics and use it alongside the FigInset as it currently stands, this will be a good idea in order to support those who want PDF production since the image conversion will not need a lot of work but the inline viewing might be slow to come. -- Baruch Even http://techst02.technion.ac.il/~sbaruch/ (My Site) http://www.redrival.com/jindor/(My brothers AD&D site) " Learn to laugh ... it's the path to true love! " - The Angel in the movie Michael
Re: language.C
On Sat, 23 Sep 2000, Garst R. Reese wrote: > Problems: What country code to assign to esperanto? None, many of the other languages should probally not have country codes. I also suggest you bring back english and just make it "en". -- Kevin Atkinson kevina at users sourceforge net http://metalab.unc.edu/kevina/
Re: language.C
Kevin Atkinson wrote: > > On Sat, 23 Sep 2000, Garst R. Reese wrote: > > > Problems: What country code to assign to esperanto? > > None, many of the other languages should probally not have country > codes. I also suggest you bring back english and just make it "en". > Well, I thought you said you required the language+country code. I'll leave the refinements people who speak the languages. My primary goal was to provide a working list. I thought english pointing to american was confusing. I'll let others decide. Garst
Re: language.C
On Sat, 23 Sep 2000, Garst R. Reese wrote: > Kevin Atkinson wrote: > > > > On Sat, 23 Sep 2000, Garst R. Reese wrote: > > > > > Problems: What country code to assign to esperanto? > > > > None, many of the other languages should probally not have country > > codes. I also suggest you bring back english and just make it "en". > > > Well, I thought you said you required the language+country code. Sorry if I gave you that impression. The country code is optional. > I'll leave the refinements people who speak the languages. My primary > goal was to provide a working list. > I thought english pointing to american was confusing. I'll let others > decide. OK --- Kevin Atkinson kevina at users sourceforge net http://metalab.unc.edu/kevina/
