Re: [PATCH] Some code factorization in toolbars
On Fri, Nov 12, 2004 at 03:56:20PM +0100, Jean-Marc Lasgouttes wrote: > >>>>> "José" == José Abílio Oliveira Matos <[EMAIL PROTECTED]> writes: > > José> Clearly if I implement this feature it will have a lot more > José> flexibility than that. Including conditional convertions > José> depending on the version available is too easy to do. > > José> Also it would allow more inteligent convertions than simply > José> replacing one layout name by another. > > Maybe you're right. My concern is that it removes some power from the hands > of people who want to distribute their own layout files without > including them in LyX. I do not know whether that matters in the end. But if we allow people to be able to plugin modules to lyx2lyx based on their own layouts that would a win even for layouts that we don't distribute. :-) In a sense we are already doing it for the layouts we distribute. :-) Introducing transformations based on the layout. What I want to do it is put this under the umbrela of lyx2lyx. > JMarc PS: I'm leaving Dublin today and forgot to take a Guiness during this two months. Oops. :-) -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [patch] tfrac
On Thu, Nov 11, 2004 at 09:25:57AM +0100, Alfredo Braunstein wrote: > Should I apply this now? > > Alfredo I think so. Lars only commented the code since André forgot to add those to cvs. -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH] Some code factorization in toolbars
On Tue, Nov 09, 2004 at 04:05:28PM +0100, Jean-Marc Lasgouttes wrote: > > José> Notice that we can remove the support for obsolete layouts > José> from the textclass and pass them to lyx2lyx. Even use a user > José> defined file to do this convertion. What do you think? > > I know, but I am ambivalent about that. I like the fact that somebody > outside of the LyX team can distribute a layout file and have a way to > deprecate layouts. Such layout files exist in the beamer class, for > example. The ObsoletedBy system is pretty simple and is actually > useful. Yes, but that was clearly a hack for those times before lyx2lyx. > Moreover, using lyx2lyx to do this conversion only works if you can > tie some version of a layout file to some version of LyX. This does > not hold for layout files distributed outside of LyX. Who said so? ;-) Clearly if I implement this feature it will have a lot more flexibility than that. Including conditional convertions depending on the version available is too easy to do. Also it would allow more inteligent convertions than simply replacing one layout name by another. > JMarc -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: LyX Status
On Tue, Nov 09, 2004 at 11:39:50AM +, Andreas Vox wrote: > > Branches work fine except two minor quirks: > * If you insert a branch for the whole section, the layout becomes "standard" >inside the branch inset and stays section outside, causing empty sectgions. Could you give an example of that? The lyx file is OK. It should be easy to fix now. > * Always deactivates branches after opening (is this wanted?) > > /Andreas -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH] Some code factorization in toolbars
On Tue, Nov 09, 2004 at 01:38:49PM +0100, Jean-Marc Lasgouttes wrote: > > What makes it a bit complicated is that obsolete layouts, which do > have an index in the list of layouts, do not appear in the combox. So > using indices means more work. Notice that we can remove the support for obsolete layouts from the textclass and pass them to lyx2lyx. Even use a user defined file to do this convertion. What do you think? > JMarc -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH][Bug 1720] LyX/Mac: Menus are not correctly disabled when a dialog has focus
On Mon, Nov 08, 2004 at 10:55:53PM +, Andreas Vox wrote: > > > (Are you listening Lars?) > > > > :-D > > Why is everyone flame-baiting always Lars, I wonder? FWIW I wasn't flame-baiting Lars, there times where Lars (as any of us) deserves criticism, but not this time. For those who don't know one of Lars goals would be to have a curses (probably ncurses) frontend for lyx. It is an interesting objective by itself, and I was playing with that and not trying to be sarcastic. > /Andreas -- José Abílio Matos LyX and docbook a perfect match. :-)
LyX Status
Hi all, cutting the nonsense and being objective what needs to be done to release a stable 1.4.0? Is it reasonable to have a HEAD that has problems while Alfredo is fixing the bugs in the other branch? Looking in bugzilla for bugs related with 1.4.0, blocker, critical, major and normal I see 22. Is this up to date? What needs to be done to clean this? What are the subjects that other developers are working and would like to have fixed before 1.4.0 release? Here is my list: lyx2lyx - improve the resilence of lyx2lyx to bad input, that means basically catching all the python exceptions if not using a development version. The code for this is almost on place. Half an hour should be enough to fix this. linuxdoc - replace all the code for paragraphs generation by the one used by docbook, the code there is sufficiently general and is well tested to make this replacement. It is almost a mater of copy and paste, a better factorization can be done in 1.5. docbook - implement the suggestions of Chris, most of them are special cases for insets, so should not impact the core. PS: Before some says that this was discussed before, this days my memory qualifies as golden fish, so forgive and let us update the discussion. One good example that I like is kde: http://developer.kde.org/development-versions/kde-3.4-features.html The question is clearly to define what needs to be fixed, and attribute priorities to bugs, what is blocker and what can wait for 1.4.1. PS: I hope this is a constructive message towards a stable 1.4 release before this year Christmas. :-) -- José Abílio
Re: [PATCH][Bug 1720] LyX/Mac: Menus are not correctly disabled when a dialog has focus
On Mon, Nov 08, 2004 at 01:43:40PM +, Andreas Vox wrote: > > BTW, what do you think of switching to Java for LyX 1.5.0? Python would be a lot faster, and it has good interfaces for xform, qt, gtk and curses. (Are you listening Lars?) ;-) :-D > Ciao > /Andreas -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: Hints to test new branch.
On Mon, Nov 08, 2004 at 09:06:15PM +0100, Andre Poenitz wrote: > > I should be quite a bit faster when loading long documents as the > 'fullRebreak' is gone... That is visible when loading the User Guide. > Andre' -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: Hints to test new branch.
On Mon, Nov 08, 2004 at 03:38:22PM +0100, Alfredo Braunstein wrote: > > The most prominent I see are: > > - cursor movement that needs coordinates outside screen (like cursor up in > the first line, cursor down in the last one, pgup, pgdown, the cursor X > target) are non-functional. I'll work on this next (maybe I'll start > tonight) > > - scrollbar (needs an approximated heuristic, because we don't know the full > y size of the document) - see Andre's post Ok. :-) > - the position of the cursor in math sometimes isn't right. > > - for some reason selecting with the mouse only works if you start your > selection with double click. Go figure. Not here. It works as intended for qt. For xforms it is not even clear how it works, I have to click several times before to be able to do mouse selection. Again notice that selecting with the mouse in xforms triggers lots of redraws, in qt this effect is not visible. :-) > - ... > > > It would be nice to keep this list updated, so we can see how far from HEAD > we are... Agreed. :-) > > I have placed it side by side with HEAD and it is faster. I have finally > > compiled also qt in this branch, so the comparison is fair now. :-) > > Thanks for the help. > > IMO, it should even be much faster... we are probably wasting cycles > somewhere. Work for later. For the user guide it seems as if lyx2lyx is now the bottleneck. :-) But still acceptable on my laptop. :-) > Alfredo > -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: Hints to test new branch.
On Mon, Nov 08, 2004 at 03:08:31PM +0100, Alfredo Braunstein wrote: > > > That is it doesn't work at all. Only when I can move the scrool bar the > > cursor is moved, else it stays always in the same place. > > As it should ;-) Good. What needs to be done in this branch? I have placed it side by side with HEAD and it is faster. I have finally compiled also qt in this branch, so the comparison is fair now. :-) > Alfredo -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: Hints to test new branch.
On Mon, Nov 08, 2004 at 01:32:42PM +0100, Alfredo Braunstein wrote: > José Abílio Oliveira Matos wrote: > > > > I hope you see what I mean. :-) > > Yep... there's an error on how the scrollbar size and jump amount are > computed. But since what we have now is just a rough approximation... > there's no use in fine-tuning it. > I thought that you were saying that the scrollwheel didn't do anything at > all and I didn't see this. At least for xforms the mouse wheel movement is related with the scrollbar, so since the scroolbar is non-functional so it is the mouse wheel. That is it doesn't work at all. Only when I can move the scrool bar the cursor is moved, else it stays always in the same place. Note again that I am not describing what it should happen, I am reporting the current behaviour. > > As I have told you it feels a lot smoother now. :-) > > Cool. > Alfredo -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: Hints to test new branch.
On Sun, Nov 07, 2004 at 10:22:46PM +0100, Alfredo Braunstein wrote: > > > - the wheel mouse doesn't work for navigating the document; > > it seems to work here. There's still the problem that the finest scrolling > is 1 par... As I have told you in another message, I'm using xforms to test this branch. This bug seems related with the behaviour of the scroll bar. For small documents it shows as a single element. For the User Guide it occupies only 60% of the right border and when I use the wheel mouse it goes down as it should, but the navigation is wrong. This is it move the scroll bar as it should but then since the scroll bar is wrong... I hope you see what I mean. :-) > > - PgDn goes down one line; > > - PgUp is a noop; I know that you are working on this but now the behaviour of PgUp it is even funnier. ;-) It goes down to the end of the document and once there it as a cycle two period between the last line and the previous. You are a genius. ;-) > These two are next in my list > > > - any cursor movement seems to trigger a screen redraw? > > fixed As I have told you it feels a lot smoother now. :-) > Alfredo -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: booktabs
On Sun, Nov 07, 2004 at 07:56:10PM +0100, Georg Baum wrote: @@ -1526,7 +1693,8 @@ def convert(file): 235 : [convert_paperpackage], 236 : [convert_bullets, add_begin_header, add_begin_body, normalize_papersize, strip_end_space], - 237 : [use_x_boolean]} + 237 : [use_x_boolean], + 238 : ''} The proper syntax here is [], the null list. Yes I know that it works now but this is the rigth way to do it. :-) + 238 : []} -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: Hints to test new branch.
On Sat, Nov 06, 2004 at 11:06:50PM +0100, Alfredo Braunstein wrote: > José Abílio Oliveira Matos wrote: > > > Are you aware that: > > - you can only see the first page of the document; > > Pressing the down arrow of the scrollbar goes down here. The rest is a > consequence of the missing fitCursor (I'm working on that). > > > - the wheel mouse doesn't work for navigating the document; > > Humm it works here (sortof). > > > - PgDn goes down one line; > > Yes. > > > - PgUp is a noop; > > Aha. > > > - any cursor movement seems to trigger a screen redraw? > > Yes. > > > Other than that it seems ok. :-) > > I can sense the irony you know ;-) Honestly it wasn't, sorry ;-). What I meant to say is that it works in some aspects better than the HEAD. It looks better, but don't ask me to quantify this. :-) > Summary: I'm trying to solve these scrolling problems. Thanks. > Btw, lyx-qt seems to work a bit better than lyx-xforms OK. I have tested the xforms frontend, using gcc 3.4 for precompiled headers. It is a lot faster to compile and test. :-) > Alfredo > -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: Hints to test new branch.
On Sat, Nov 06, 2004 at 10:33:57PM +0100, Alfredo Braunstein wrote: > José Abílio Oliveira Matos wrote: > > > Hi Alfredo, > >any suggestions to test your branch? > > What to test you mean? All visual related things. The most severe problems I > see are in math (I hope Andre could have a look there...) but there are > others. > > Of course, the aim would be to bring CoordBranch to the status of the main > trunk... and merge back. So the most useful for the moment would be to find > the differences. Are you aware that: - you can only see the first page of the document; - the wheel mouse doesn't work for navigating the document; - PgDn goes down one line; - PgUp is a noop; - any cursor movement seems to trigger a screen redraw? Other than that it seems ok. :-) > >And don't worry no one will take you cvs for now. ;-) > > Well the fact that cvs branches are indeed a PITA, but for now it's ok (and > it's one more incentive to merge back soon ;-)) Agree. :-) > Thanks! > > Alfredo > -- José Abílio Matos LyX and docbook a perfect match. :-)
Hints to test new branche.
Hi Alfredo, any suggestions to test your branch? And don't worry no one will take you cvs for now. ;-) -- José Abílio
Re: booktabs
On Fri, Nov 05, 2004 at 05:46:34PM +, Andreas Vox wrote: > Edwin Leuven <[EMAIL PROTECTED]> writes: > > > La donna é mobile > > Qual piuma al vento, > > Muto d'accento - e di pensiero. > > The woman é mobile > Which piuma to the wind, piuma -> (more or less) feather > Dumb of accent - and thought. > > Could anyone provide a better translation than Google? Do you want to stop Alfrado's work just for that? ;-) > /Andreas -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: lyx-1.3.x/src/frontends/xforms/forms/Makefile.am
On Fri, Nov 05, 2004 at 01:13:34PM +, Angus Leeming wrote: > > Have fun y'all. I'll be thinking of you when I'm half way up some > mountain or other ;-) Half way up or half way down, symbolically for the project this is important. ;-) Enjoy your journey. :-) > -- > Angus -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: lyx-1.3.x/src/lyxlength.C
On Thu, Nov 04, 2004 at 11:27:04AM +, Angus Leeming wrote: > > Looks good enough to me. Why not get rid of snprintf.[Ch] at the same > time? I agree on both issues. > -- > Angus -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: Progress of math in docbook. (?)
On Sun, Oct 31, 2004 at 10:00:30PM +, Andreas Vox wrote: > > Unfortunately I got sidetracked this weekend and the last, so > there's no progress on my side. I just had some general thoughts > about factoring the bitmap generation for formulas out of the preview > generation and use it for both, previews and Docbook export. It makes sense. :-) > So on my TODO list is: > > * bitmap generation for equations, don't know when I get to it > * declaration of some MathML entities. I get two errors with > my de_Userguide about entities and ⅆ. > Those should be declared analogous to lyxarrow or we would need a > hint how to declare those (if they are standard in the MathML DTD, > configure should test for this DTD and disable MathML output if not > found) > * Need to contact the db2latex guys about their practice to put > \ensuremath{...} and \[ ... \] around every equation. I made a bad hack >which omits our \begin{eqnarray} or equivalent in LyX' XML output, >but I think db2latex should be changed instead. TeX will complain >anyhow when it finds the '&' char in standard equations. > * Testing > > If you want to pick any, just tell me before the next weekend :-) I still have some other issues with my list. :-) > My non-math-related TODO list would be: > > * Support for Glossaries, Bibliographies and Indices > * better frontmatter / mainmatter separation > * ToCs ? > * Macros without args (entities) > * Bug #1682 > * Messed up i18n on my PowerBook (don't know yet if it's a bug or if > I just messed up my configuration) > > < unnamed equations, give them a number. > < >< a long long int representation. I have applied instead the uniqueID function > < rescued from the graphics. > > That's fine. You could also delete my comment about at least 60 chars in > math_hullinset.C since it is outdated now. Done. > < > < > < propagate the correct sequence of escaped characters, probably the easiest > < will be putting it on the output parameters. > > That's your latest patch, right? Looks ok to me. Yes. > I'm just not sure if it should be present in the tclass ... but we can still > change that later if at all necessary. I don't think it is worth the trouble. First this is a SGML problem, not XML and then this is the easiest way to do it for a localization of options. > < Have a nice weekend, > Kind of over now :-) Then have a nice week. :-) > Ciao > /Andreas -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: Posting patches to the list
On Mon, Nov 01, 2004 at 12:18:05PM +0100, Lars Gullik Bjønnes wrote: > > > | How? > > It is easer to read one patch file, instead of wading through one file > at a time in viewcvs. Is it possible the issue a single cvs command to see the whole patch? Or that is the problem with atomic commits from cvs? > >> Note that you don't always have to wait for comments before committing. > > > | What is the general rule? > > If you are not sure it is the right thing, or if you want people to > have a look at it and comment before you commit. Common sense really. OK. > >> After a short grace period I will begin to enforce this. > > > | I don't want to be picky but I would like to have the rules defined from > | begining, or else it can be annoying if it appears the rules change in the > | middle of the game. :-) > > One simple rule: Post _all_ patches to the list. That is fair, and simple. :-) > -- > Lgb -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [patch] InsetCharstyle cosmetics
On Mon, Nov 01, 2004 at 10:27:38AM +0100, Juergen Spitzmueller wrote: > > The attached patch does just this (without the minibuffer message, for which I > haven't found an easy solution). > José, are your latest changes in ::docbook still necessary when paragraph > breaks are disabled? (sorry for this ping-pong game). The text inset still has paragraphs inside, doesn't it? Then the for cycle is not needed anymore as it is only a paragraph. But it should be working. :-) > Jürgen -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: Minor bugs in LaTeXConfig.lyx
On Sun, Oct 31, 2004 at 09:42:31PM +0100, [EMAIL PROTECTED] wrote: > Hi > > I picked up a bug report from "Feliks" on the documentation list, and > after asking him some follow up questions I promised to pass it on. > > The bugs are kind of trivial -- they are in the automatically generated > file: .lyx/doc/LaTeXConfig.lyx > > 1. The first section, third sentence after the enumerated list says: > ... > After the installation, please use the menu entry > Options->Reconfigure and reload this file to see if > ... This is 1.4 :-) > /Christian > > PS. Congratulations to our new PhD colleague :-) > > -- > Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr > -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: Posting patches to the list
On Sun, Oct 31, 2004 at 03:05:05PM +0100, Lars Gullik Bjønnes wrote: > > Can we please begin (continue) to post _all_ patches to the list. > (If you feel we need a separate list for this that can be done.) I have been the one at fault here. :-) > This makes it a lot easier to follow what is up for review or what is > applied to CVS. How? > Note that you don't always have to wait for comments before committing. What is the general rule? > After a short grace period I will begin to enforce this. I don't want to be picky but I would like to have the rules defined from begining, or else it can be annoying if it appears the rules change in the middle of the game. :-) > -- > Lgb -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [patch] InsetCharstyle cosmetics
On Sun, Oct 31, 2004 at 02:33:59PM +0100, Juergen Spitzmueller wrote: ... > Jürgen > > BTW, as to your latest change: I think we should not allow paragraph breaks in > the char style inset at all (leads to LaTeX error also and is not what inline > insets are designed for IMO). I agree. It doesn't make sense for an inline element to have paragraphs inside, because then it would not be an inline element. :-) > Alternatively, we could close the macro/tag and > reopen in a new paragraph. But that would be much more tricky i guess. Is it necessary? I don't think so. :-) -- José Abílio Matos LyX and docbook a perfect match. :-)
Progress of math in docbook. (?)
Hi Andreas, let us syncronize again our todo lists. :-) I have applied you work on ids. I have applied also your patch for unnamed equations, give them a number. One of the problem of your implementation in linux is that tellp uses a long long int representation. I have applied instead the uniqueID function rescued from the graphics. What is missing? Regarding the escape of ids, I am still trying to find a simple way to propagate the correct sequence of escaped characters, probably the easiest will be putting it on the output parameters. Have a nice weekend, -- José Abílio
Re: [patch] InsetCharstyle cosmetics
On Sun, Oct 31, 2004 at 11:28:04AM +0100, Juergen Spitzmueller wrote: > > P.S.: Do you have any idea why the label does not get drawn? Also, getDrawFont > doesn't seem to work (provided that Noun should be drwan as small caps). But if you nest two of the them the inside style gets its label visible. :-) -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [patch] fix insetCharStyle::priv_dispatch
On Sat, Oct 30, 2004 at 04:50:23PM +0200, Juergen Spitzmueller wrote: > As mentioned in the previous thread, entering a charstyle inset with the mouse > leads to an infinite loop. The attached oneliner fixes this (typo). I will > just commit this since it seems uncontroversial. > > Jürgen Do it. Thanks for the other patch. :-) -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [Bug 1731] New: insetcharstyle doesn't escape active latex characters
On Sat, Oct 30, 2004 at 12:00:53PM +0200, Juergen Spitzmueller wrote: > > Well, if you put it like this ;-) :-) It was not a threat, but a treat. ;-) > But please review the attached patch (especially I'm not sure if > sgml::escapeString is still needed with InsetText::docbook/linuxdoc). It was there for the same reason that your started this thread. :-) Now we don't need it. Thanks. :-) > Thanks, > Jürgen -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [Bug 1731] New: insetcharstyle doesn't escape active latex characters
On Sat, Oct 30, 2004 at 11:30:29AM +0200, Juergen Spitzmueller wrote: > > > > If it works for LaTeX, it will work there too. > > I will not touch this. Maybe Jose can have a look at it. If you change the call to latex then do the same for linuxdoc and docbook. Or else I will do it. :-) What we are discussing here is orthogonal to the distinction between the different backends. :-) > Jürgen -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: A literate programming build bug
On Fri, Oct 29, 2004 at 11:16:36PM +0200, Alfredo Braunstein wrote: > Kayvan A. Sylvan wrote: > > > btw, you have mail. > > PS: please forgive me, I'm just drunk. What? No time for it, start fixing some bugs now! ;-) Oh, wait, better do it tomorrow. :-p > Alfredo -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH] Write one paragraph parameter per line.
Now with the patch: :-) -- José Abílio Matos LyX and docbook a perfect match. :-) Index: ParagraphParameters.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ParagraphParameters.C,v retrieving revision 1.44 diff -u -p -r1.44 ParagraphParameters.C --- ParagraphParameters.C 5 Oct 2004 12:56:20 - 1.44 +++ ParagraphParameters.C 29 Oct 2004 15:10:04 - @@ -246,28 +246,25 @@ void ParagraphParameters::read(LyXLex & void ParagraphParameters::write(ostream & os) const { - ostringstream oss; - // Maybe the paragraph has special spacing - spacing().writeFile(oss, true); + spacing().writeFile(os, true); // The labelwidth string used in lists. if (!labelWidthString().empty()) - oss << "\\labelwidthstring " + os << "\\labelwidthstring " << labelWidthString() << '\n'; // Start of appendix? if (startOfAppendix()) - oss << "\\start_of_appendix "; + os << "\\start_of_appendix\n"; // Noindent? if (noindent()) - oss << "\\noindent "; + os << "\\noindent\n"; // Do we have a manual left indent? if (!leftIndent().zero()) - oss << "\\leftindent " << leftIndent().asString() - << ' '; + os << "\\leftindent " << leftIndent().asString() << '\n'; // Alignment? if (align() != LYX_ALIGN_LAYOUT) { @@ -278,9 +275,9 @@ void ParagraphParameters::write(ostream case LYX_ALIGN_CENTER: h = 3; break; default: h = 0; break; } - oss << "\\align " << string_align[h] << ' '; + os << "\\align " << string_align[h] << '\n'; } - os << rtrim(oss.str()); + os << '\n'; } @@ -301,7 +298,7 @@ void params2string(Paragraph const & par params.write(os); // Is alignment possible - os << '\n' << "\\alignpossible " << layout->alignpossible << '\n'; + os << "\\alignpossible " << layout->alignpossible << '\n'; /// set default alignment os << "\\aligndefault " << layout->align << '\n';
[PATCH] Write one paragraph parameter per line.
Hi, The following patch writes one paragraph parameter per line. This follow the rational of all other changes in the lyx file format over 1.4, to limit to one any token beginning with a slash. Also, some parameters have their own line while other don't, this makes them all equal. :-) -- José Abílio
Re: lyx-devel src/: ChangeLog output_docbook.C sgml.C src/inse ...
On Fri, Oct 29, 2004 at 12:51:04PM +0300, Martin Vermeer wrote: > Beautiful piece of work, José. Looks so much cleaner now. Thanks, :-) -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: lyx-devel src/: ChangeLog output_docbook.C sgml.C src/inse ...
On Fri, Oct 29, 2004 at 11:00:03AM +0100, Angus Leeming wrote: > > Actually, José, I think that you can simplify insetcharstyle.C even > further: > > int InsetCharStyle::linuxdoc(Buffer const & buffer, std::ostream & os, > OutputParams const & params) const > { > return docbook(buffer, os, params); > } > > I can't see any difference between the two functions, so why not remove the > redundant code? I am applying my patches in small chunks and this was left for another round. :-) There are several places in the code where we are could merge the linuxdoc and docbook code. I will look into it next. Thanks, > -- > Angus -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: lyx-devel src/: ChangeLog buffer.C output_docbook.C output ...
On Thu, Oct 28, 2004 at 04:29:20PM +0300, Martin Vermeer wrote: > Hmmm... did you look at the way " is used in the other layout > files? And have a look at lyxlayout.C and lyxtextclass.C. Should we > think about unifying this with your use of <> ? Can we (i.e., is <> > sufficiently general for this purpose)? This is just for 1.4, for 1.5/2.0 ;-) the right thing to do is fix the parser to allow double quotes inside arguments. For now I think that it is a lot more easier to read "id=" or "type=" Also _<_ and _>_ cann't ever appear in attributes, so we are on the safe side here. I am centralizing everything inside a single function told you this will disapper in next version. After all those are just 2 lines. :-) > - Martin > -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: Route to 1.4.0
On Thu, Oct 28, 2004 at 12:31:57PM +0200, Alfredo Braunstein wrote: > > Alfredo, phd for almost a day ;-) Congratulations. :-) -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: Bug 1687: request for help. :-)
On Tue, Oct 26, 2004 at 11:03:07AM +0200, Jean-Marc Lasgouttes wrote: > > - Does disabling optimization help? --- Additional Comments From [EMAIL PROTECTED] 2004-10-28 11:57 --- Turning off optimisation fixes the problem. Good thinking. > JMarc Thanks, Jean-Marc. -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: lyx-devel src/: ChangeLog output_docbook.C
On Thu, Oct 28, 2004 at 09:42:29AM +0300, Martin Vermeer wrote: > > I don't remember, and I don't seem to have the AGU-Article dtd anymore. I think that I still have a copy that you sent me. :-) > Note that also the sectioning counter names differ from their LaTeX > names. Are you sure you understand this code? :-) Your code is really easy to read. And the work that you have done with the layout files is amazing. Congratulations. And I really mean it you have clean my code to such a point that I could even understand it, and that allowed the latest rewrite. :-) Your changes simplied so much the logic that I will merge both the docbook and linuxdoc support at the paragraph list level, because they are the same. Everything is controled from ours xsl, pardon textclasses ;-), files. This is quite interesting. > > Note that the result is still _id="para50"_ as it should. > > OK. I will apply the patch later. :-) > -- > Martin Vermeer [EMAIL PROTECTED] > Helsinki University of Technology > Dept. of Surveying, Inst. of Geodesy > P.O. Box 1200, FIN-02015 HUT, Finland -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: Bug 1687: request for help.
On Wed, Oct 27, 2004 at 10:16:18PM +0100, Angus Leeming wrote: > José Abílio Oliveira Matos wrote: > > > On Wed, Oct 27, 2004 at 05:36:08PM +0100, Angus Leeming wrote: > >> > >> José, Just for info: I use 1.3.x all the time on a 64bit Alpha > >> machine and have never had the problem described in this bug report. > > > > Just to be sure, could you export an empty document to docbook and see > > if it crashes lyx? > > Not easily. What would I need to install? Put somewhere in your path some dummy script with execution permissions called sgmltools or db2dvi. When I want to test lyx in some machine but not install the docbook tools this is exactly what I do. That you will not be able to see the resulting dvi or pdf. But that is not the problem here. > However, I note that the guy said that exporting to DVI, PDF also crashed > lyx. That doesn't happen here. But from docbook, not from latex. That happens because the first export fails, I think. > Incidentally, trying to export an empty document as a DVI file results in a > warning dialog: > > Alert > The operation resulted in > an empty file > Dismiss > > What happens if you do this with docbook? It looks like the same, this is strange. Both for 1.3 and 1.4, so this means that no file is exported... File error. The specified file '/tmp/lyx_tmpdir5505ZkAmOy/lyx_tmpbuf0/newfile1.dvi' does not exist. KDVI already tried to add the ending '.dvi'. > -- > Angus -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: lyx-devel src/: ChangeLog output_docbook.C
On Tue, Oct 26, 2004 at 10:49:29AM +0300, Martin Vermeer wrote: > > > Using pseudo code the it would be: > > > > Is there any label in paragraph? > > (Yes) then use it > > (No) else include the automatically generated. > > ...with # substitution if appropriate. > > That's precisely correct. I have done it. If there is a label the code is the suggestion for the automatic label is disregarded, if not placed there. Is there any special reason why you declared a counter called para instead of p, the name of the paragraph? I have tried and the code works as it should. If you don't mind I will change it to p. It makes also the code easier. :-) Note that the result is still _id="para50"_ as it should. > -- > Martin Vermeer <[EMAIL PROTECTED]> -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: Bug 1687: request for help.
On Wed, Oct 27, 2004 at 05:36:08PM +0100, Angus Leeming wrote: > > José, Just for info: I use 1.3.x all the time on a 64bit Alpha > machine and have never had the problem described in this bug report. Just to be sure, could you export an empty document to docbook and see if it crashes lyx? > -- > Angus -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: Bug 1687: request for help.
On Wed, Oct 27, 2004 at 05:36:08PM +0100, Angus Leeming wrote: > > José, Just for info: I use 1.3.x all the time on a 64bit Alpha > machine and have never had the problem described in this bug report. Thanks Angus, that information is useful. I will contact the guy who has this problems suggesting the steps pointed by Jean-Marc. > -- > Angus -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH] Movers
On Tue, Oct 26, 2004 at 07:41:27PM +0100, Angus Leeming wrote: > Angus Leeming wrote: > > Here is the patch to enable XFig files to be moved around freely, > > together with stuff to enable these external 'copiers' to be defined > > in the preferences dialog. > > Ok, it's now in cvs. Now that we have the Movers it would be useful to have the Doers. Could you take care of it? ;-) > -- > Angus -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: lyx-devel src/: ChangeLog output_docbook.C
On Tue, Oct 26, 2004 at 08:36:17AM +0300, Martin Vermeer wrote: > > As I understand it, the manual label overrides any automatic one. So in > this case the previous paragraph would have label para150 and the next > para152 (and these change dynamically as you add and remove paragraphs) > but the label of this paragraph is and remains aha_gotcha. (For AGU, > dunno about others) At least for now we are talking about AGU. I didn't know, but then the code was wrong as it always overwrote the manual one, and I assumed that it was an imposition of the dtd... Using pseudo code the it would be: Is there any label in paragraph? (Yes) then use it (No) else include the automatically generated. > -- > Martin Vermeer <[EMAIL PROTECTED]> Best regards, -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: Bug 1687: request for help.
On Mon, Oct 25, 2004 at 09:39:52PM +, Andreas Vox wrote: > > You could ask someone with a 64bit box for help! ;-P That would be nice. :-) > Sorry, I have my nasty day again, José. At our institute we ordered > a couple of Athlon64s which should arrive in a few weeks if not > next year (well, you know about university administration, no?) Someday I will be part of it. :-( > If the bug is still open at that time I'll give it a try. Thanks. :-) > Ciao > /Andreas -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: lyx-devel src/: ChangeLog output_docbook.C
On Mon, Oct 25, 2004 at 05:15:39PM +0300, Martin Vermeer wrote: > > I still feel you're making this too complicated :-) Mais au contraire, mon cher ami. ;-) [This started as an simple answer and ended as a rant. You have been warned... ;-)] ids are attributes that are allowed in every element. What I would to have is a clever and clear way to deal with them. Take the ids for AGU as an example, that we have already discussed. One of the proposal IIRC, was to allow all labels (ids) to appear in the graphical interface, even the automatic. What I propose now is never to include the automatic labels, but to translate from manual to automatic. This is something that lyx can do quite well. Lets assume that your label called 'aha_gotcha' is located on paragraph 151, according to AGU you should always use 'para151' to refer to that lable, except if you add another paragraph before where it should be 'para152'. The problem for us humans is that those references are not stable, it is easy to refer to them as 'aha_gotcha'. LyX always know where the label appears, so it is easy for it to do that convertion automatically for the user. Now I would like to have a mini-language to put all this knowleadge in the textclasses, the same we do with those $$i, $$o, $$b in the converter stuff. I don't want something that only works for AGU, I want something that works for any XML based format. Have I been clear regarding my motivation? :-) > -- > Martin Vermeer <[EMAIL PROTECTED]> The question is that we do have several mini-languages around: - the lyx file format; - the textclasses format; - the lyxrc format; - the converters format. The problem is that syntax is nuts for almost all of them. Take the textclass as an example, you cann't do this: LatexParam"lang=\"pt\"" Why? because to do this it would be need to change all the uses of lexrc.next() to lexrx.next(true), this means that \ and " are special characters and should be escaped if used. Problem, if we do that the previous example will work, I tested it, but since latex uses lots of slashes all the configuration files would need to use double slashes, exactly as we do it in C++. Is this acceptable? No, IMO. :-) If we are using a "shell-ish" notation why not go all the way, and add ' to the bunch of special characteres? These are questions that I would like to answer in the next development cycle. My awareness for this issues raised certainly because of lyx2lyx. We talked in the past over using a script language in the configuration files, but I don't even use properly what we have now. :-( -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: Bug 1687: request for help. :-)
On Mon, Oct 25, 2004 at 03:05:38PM +0100, John Levon wrote: > > It shouldn't ;) Any idea how to debug this? > john -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: lyx-devel src/: ChangeLog output_docbook.C
On Mon, Oct 25, 2004 at 05:15:39PM +0300, Martin Vermeer wrote: > > > > Then probably the first line inside the if should be instead: > > > > id += " " + bstyle->latexparam(); > > No no... rather, keep it as it is, but shift it to inside the second > if-statement, i.e., one line down. OK, looking to layout I see it: "id = "s#"" I thought that we weren't dealing with ids. > I still feel you're making this too complicated :-) I'm sorry Martin but complicated is how the AGU dtd looks. ;-) That idea of forcing automatic ids for every elements of a given type is crazy, I've never seen nothing like it. :-) Now that see your point I don't know what to think, because you could have a parameter that not an id... Something like: if parameter contains '#': replace # by the appropriate counter and put that into id else: add the parameter to the content of id > -- > Martin Vermeer <[EMAIL PROTECTED]> The weather here is chilly, 8C that with wind chill goes to 4C. I have visited Dublin in the afternoon, and it was a bit unplesant. :-) Not that I'm complaining. ;-) -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: lyx-devel src/: ChangeLog output_docbook.C
On Mon, Oct 25, 2004 at 04:13:23PM +0300, Martin Vermeer wrote: > > At least this looks correct now... but can't you (referring to before > this proposed patch) just place the counters thingy *inside* the second > if-statement? Again, what do I miss? > > Like this > > if (!bstyle->latexparam().empty()) { > id = bstyle->latexparam(); > if (id.find('#') != string::npos) { > counters.step(bstyle->counter); > string el = expandLabel(buf.params().getLyXTextClass(), > bstyle, false); > id = subst(id, "#", el); > } > } With this code you are overriding the id even if you don't have any # in your style parameter. Then probably the first line inside the if should be instead: id += " " + bstyle->latexparam(); > -- > Martin Vermeer <[EMAIL PROTECTED]> -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: lyx-devel src/: ChangeLog output_docbook.C
On Mon, Oct 25, 2004 at 03:25:50PM +0300, Martin Vermeer wrote: > > Wrong fix I think. > > What if style->latexparam() is non-empty, but does not contain a '#'? > > :-) I think that we need to agree on a common syntax for string substitution and place that on openTag. :-) Second try, something like this? Index: output_docbook.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/output_docbook.C,v retrieving revision 1.17 diff -u -p -r1.17 output_docbook.C --- output_docbook.C25 Oct 2004 11:20:02 - 1.17 +++ output_docbook.C25 Oct 2004 12:32:53 - @@ -234,14 +234,12 @@ ParagraphList::const_iterator makeComman string id = par->getDocbookId(); id = id.empty()? "" : " id = \"" + id + "\""; - if (!bstyle->latexparam().empty()) { + if (!bstyle->latexparam().empty() && bstyle->latexparam().find('#') != string::npos) { counters.step(bstyle->counter); id = bstyle->latexparam(); - if (id.find('#') != string::npos) { - string el = expandLabel(buf.params().getLyXTextClass(), - bstyle, false); - id = subst(id, "#", el); - } + string el = expandLabel(buf.params().getLyXTextClass(), + bstyle, false); + id = subst(id, "#", el); } //Open outter tag > -- > Martin Vermeer <[EMAIL PROTECTED]> -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: Bug 1687: request for help. :-)
On Mon, Oct 25, 2004 at 01:20:26PM +0100, John Levon wrote: > On Mon, Oct 25, 2004 at 12:06:33PM +0100, Jos? Ab?lio Oliveira Matos wrote: > > >http://bugzilla.lyx.org/attachment.cgi?id=597&action=view > > > >What I find strange is the frame #5: > > > > #5 0x00456f50 in Buffer::makeDocBookFile (this=0xb38fc0, [EMAIL > > PROTECTED], > > nice=true, only_body=false) at buffer.C:2945 > > Is the Buffer (this) valid? #6 0x00478fd6 in Exporter::Export (buffer=0xb38fc0, [EMAIL PROTECTED], put_in_tempdir=false, [EMAIL PROTECTED]) at exporter.C:84 #7 0x00479677 in Exporter::Export (buffer=0x7fbfe3c3c8, [EMAIL PROTECTED], put_in_tempdir=false) at exporter.C:116 You are right. The buffer changed between these two calls, even weird. It shouldn't, right? > john -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: lyx-devel src/: ChangeLog buffer.C output_docbook.C output ...
On Mon, Oct 25, 2004 at 01:47:09PM +0300, Martin Vermeer wrote: > > > > Nothing, I think. I have reordered the code and, probably, before this > > code chuncks were in different places. > > As you clearly show this should be merged. Do you want me to do it? > > Yes, please. Done, thanks. :-) I hope you like the new code. :-) > -- > Martin Vermeer <[EMAIL PROTECTED]> -- José Abílio Matos LyX and docbook a perfect match. :-)
Bug 1687: request for help. :-)
Hi, I am lost. :-) The bug is: http://bugzilla.lyx.org/show_bug.cgi?id=1687 In short, a user running a 64 bit plataform and lyx-1.3.4 has problems exporting any docbook document in any format. LyX always crashes, and the bug report is here: http://bugzilla.lyx.org/attachment.cgi?id=597&action=view What I find strange is the frame #5: #5 0x00456f50 in Buffer::makeDocBookFile (this=0xb38fc0, [EMAIL PROTECTED], nice=true, only_body=false) at buffer.C:2945 fname is supposed to be a reference to a constant string, yet it is null. The first code in makeDocBookFile that checks to see if the ostream was succefuly created does not fail. Then some of the values above are completly bogus, the depth for example. Clearly this does not happen on i368, or else I would have noticed, and I don't have also any x86_64 to test. -- José Abílio
Re: ftp.lyx.org/pub/lyx proposal
On Mon, Oct 25, 2004 at 11:32:36AM +0100, Angus Leeming wrote: > > The statement below is grammatically correct and a little less > mind-twisty... > > If you have questions about the organization of this directory, > or would like to suggest additions to it, please contact the > LyX developers' mailing list ([EMAIL PROTECTED]). Thanks Angus. I agree with you. :-) > -- > Angus -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: ftp.lyx.org/pub/lyx proposal
On Mon, Oct 25, 2004 at 12:22:47PM +0200, Jean-Marc Lasgouttes wrote: > >>>>> "José" == José Abílio Oliveira Matos <[EMAIL PROTECTED]> writes: > > José> Hello, here is what I propose for ftp.lyx.org/pub/lyx > > José> devel > > José> remove it completly, all the files there are outdated and > José> serve no meaningful purpose. ;-) > > Since everything is in cvs, I guess only the old patches to the 0.7 > series have some historical interest (and this interest is very very > weak, since there are no associated changelogs). I have then here and intend to make them available through the archaelogy site. > José> Another alternative is to leave just the README found in 0.13 > José> directory inside. > > I do not think it is worth doing it. But we probably need a toplevel readme. OK. > José> contrib - add a README - create special categories: > José> latex-classes CU-Thesis.tar.gz egs+springer-layouts.tgz > José> iletter.tar.gz seminar.tar.gz tools Aiksaurus-* csv2lyx.tar.gz > José> fd2lyx.tar.gz lyxMM-0.3.tar.gz xforms libforms* xforms* qt > José> qt-mac-free-3.1.2-sit - remove: COLD arrowbt dos-unix dvi2tty* > José> ghostscript* ispell-* > > I think we can drop qt-mac-free, since we instruct to download from > trolltech site now. I was unsure about this one, but I knew that you would have a more informed opinion. ;-) > José> Bellow is a possible draft for the README: > > José> For questions regarding the organization, or suggestions > José> regarding additions, for this directory please contact the LyX > José> developpers mailing list. > > With an e-mail address, I guess... Yes, I forgot it. :-) > JMarc -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: lyx-devel src/: ChangeLog buffer.C output_docbook.C output ...
On Mon, Oct 25, 2004 at 01:05:22PM +0300, Martin Vermeer wrote: > ma, 2004-10-25 kello 03:35, José Abílio Oliveira Matos kirjoitti: > > > Martin the code now should be a lot easier to read, I tried to maintain > > all the previous features for AGU. I think also that we should set some kind > > of syntax for parameters substituion. > > Eh, in output_docbook.C: > > 237 if (bstyle->latexparam().find('#') != string::npos) { > 238 counters.step(bstyle->counter); > 239 } > 240 > 241 if (!bstyle->latexparam().empty()) { > 242 id = bstyle->latexparam(); > 243 if (id.find('#') != string::npos) { > 244 string el = > expandLabel(buf.params().getLyXTextClass(), > 245 bstyle, false); > 246 id = subst(id, "#", el); > 247 } > 248 } > > Why is line 238 not inside the following piece of code? What do I miss? Nothing, I think. I have reordered the code and, probably, before this code chuncks were in different places. As you clearly show this should be merged. Do you want me to do it? > -- > Martin Vermeer <[EMAIL PROTECTED]> -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: LyX CVS compile problem
On Sun, Oct 24, 2004 at 09:18:58PM -0700, Kayvan A. Sylvan wrote: > On Linux, xforms frontend: > > if g++ -DHAVE_CONFIG_H -I. -I. -I. -I../boost -I/usr/X11R6/include -O2 -fno-ex > ceptions -W -Wall -MT sgml.o -MD -MP -MF ".deps/sgml.Tpo" \ > -c -o sgml.o `test -f 'sgml.C' || echo './'`sgml.C; \ > then mv -f ".deps/sgml.Tpo" ".deps/sgml.Po"; \ > else rm -f ".deps/sgml.Tpo"; exit 1; \ > fi > In file included from sgml.C:14: > sgml.h:35: invalid use of undefined type `struct std::string' > /usr/include/c++/3.2/bits/stringfwd.h:61: declaration of `struct std::string' > make[4]: *** [sgml.o] Error 1 I think that we should include then #include for that file. Thanks for the report. > ---Kayvan -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: lyx-devel src/: ChangeLog buffer.C output_docbook.C output ...
On Sun, Oct 24, 2004 at 01:14:56AM +0100, José Abílio Oliveira Matos wrote: > > I hope that Martin and Andreas find the code easier to understand now. I have fixed the last know bugs for this code, and commited the fixes. Andreas, I applied the fix to inset index, for that I created a new function in sgml.C called escapeString, I think that to play safe we need to apply this function in almost all the places where we don't control the input. Martin the code now should be a lot easier to read, I tried to maintain all the previous features for AGU. I think also that we should set some kind of syntax for parameters substituion. I have centralized all the code for substituions there, the only expection is the level of sections. If we agree on a reasonable notation then we can transfer all the code there and have a single mechanism for parameters building. -- José Abílio Matos LyX and docbook a perfect match. :-)
ftp.lyx.org/pub/lyx proposal
Hello, here is what I propose for ftp.lyx.org/pub/lyx bin clean (nothing to suggest) stable clean (nothing to suggest). devel remove it completly, all the files there are outdated and serve no meaningful purpose. ;-) Another alternative is to leave just the README found in 0.13 directory inside. contrib - add a README - create special categories: latex-classes CU-Thesis.tar.gz egs+springer-layouts.tgz iletter.tar.gz seminar.tar.gz tools Aiksaurus-* csv2lyx.tar.gz fd2lyx.tar.gz lyxMM-0.3.tar.gz xforms libforms* xforms* qt qt-mac-free-3.1.2-sit - remove: COLD arrowbt dos-unix dvi2tty* ghostscript* ispell-* Bellow is a possible draft for the README: _ Contributed LyX directory This directory contains packages that are useful in conjunction with LyX. These packages were contributed by the LyX users. Note that these packages are provided as is, without any warranty with respect to packaging, security or functionality. For questions regarding the organization, or suggestions regarding additions, for this directory please contact the LyX developpers mailing list. For questions regarding the packages available in this directory please contact that packages authors directly. The packages are divide according to their use: - latex-classes packages that contain LaTeX classes and/or the associated LyX textclasses. - tools external tools to interact with LyX - xforms xforms toolkit packages - qt qt toolkit packages _ Comments? -- José Abílio
Re: docbook.C compile problem
On Sun, Oct 24, 2004 at 12:41:57AM -0700, Kayvan A. Sylvan wrote: > Latest CVS lyx does not compile: > > if g++ -DHAVE_CONFIG_H -I. -I../../lyx/src -I. -I../../lyx/boost > -I/usr/local/include-I/usr/X11R6/include -O2 -fno-exceptions -W -Wall > -mms-bitfields -MT output_docbook.o -MD -MP -MF ".deps/output_docbook.Tpo" -c -o > output_docbook.o ../../lyx/src/output_docbook.C; \ > then mv -f ".deps/output_docbook.Tpo" ".deps/output_docbook.Po"; else rm -f > ".deps/output_docbook.Tpo"; exit 1; fi > ../../lyx/src/output_docbook.C:39: error: `stack' not declared > make[3]: *** [output_docbook.o] Error 1 > make[3]: Leaving directory `/home/ksylvan/src/lyx-build/src' Fixed in cvs. -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: docbook.C compile problem
On Sun, Oct 24, 2004 at 12:41:57AM -0700, Kayvan A. Sylvan wrote: > Latest CVS lyx does not compile: > > if g++ -DHAVE_CONFIG_H -I. -I../../lyx/src -I. -I../../lyx/boost > -I/usr/local/include-I/usr/X11R6/include -O2 -fno-exceptions -W -Wall > -mms-bitfields -MT output_docbook.o -MD -MP -MF ".deps/output_docbook.Tpo" -c -o > output_docbook.o ../../lyx/src/output_docbook.C; \ > then mv -f ".deps/output_docbook.Tpo" ".deps/output_docbook.Po"; else rm -f > ".deps/output_docbook.Tpo"; exit 1; fi > ../../lyx/src/output_docbook.C:39: error: `stack' not declared > make[3]: *** [output_docbook.o] Error 1 > make[3]: Leaving directory `/home/ksylvan/src/lyx-build/src' I'm sorry Kayvan, I removed stack usage from that file and forgot to remove that using. Funny that gcc 3.4 didn't compain. :-) I will removed asap. Thanks for the report. :-) -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: lyx-devel src/: ChangeLog buffer.C output_docbook.C output ...
On Sun, Oct 24, 2004 at 02:02:40AM +, [EMAIL PROTECTED] wrote: > > Modified files: > lyx-devel/src/: ChangeLog buffer.C output_docbook.C > output_docbook.h paragraph.C sgml.C > lyx-devel/src/insets/: ChangeLog insettext.C > > Log message: > Reorganized docbook export code and fixed several bugs in the process. Hi, this is the long waited code rewrite for docbook export. The code is a lot easier now and that allowed me to fix some old bugs. I'm sure that are still some rough corners to polish, but this code shows better behaviours than the previous. Compare, for example, the export document containing code before and after: Before After I hope that Martin and Andreas find the code easier to understand now. -- José Abílio
Re: [patch] fix bug 1677
On Sat, Oct 23, 2004 at 01:37:50PM +0200, Juergen Spitzmueller wrote: > Lars Gullik Bjønnes wrote: > > I wonder if we shouldn't make this a real InsetThanks then. > > I don't want to separate it on the ui-side (users should not bother whether to > use \thanks or \footnote, since it is basically the same concept). Moreover, > this separation would be very LaTeX-centric, and I cannot imagine that this > would please you ;-) I am forced to agree with Jürgen here. Note that sometimes the thanks are not used to thank anyone but simply to carry the address, or other special note. As it would be done if you could use footnotes on author. The problem is that thanks is too specialized, with no other counterpart. > Regards, > Jürgen -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH]
On Fri, Oct 22, 2004 at 05:13:59PM +0200, Lars Gullik Bjønnes wrote: > > Then why not a even clearer mark "!-- inntermakr standard --"? Because it is usually easy to see from the context which element it refers. Also I'm lazy and change the code to filter all empty comments for stable releases so no need to change the layout files. I just do this because, as I refered before, usually it is enough to see what is going on. > -- > Lgb -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH]
On Fri, Oct 22, 2004 at 04:54:15PM +0200, Lars Gullik Bjønnes wrote: > > > | You forgot the quotes around the !-- -- > | Quite easy to find actually. :-) > > This look like a hack, is it? > > -- > Lgb InnerTag "" would give the same result, if that is what you ask. During development I use this kind of markers to see that the output is what it should be. -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH]
On Thu, Oct 21, 2004 at 10:30:05AM +0200, Andreas Vox wrote: > Hi! > > Another small and independent patch which corrects the behaviour > of starsection in DocBook. The other patch nested an inner > element into the , which is against DocBook DTD. > > /Andreas > > Index: lib/layouts/db_stdstarsections.inc > === > RCS file: /cvs/lyx/lyx-devel/lib/layouts/db_stdstarsections.inc,v > retrieving revision 1.5 > diff -u -p -r1.5 db_stdstarsections.inc > --- lib/layouts/db_stdstarsections.inc2004/10/15 16:22:43 1.5 > +++ lib/layouts/db_stdstarsections.inc2004/10/21 07:34:43 > @@ -14,7 +14,7 @@ Style Part* > MarginStatic > LatexName bridgehead > LatexType Environment > - InnerTag title > + InnerTag !-- -- > LabelType No_Label > LatexParamrenderas="part" > End You forgot the quotes around the !-- -- Quite easy to find actually. :-) -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH] Changelogs for the other Docbook patches
On Fri, Oct 22, 2004 at 01:49:37PM +, Andreas Vox wrote: > > Sorry, that's what happens if I use anything but vi to edit changelogs. > > Forgiven? Certainly. :-) The whole exercise was just to show you that small patches are a lot easier to deal for all of us. :-) And also that we read your patches. ;-) > /Andreas -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: Moving files from one dir to another
On Fri, Oct 22, 2004 at 01:25:08PM +0100, Angus Leeming wrote: > > Does DocBook not use MathML? The XML version, yes, the SGML no. Then the problem is that even if you use it, for some tools and chains is a lot easier to go the tex way, as it is more mature and gives better results. Free tools to produce goof pdf, are starting to appear, but sometimes you need the work done now, not tomorrow. ;-) > Incidentally, why don't we use jadetex and pdfjadetex to genernate docbook? For some tool chains, mainly related with the SGML version (note that the xml version can use the sgml tools, but not vice-versa) the wrappers that we use transform docbook to jadetex and then use pdfjadetex to generate pdf. We could clearly do the work of most of this wrappers and call the tools directly, as our converters do the same. This is an interesting idea (in a sense the same as we do to latex), that has been persued, by integrating some of Chris Karakas scripts into lyx-docbook. > -- > Angus -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH] Docbook graphic -> mediaobject
On Fri, Oct 22, 2004 at 12:27:19PM +, Andreas Vox wrote: > José Abílio Oliveira Matos <[EMAIL PROTECTED]> writes: > > Fix what? In my opinion this is the fix: an older patch introduced those > spurious '<' in toDocbookLength() and I used the opportunity to > delete them in the last patch. So they were placed there by mistake, is it? If yes, then alright. > Ciao > /Andreas -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: Patch - DTD - And lyx file
On Thu, Oct 21, 2004 at 10:21:49PM -0400, John Weiss wrote: > > I say define anything that depends on environment ... like the > textclasses ... as simple string attributes. We can make exceptions > for *certain* textclasses ... like "Standard" ... that are pretty much > universal. Just my $0.02 worth. John, note that Standard is not a textclass, but a paragraph/layout of almost every textclass. Also we have support in the textclass for defining a default paragraph, that not the Standard. In other words I don't think we should allow exceptions in this area. An external tool to verify the validity of those it makes sense. :-) > -- > John Weiss -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: Preview is broken due to quotes!
On Fri, Oct 22, 2004 at 12:35:33PM +0200, Jean-Marc Lasgouttes wrote: > > I am all for it. I support that. :-) > JMarc -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH] DocBook cleanID and math
On Thu, Oct 21, 2004 at 10:21:56AM +0200, Andreas Vox wrote: > Hi! > > I submit my patch from last weekend again with bug fixes and split into > parts. I know that this is the second time I ask you to do this, but could you redo your patch against current cvs? This is what I get when trying to apply the patch: $ patch -u -p0 --dry-run < /home/jamatos/patch-db-ids+math.txt patching file src/paragraph.C patching file src/sgml.C patch: malformed patch at line 46: namespace sgml { > This one is the biggest, it contains the changes to math_hullinset and > the new > 'cleanID' function. > > Content: > > * calling 'sgml::cleanID' when outputting SGML or XML ids or linkends. > * changing the namemangling in 'cleanID' to be unique and according to > SGML decl. This is I don't understand. XML has a less restrictive model, yet the patch seems to apply the same function no matter what. Or am I understanding it wrong? > * mathed: escaping '&' and '<' in output > * element for equations > > Oh yes, and I made a :%s/ // in vi, so there shouldn't be any > superflous spaces left ;-) > > /Andreas -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH] Docbook graphic -> mediaobject
On Thu, Oct 21, 2004 at 10:24:17AM +, Andreas Vox wrote: > Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: > > > Andreas Vox <[EMAIL PROTECTED]> writes: > > | - case LyXLength::PT: //< Point = 1/72.27in = 0.351mm > > | + case LyXLength::PT: // Point = 1/72.27in = 0.351mm > > | result << len.value() * 72 / 72.27 << "pt"; > > > > The '<' is there for a reason. > > Yes. The reason is I copy&pasted this comments from their declaration :-) > > > Don't remove them. (rather fix them to be '///<') > > Doxygen'ing case labels seems rather radical to me ;-) Did you fix it after? The patch that you sent me is applied, I verified several details, but not this. :-) > Cheers > /Andreas -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH} Docbook citation
On Thu, Oct 21, 2004 at 10:23:29AM +0200, Andreas Vox wrote: > Hi! > > This is a small and independent patch which was already discussed. > > /Andreas Applied. -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH] Changelogs for the other Docbook patches
On Thu, Oct 21, 2004 at 10:38:56AM +0200, Andreas Vox wrote: > Hi! > > I bundled those extra since they relate to all other patches. > This time I didn't erase any blanks but replaced all blanks > by double blanks, as is required for the Changelog format ;-) Aha, not quite. :-) But nevermind I will fix that. > Josè, could you commit these patches? I want to go on with > the allowedNameChars runparam, DBTeXMath, calling > 'escapeEntities' where needed and further debugging. > It just feels wrong when my version gets far off the CVS version > and my patches get larger and more interconnected. First, I appreciatte that you an accent in my name. But you got the wrong one, è doesn't exists in portuguese. While it appears that ã only exists in portuguese and õ in portuguese an lituanian. And why do I know all those details? Because I have been reading the unicode website because of you know what. :-) If you don't mind I take care of the allowed names. I want to have also some fun. ;-) > /Andreas > Index: src/output_docbook.C > === > RCS file: /cvs/lyx/lyx-devel/src/output_docbook.C,v > retrieving revision 1.11 > diff -u -p -r1.11 output_docbook.C > --- src/output_docbook.C 2004/10/13 22:15:32 1.11 > +++ src/output_docbook.C 2004/10/21 07:35:02 > @@ -95,7 +95,7 @@ void docbookParagraphs(Buffer const & bu > > string ls = par->getDocbookId(); > if (!ls.empty()) > - ls = " id = \"" + ls + "\""; > + ls = " id=\"" + ls + "\""; > > // Write opening SGML tags. > switch (style->latextype) { You speak of changelogs and send me a code change? ;-) > Index: src/insets/ChangeLog > === > RCS file: /cvs/lyx/lyx-devel/src/insets/ChangeLog,v > retrieving revision 1.1050 > diff -u -p -r1.1050 ChangeLog > --- src/insets/ChangeLog 2004/10/05 13:38:30 1.1050 > +++ src/insets/ChangeLog 2004/10/21 07:35:12 > @@ -1,3 +1,12 @@ > +2004-17-05 Andreas Vox <[EMAIL PROTECTED]> ??? XML is a ISO standard, but not for dates. ;-) > + > + * insetref.C (docbook): clean illegal chars in ID > + * insetlabel.C (docbook): clean illegal chars in ID > +* insetgraphics.C (docbook, writeImageObject): write more than See here, 8 spaces. > + one format of imageobjects in > +* insetcite.[hC] (docbook, latex, cleanupWhitespace): > implementing As here. > +DocBook output for this inset ( content ) > + > 2004-10-05 Andreas Vox <[EMAIL PROTECTED]> > > * insetgraphics.C (docbook) : using mediaobject for XML; -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH} Docbook citation
On Thu, Oct 21, 2004 at 10:23:29AM +0200, Andreas Vox wrote: > Hi! > > This is a small and independent patch which was already discussed. Applied. -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH]
On Thu, Oct 21, 2004 at 10:30:05AM +0200, Andreas Vox wrote: > Hi! > > Another small and independent patch which corrects the behaviour > of starsection in DocBook. The other patch nested an inner > element into the , which is against DocBook DTD. > > /Andreas You are right, the content model is different from that of chapters/sections. Again as soon as I have the patch I will apply it directly. -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH} Docbook citation
On Thu, Oct 21, 2004 at 10:23:29AM +0200, Andreas Vox wrote: > Hi! > > This is a small and independent patch which was already discussed. As soon as I have the patch I will apply it to my local tree. -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH] DocBook cleanID and math
On Thu, Oct 21, 2004 at 03:11:05PM +0100, José Abílio Oliveira Matos wrote: > > You can send send the different patches attached in the same message, since > the existing can be read. AS Chris says ;-), I'm not complaing about you but about the patches. :-) Also due to the wrap rules some lines are broken, and patch doesn't like them. It is easier for all if I ask you to send me the files instead of having all the work to reconstruct the patches. -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH] DocBook cleanID and math
On Thu, Oct 21, 2004 at 10:21:56AM +0200, Andreas Vox wrote: > Hi! > > I submit my patch from last weekend again with bug fixes and split into > parts. Please send the files not inline. It has been a hell trying to submit them to patch. You can send send the different patches attached in the same message, since the existing can be read. Thanks, -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: name characters in xml.
On Thu, Oct 21, 2004 at 12:08:22PM +0200, Chris Karakas wrote: > José Abílio Oliveira Matos <[EMAIL PROTECTED]> schrieb am 21.10.04 00:28:34: > > > > > And is it ok if I limit myself to ASCII for the time being? > > > > Yes, we are safe with ASCII, notice that standard allows more than that. > > If we restict our self to ASCII and then when supporting unicode lift this > > restriction, we are safe. It is simple and for 1.4 should be OK. > > > > Does this mean that we cannot do DocBook in, say, greek with LyX? In greek, certainly. I was refering to the name of labels. In SGML, the default SGML declaration that comes with the stylesheets, and other tools only accept for IDs and thus for labels: - . letter numbers This is independent of the language. > I have people who ask me how to translate my PHP-Nuke HOWTO > > http://www.karakas-online.de/EN-Book/ > > in greek, or hindu or chinese. What shall I tell them? Chinese should be OK with the the CJK version of LyX. Hindu, I don't know. The problem here is just lyx supporting the appropriate encoding. > That labels, URL texts etc. should stay in english? I just said labels, the url certainly doesn't have that restriction. Notice that the xml doesn't have this restriction. OTOH yesterday while playing with references in xml, the parser accepted é in a label, but fop would complain and refuse to work. > PS. That's no accusation. I am just trying to understand what will be possible > and what not with the current state of affairs in LyX 1.4.0. LyX 1.4.0 will not support unicode, that is planned for the next version. Then some of this isses will be simplified. > -- > > Regards > > Chris Karakas > http://www.karakas-online.de > -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [patch] fix bug 1620
On Thu, Oct 21, 2004 at 09:19:38AM +0200, Georg Baum wrote: > > I had this already set on one machine, but obviously not on this one. I have > added it now. Unfortunately it would not have helped much in this case, > since parse_text() is a monster function ;-) Thanks. :-) > Georg -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: name characters in xml.
On Wed, Oct 20, 2004 at 11:11:25PM +, Andreas Vox wrote: > José Abílio Oliveira Matos <[EMAIL PROTECTED]> writes: > > > For an small introduction: > > http://www.unicode.org/glossary/ > > Which is neither small nor does it contain an entry for 'mark' ! But if you read it carefully, or search for mark you see reference to different types of marks. Do it, you will the idea. > Do you want to drive me crazy ?? It is just unicode. ;-) > > Accents, for example are marks, any diacrytic that you can imagine is a > > mark. > > Anything that leaves ink on paper when printed? No. :-) > > Spacing Mark. A combining character that is not a nonspacing mark. > > But Spacing Mark != Whitespace if I got that right, phew! Right. :-) > > > And is it ok if I limit myself to ASCII for the time being? > > > > Yes, we are safe with ASCII, notice that standard allows more than that. > > If we restict our self to ASCII and then when supporting unicode lift this > > restriction, we are safe. It is simple and for 1.4 should be OK. > > What about ISO-8859-1 umlauts etc. ? :-> They are allowed. As it is the ß. > ... > > > Note that this is for sgml, for xml the letters + ':.-_' are allowed. > > And all marks, don't forget! ;-) > Oh wait! Are '&' and '<' marks ? And '"' ? There are no marks in ascii range. :-) So if we restrict ourselves to ascii, I don't need to care about marks, for now. I hope this makes you happy. ;-) > /Andreas -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: name characters in xml.
On Wed, Oct 20, 2004 at 09:43:40PM +, Andreas Vox wrote: > José Abílio Oliveira Matos <[EMAIL PROTECTED]> writes: > > >So this means more or less: > > + All Letters > > + All Marks > > + Digits > > + Characters ':' and '_' are allowed as name-start characters. > > + Characters '-' and '.' are allowed as name characters. > > I read most of that out of the link to the XML declaration you sent earlier :-) > > Only remaining question is: what are marks ??? For an small introduction: http://www.unicode.org/glossary/ Accents, for example are marks, any diacrytic that you can imagine is a mark. I know that this is an introduction, but the best part for me is: Spacing Mark. A combining character that is not a nonspacing mark. :-D I couldn't say it best. :-) > And is it ok if I limit myself to ASCII for the time being? Yes, we are safe with ASCII, notice that standard allows more than that. If we restict our self to ASCII and then when supporting unicode lift this restriction, we are safe. It is simple and for 1.4 should be OK. > BTW, I changed the translation scheme to: > > : or comma or semicolon to . > _ and space to - > all others dropped > if any mangling occured, append "-" + unique number > if no mangling occured but the original ended in a digit, append "." > > That should result in quite readable mangled names which are much > shorter than the "Morse" code I proposed earlier. > > Also the scheme is very similar to the one LyX already uses for filenames > (yes, I just copied the good ideas :-) ) You are learning. :-) Note that this is for sgml, for xml the letters + ':.-_' are allowed. > /Andreas > -- José Abílio Matos LyX and docbook a perfect match. :-)
name characters in xml.
Ok, finally I got it: http://www.w3.org/TR/REC-xml/#CharClasses You can see what those classes are here: Search for "General Category Escapes" http://www.webreference.com/programming/awxml1/6.html So this means more or less: + All Letters + All Marks + Digits + Characters ':' and '_' are allowed as name-start characters. + Characters '-' and '.' are allowed as name characters. -- José Abílio
Re: [patch] fix bug 1620
On Wed, Oct 20, 2004 at 09:48:06PM +0200, Georg Baum wrote: > The attached patch fixes bug 1620, although I am not sure wether this > newline problem exists at other places, too. Therefore the FIXME. I am > going to apply this if nobody complains. Hi Georg, not related but I use in my $HOME/.cvsrc this: cvs -z6 diff -upN rdiff -upN update -dP My point is *p* option for diff, it allows to see the C/C++ function where the change takes place. Please consider using that it makes patches easier to read, at least to me. :-) Thanks. > Georg -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH] Docbook export math/graphic/refs
On Wed, Oct 20, 2004 at 06:51:31PM +, Andreas Vox wrote: > > < No way. > > Ok, but then it definitely will not be stored in .layout files. > > < > c) a converter > > < All the tools I know work only for valid documents. Is there any of the > < used tools who doesn't care about the the document validation? I don't think > < so. > > saxon wasn't quite as picky as Openjade. As far as I understand you don't have a choice. As simples as it can be. See: http://www.w3.org/TR/NOTE-sgml-xml-971215 http://tecfa.unige.ch/guides/xml/frame-sgml/html/quick-fm-xml-guide-4.html That is if you change the smgl declaration it is no more xml. That is how read it. Note that I can be wrong. Please try saxon with different labels and see the result. Is it what you expected? ... > I understood that '-' and '.' already are allowed by the standard? If I'm right we making a tempest in a tea pot. That is what I'm trying to say, I don't see anymore choice other than the '_' so the resulting document is not insane. No need to make it complex. The other point of Chris is: should lyx be clever and not tell the users that it is fixing the document without the user's approval? Chris thinks not, the lyx core team thinks otherwise. All the discussion comes to this. And only for sgml, not for xml. ... > Does Lex::lex give unicode chars? Does std::string store them? > Should we bother? (another white area on my mental map of LyX) That will be for 1.5 or 2.0 as I prefer to think. ;-) > < > Oh BTW, Chris, if you read this: > < > what happens if the user activates '&' for names? > > < You know the result. > > I don't *know* it. But of course I have a vivid imagination ;-) > Do we need to protect the user in a way that '&' is mangled even if it > was included in the allowedNameChars? Any other chars? Someone who plays with this, should know more that that. This equivalent to change the role of the characters in tex. > < > Should we ask others before we change the .layout or .lyx format ?? > > < Who said that we need to do that? > > I remember remotely some idea about a "CNAME= ..." option in the > .layout files ... > Now that a) and b) are gone, that won't be a problem. \relax :-) You traitor. Finally I see your true face, it should have been. :-D > /Andreas -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH] Docbook export math/graphic/refs
On Wed, Oct 20, 2004 at 05:24:41PM +, Andreas Vox wrote: > José Abílio Oliveira Matos <[EMAIL PROTECTED]> writes: > > Hm, I think I haven't thought that completly through. > 1. and 3. can't be combined that easily. > We have to decide if namemangling is a setting of > a) a class More than a class, it is a property from the backend. Docbook, in this case. This affects the validation of all docbook documents, be it article, book, set, chapter or whatever. > b) a document No way. :-) > c) a converter All the tools I know work only for valid documents. Is there any of the used tools who doesn't care about the the document validation? I don't think so. If this was a converter option the best option would be another flavour. Don't forget that we need to pass that option to lyx. > a) and b) can be combined easily, although b) needs a new dialog. > For c) there already is an entry for extra flags in the dialog for > converter definition, but that is independent of the .layout file. > > c) overrides b) overrides a) ? I think that we should implement only c) this is not perl, you know? ;-) > > This will probably imply to add cname to outputparams, > > unless buffer is a member... > > I would prefer "allowedNameChars" with the values: > "" only letters, digits, '-' and '.' > "all" no mangling accurs > "$+#!_*" only letters, digits, '-', '.' and the given chars are accepted. > Similarily for other char combinations. What is the logic behind? What about the upper part of the ascii table. I think that in a sane way there only three or four option. No need to complicate what doesn't need to. :-) > Oh BTW, Chris, if you read this: > what happens if the user activates '&' for names? ;-) You know the result. ;-) > José, I could add it to runparams. > For a) and b) it needs to be added to bufferparams or somewhere else; > I don't feel knowledgeable enough to do that. > Should we ask others before we change the .layout or .lyx format ?? ;-) Who said that we need to do that? :-) > /Andreas -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH] Docbook export math/graphic/refs
On Wed, Oct 20, 2004 at 03:30:13PM +, Andreas Vox wrote: > < > And for the settings dialog I prefer (in this order) > < > 1. special flag for converter (the user could define a "nonmangled" > < > Docbook format > < > 2. Document settings > < > 3. none (edit .layout file manually) > < > 4. .layout file editor > > < It's O.K., we have a deal. > > Ah, we haven't talked about the price yet! I will think of something. ;-) > > < Of course you may leave the layout editor for later (but I hope not > < for "never to be done"). > > Or leave it to someone else ... > Above was my "Preferred order". My implementation order will be: > > 3. then 1. then hell freezes then 2. then 4. :-) 3. 4. 1. hell freezes then 2. ;-) Lets us goto to 3 for 1.4.0. Andras, do you take care of this or do you want me to add it? This will probably imply to add cname to outputparams, unless buffer is a member... > Ciao > /Andreas > -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH] Docbook export math/graphic/refs
On Wed, Oct 20, 2004 at 10:46:58AM +0200, Chris Karakas wrote: > Georg Baum <[EMAIL PROTECTED]> schrieb am 19.10.04 22:15:29: > > > > IMHO if a user can modify his SGML declaration he can as well edit layout > > files. The nonexpert user will just use what is there: the standard SGML > > declaration and the standard layout file, and they should match. If e.g. > > SuSE decide to ship a modified SGML declaration, we can as well expect > > that they ship a modified layout file. > > > > The non-expert user will use underscores in his labels and will not be amused > to see that they were transformed to something else without warning. > > Ah...Warning! > > How about a warning, to be output when LyX exports the file to DocBook? > Something like: > > About to export to DocBook...done > Warning: Character "_" in label "my_label" was transformed to dash: "my-label". > To leave "_" untouched, change the value of CNAME in xyz.layout.file to include "-". I forgot to say this in my previous message. I'm in favour of warning display, with some small differences from what you say. We are getting there. ;-) Notice that it is not that simple. It is not enough to change the layout file. I propose to emit a warning if CNAME is different from the default and from "". You have to modify the SGML declaration file also. Also I will add a section about this to the LyX-Docbook FAQ. If some is puzzeled then that will be the first place to search. :-) It is always a matter of compromise. The funny part is that are pushing for the advanced users, but with some of your transformation scripts, this will work of the box for any user. I propose to let the curious user to know how to become advanced using the documentation, not the gui. > > > It all boils down to the question: do we do this through a dialog that > > will > > > manipulate the layout file, or do we expect the user who has such wishes > > to > > > be knowledgeable enough to know what he is looking for and start > > > tweaking the CNAME variable in some obsure file. > > > > Of course this should be documented. And who said that a graphical editor > > for layout files is a bad thing? > > > > I agree. How about this: > > Do it with the CNAME thing today, but add a Warning as above > for every label that was changed. > > Then add a "to do" item in the list of things to be done: > Program a graphical editor for layout files. That is fair. > That's general enough and would take care of all such cases where > the developers would rather have something done through a change in > the layout file and the users would rather tweak some option in a > graphical dialog. > > Then, for every change that is done by LyX (in labels, names, whatever), > add a Warning that says what LyX did and that the user can change it > by using the graphical layout editor. As thing to put in my todo list, it is acceptable, but I have more urgent tasks now such as integrate your scripts. :-) > -- > Regards > > Chris Karakas > http://www.karakas-online.de -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH] Docbook export math/graphic/refs
On Tue, Oct 19, 2004 at 10:12:58PM +0200, Georg Baum wrote: > > > Maybe from some standpoint it belongs there. But it is not user-friendly > > to expect the user to tweak layout files, IMHO. > > IMHO if a user can modify his SGML declaration he can as well edit layout > files. The nonexpert user will just use what is there: the standard SGML > declaration and the standard layout file, and they should match. If e.g. > SuSE decide to ship a modified SGML declaration, we can as well expect > that they ship a modified layout file. That is my point. :-) > > It all boils down to the question: do we do this through a dialog that > will > > manipulate the layout file, or do we expect the user who has such wishes > to > > be knowledgeable enough to know what he is looking for and start > > tweaking the CNAME variable in some obsure file. > > Of course this should be documented. And who said that a graphical editor > for layout files is a bad thing? Believe it or not it is in my plans, using python naturally. ;-) > > I find the first solution (which is what Andreas proposed) better. > > > > Maybe you are right - why should DocBook options belong to LyX dialogs? > > But then, why should LyX mess up with DocBook options through > > its ID mangling? As I see it, it is LyX which is trying to "do the > > Because most users are far less knowleadgable wrt docbook/sgml than you > are. I understand that you want the expert power, but lyx should not only > be friendly to experts, but also to less knowleadgable users. For the same reason that it is not there for latex users, it doesn't belong there. As I said before this is a matter of configuring docbook, not a lyx document. This is not something that you change everyday, neither monthly. Due to its consequences, that you explain very weel in your pages this is something that you never change. That was your point Chris. :-) > Georg -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH] Docbook export math/graphic/refs
On Tue, Oct 19, 2004 at 04:46:45PM +, Andreas Vox wrote: > > Something like this Document settings->SGML: > >enforce valid SGML/XML ids (yes,no): yes >if yes, additional allowed chars:.:_ > > what you have in mind? > Second input field would be disabled if answer to first one is "no", > then all chars are allowed (by LyX). The idea is getting better. But I don't like the idea of a document dialog. This is an option for docbook, not for the document. Read bellow what I propose. > The users are responsible to keep their SGML declaration and the LyX-allowed > chars in sync. > > Default would be "enforce" and no allowed chars except ".-". I agree. > Allowed chars are also automatically allowed as start chars (no prepended 'x'). > > If you change your .layout file to include "CNAME=.:_" that would be > the default for the second input field. I propose thus that all the configuration goes in the textclass, where it belongs in my humble opinion: 1) I propose that we leave the default option as CNAME=".-". 2) If the users chooses other characters we respect them. An example from some xml.dcl is CNAME=".-·", we don't mangle those characters. 3) If the users chooses: CNAME="" # empty string lyx doesn't mangle the ids. Chris would have to add this to your customization for it to work as it does now. > Ok? Do we have a deal, now? ;-) > /Andreas -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH] Docbook export math/graphic/refs
On Tue, Oct 19, 2004 at 01:36:55PM +, Andreas Vox wrote: > José Abílio Oliveira Matos <[EMAIL PROTECTED]> writes: > > > > It violates the principle "you asked for it, you got it". > > > > That is not your principle. > > What You See Is What You Mean (not What You Get). > > We also have the principle "You don't have to be a LaTeX initiate > to use LyX". I think this should also apply to SGML and DocBook. True. > Another thing that is really missing is a distribution for DocBook, > which would include all the relevant entities, dtds, stylesheets and > programs. And CATALOGs! Something like teTeX for DocBook sgml-tools v2 tried to do that. The problem was the overhead of work to maintain the different tools, style sheets and everything else. The forced the author to abandon this strategy, to that later version 3.0 only had the basics mechanism for convertions. That is also one of the reasons o LSB standard for SGML and XML, with /etc/sgml and /etc/xml. I use FC2 and all the tools work, and I do think that this is true also for other linux distributions. > > IMHO we should a validation stage that will be called manually or before > > converting to other formats. I have discussed that with Andreas last week. > > "Started to discuss" is more like it ... :-) If I recall correctly I was arguing > for dynamical Layout-menues to keep the user from setting layouts for > paragraphs which are not allowed at this place ... It is easier for now to have them controlled manually for reasons that you have pointed out, copy and paste, external insertion, cut, code moved, etc. Is this convincing? ;-) > /Andreas -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH] Docbook export math/graphic/refs
On Tue, Oct 19, 2004 at 02:39:56PM +0200, Chris Karakas wrote: > José Abílio Oliveira Matos <[EMAIL PROTECTED]> schrieb am 19.10.04 13:32:21: > > > > On Tue, Oct 19, 2004 at 01:12:47PM +0200, Chris Karakas wrote: > > > > > > - Somebody in the DocBook committee decided that underscore is "out". > > > > First I understand your point, second the problem is precisely the > > opposite that you refering to. > > > > Well...that's precisely what happened to me, believe it or not. > My documents worked with underscores in the labels, then I upgraded > DocBook, openjade and the rest - and suddenly they did not work. But then it wasn't the docbook committee but probably the packager decision to comply with the rest of the world. (Notice that I am not criticizing you, you are free to change your SGML declaration according to the standard.) I have been searching the mailing list for this and I have a couple of messages that support this. > Sorry, but in this case I change the SGML declaration, not the labels. > Cool URIs don't change. Cool labels don't change either: > > http://www.karakas-online.de/mySGML/cool-labels-dont-change.html > > > > > > > And why all this? Because LyX thinks it must correct my labels > > > and impose his view of correctness on my names. > > > > I'm sorry this is non negotiable. LyX should work out of box. What is not negotiable is the default behaviour, FWIW. > Then make LyX call an external parser and validate through it. > But leave the labels intact and the decision to t he user. > LyX should not change the user's labels, this is not LyX' > responsibility! This is the same reasoning as for latex. There as well there are people who think the same as you do. We should have a uniform criterion, no matter which backend we use. And we have decided to mangle the ids. This applies to latex, linuxdoc and docbook. > > What we can do is allow the users to specify what characters are allowed > > in CNAMES. This is easy we garantee that those characters will not be > > messed. Is this acceptable for you? > > I am not sure. I am against automatic label changes, even for a > "good purpose". If the user types a label and sees a different > filename in the "rendered" document, he will go crazy - at least > I would do... > > It violates the principle "you asked for it, you got it". That is not your principle. ;-) What You See Is What You Mean (not What You Get). :-) Notice that that principle is not clear as that, using lyx with docbook we are using lots of hidden assumptions bellow. This is not the single one. > If my SGML Declaration is such that makes my documents > non-sharable with others - so be it. It iy my responsibility as a > user and owner of my documents. It is not LyX to blame for this. If you use a different SGML declaration that can be configured as I have shown before. Actually it is enough to have this file in your local lyx directory for layouts ( usually $HOME/.lyx/layouts) this modified version of db_stdclass.inc - Input db_stdclass.inc ClassOptions Other "CNAME=..." End - That means that every docbook classes will work. This means thus that all your documents will work. This is almost the same as the dsssl or xsl configuration files for the transformation. You then use your own configuration aver the standard files. ** Angus ** One more point as the texclasses behave as xls. ;-) ** > If you want LyX to "work out of the box", you should pursue the idea > of "validating against the DTD while editing", not "inserting new > characters and replacing old ones in the user's labels in the hope > that these will pass the DTD test later". IMHO we should a validation stage that will be called manually or before converting to other formats. I have discussed that with Andreas last week. > You can't know what configuration the user has. That is why you can configure it. It the user has a different setup he can configure lyx accordingly. Notice that at present I can't have a label called 'José'. But if I change my SGML declaration to allow the _é_ then I can use it. If I know enough as to want stable labels, then I know enough not to change them in the first place. I just want to show you that this arguments is as defensible as yours. Using almost the same arguments. :-) > -- > Regards > > Chris Karakas > http://www.karakas-online.de -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH] Docbook export math/graphic/refs
On Tue, Oct 19, 2004 at 01:12:47PM +0200, Chris Karakas wrote: > > There is more to it than you think. here is a scenario: > > - Labels become filenames: > > http://www.karakas-online.de/mySGML/labels-as-filenames.html > - The first version of the document goes online. > > - Search engines crawl and index the document. > > - In previous versions of DocBook, underscore *was* allowed in the > SGML Declaration. Thus the first version contains underscores in > the HTML filenames. > > - Then the user upgrades his DocBook. > > - Somebody in the DocBook committee decided that underscore is "out". First I understand your point, second the problem is precisely the opposite that you refering to. The SGML declaration is an hint, that basically says that all documents that conform it are safe to be exchanged. So it is not normative but indicative. The reason why the Docbook comitee doesn't change it to something less restrictive is precisely to preserve this. The problem is that don't change it to have less constraints. They would never, *ever* change it to something more restrictive. > - What are the user's choices? > > - Either he changes the labels - but this will changes his HTML filenames, > i.e. the URI's of his document. But "cool URIs don't change": > > http://www.karakas-online.de/mySGML/cool-labels-dont-change.html > > But now, since the URIs changed, the document is not found anymore > by the search engines. It may take 3 to 6 months to be found again. > > The document is dead. Just because somebody decided to change the > SGML Declaration between two versions... :-( > > - The other choice is - the user changes the SGML Declaration. > > But then LyX comes into play and messes up with the labels! > Nothing is the way it was! Labels have changed and so have the > filenames too! > > And why all this? Because LyX thinks it must correct my labels > and impose his view of correctness on my names. I'm sorry this is non negotiable. LyX should work out of box. What we can do is allow the users to specify what characters are allowed in CNAMES. This is easy we garantee that those characters will not be messed. Is this acceptable for you? In the layout file: # Modified layout file Input docbook.layout ClassOptions Other "CNAME=.-·" End You can replace the last line by: Other "CNAME=.-·_" > This can't be the right thing. > > Leave it to the SGML parser. The parser will complain - if it has to. > > -- > Regards > > Chris Karakas > http://www.karakas-online.de -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH] Docbook export math/graphic/refs
On Mon, Oct 18, 2004 at 10:54:55PM +, Andreas Vox wrote: > José Abílio Oliveira Matos <[EMAIL PROTECTED]> writes: > > > On Mon, Oct 18, 2004 at 08:43:46PM +0200, Chris Karakas wrote: > > > I hope you are not suggesting to change the DocBook SGML Declaration? > > At least because of a small detail like this. > > Well, if Chris wants to, he can of course do it. He just wont be able to produce > LyX documents which produce references which contain the new characters :-P > > And if Chris manages to convince the DocBook stylesheet guys to include his > change to the SGML declaration, I'll be more than happy to provide a patch > which honors this change ;-) I'm forced to agree with you here. > > As Andreas mentioned it is a question of producing legal code, we use the > > same trick for latex, for identical reasons. > > What, where? There's again some code noone told me about! The road to wisdom has many shortcuts. ;-) > I might have been able to use that! ;-) The problem is that the set of characters that latex doesn't support is not the same as sgml. But it can be used as a model: src/support/lstrings.C (escape) > Ciao > /Andreas -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH] Docbook export math/graphic/refs
On Mon, Oct 18, 2004 at 08:43:46PM +0200, Chris Karakas wrote: > > > > Jose and Andreas, > > it is not that simple! The underscore may very well be allowed in the value of an ID > attribute, at least in SGML! This quite tricky subject is dealt in: > > character "_" not allowed in value of attribute ID > http://www.karakas-online.de/forum/viewtopic.php?t=872 I hope you are not suggesting to change the DocBook SGML Declaration? At least because of a small detail like this. Also if lyx deals with all the references there is no problem as it will be always consistent. > I suggest to leave validation to validating parsers, or, if you want to > validate, then use an external one, don't try to reinvent the wheel. SGML > can be quite tricky at this - and that was a reason that led to XML, namely > that parsing SGML can be a challenge to program. As Andreas mentioned it is a question of producing legal code, we use the same trick for latex, for identical reasons. > -- > Regards > > Chris Karakas > http://www.karakas-online.de > -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: [PATCH] Docbook export math/graphic/refs
On Mon, Oct 18, 2004 at 07:52:17PM +0200, Chris Karakas wrote: > > Does LyX really do it so, also for image file formats? I apologize. BTW, > that was the most polite RTFM I ever got. :-) If I understood you well, yes lyx has all the mechanisms to do what you described. > -- > Regards > > Chris Karakas > http://www.karakas-online.de -- José Abílio Matos LyX and docbook a perfect match. :-)