Re: Commit Rules Post-1.5.0
Martin Vermeer wrote: We already have that: charstyles, which are however pretty limited. But they could be extended (under a different name probably, style insets?) Could something like that do the trick for beamer? (I haven't used beamer myself . . .) Would be a partial solution at best. We also need optarg insets extended to accept as delimiters instead of [ ] . And then a dialog, definable from the .layout file, for picking the various 1- etc strings. (this feature would also help implementing Carlisle's enumerate extension more generally.) If we have nested styles. For example a titlepage style, with nested title, author, date, etc.. with some rules to specify the possible order of nested styles and a general mechanism for optargs, we will dramatically increase the amount of latex that can be lyxified ... The gui part is, however, not that easy. Cheers, Charles -- http://www.kde-france.org
Re: Commit Rules Post-1.5.0
Martin Vermeer wrote: > > We already have that: charstyles, which are however pretty > limited. But they could be extended (under a different name > probably, "style insets"?) > >> Could something like that do the trick for beamer? (I haven't >> used beamer myself . . .) > > Would be a partial solution at best. We also need optarg > insets extended to accept < > as delimiters instead of > [ ] . And then a dialog, definable from the .layout file, > for picking the various 1- etc strings. (this feature > would also help implementing Carlisle's enumerate > extension more generally.) > If we have nested styles. For example a titlepage style, with nested title, author, date, etc.. with some rules to specify the possible order of nested styles and a general mechanism for optargs, we will dramatically increase the amount of latex that can be lyxified ... The gui part is, however, not that easy. Cheers, Charles -- http://www.kde-france.org
Re: Commit Rules Post-1.5.0
Charles de Miramon wrote: I think that what is needed is a standard mechanism to enter in a friendly GUI way structured information in LyX like titlepages, frames in beamer,multiple choice questions, etc. The gui form would be stored in the layout and when you create a new beaamer frame (title page, multiple choixe entry) the ui form would be displayed and you could enter title, subtitle, etc... LyX is limited by the dropdown style list copied from wordprocesssors that works for paragraph formatting but not for structured information. An idea: What if the .layout could specify document-specific insets? They would be listed on the insert menu, and show up in the GUI as boxes with whatever caption the .layout specifies. The .layout should also specify latex code to be generated, and enforce some structure with simple rules about how they nest. Could something like that do the trick for beamer? (I haven't used beamer myself . . .) Helge Hafting
Re: Commit Rules Post-1.5.0
On Mon, Jul 30, 2007 at 10:07:54AM +0200, Helge Hafting wrote: Charles de Miramon wrote: I think that what is needed is a standard mechanism to enter in a friendly GUI way structured information in LyX like titlepages, frames in beamer,multiple choice questions, etc. The gui form would be stored in the layout and when you create a new beaamer frame (title page, multiple choixe entry) the ui form would be displayed and you could enter title, subtitle, etc... LyX is limited by the dropdown style list copied from wordprocesssors that works for paragraph formatting but not for structured information. An idea: What if the .layout could specify document-specific insets? They would be listed on the insert menu, and show up in the GUI as boxes with whatever caption the .layout specifies. The .layout should also specify latex code to be generated, and enforce some structure with simple rules about how they nest. We already have that: charstyles, which are however pretty limited. But they could be extended (under a different name probably, style insets?) Could something like that do the trick for beamer? (I haven't used beamer myself . . .) Would be a partial solution at best. We also need optarg insets extended to accept as delimiters instead of [ ] . And then a dialog, definable from the .layout file, for picking the various 1- etc strings. (this feature would also help implementing Carlisle's enumerate extension more generally.) Helge Hafting - Martin
Re: Commit Rules Post-1.5.0
Charles de Miramon wrote: I think that what is needed is a standard mechanism to enter in a friendly GUI way structured information in LyX like titlepages, frames in beamer,multiple choice questions, etc. The gui form would be stored in the layout and when you create a new beaamer frame (title page, multiple choixe entry) the ui form would be displayed and you could enter title, subtitle, etc... LyX is limited by the dropdown style list copied from wordprocesssors that works for paragraph formatting but not for structured information. An idea: What if the .layout could specify document-specific insets? They would be listed on the insert menu, and show up in the GUI as boxes with whatever caption the .layout specifies. The .layout should also specify latex code to be generated, and enforce some structure with simple rules about how they nest. Could something like that do the trick for beamer? (I haven't used beamer myself . . .) Helge Hafting
Re: Commit Rules Post-1.5.0
On Mon, Jul 30, 2007 at 10:07:54AM +0200, Helge Hafting wrote: > Charles de Miramon wrote: > > I think that what is needed is a standard mechanism to enter in a friendly > > GUI way structured information in LyX like titlepages, frames in > > beamer,multiple choice questions, etc. The gui form would be stored in the > > layout and when you create a new beaamer frame (title page, multiple choixe > > entry) the ui form would be displayed and you could enter title, subtitle, > > etc... > > > > LyX is limited by the dropdown style list copied from wordprocesssors that > > works for paragraph formatting but not for structured information. > > > An idea: > What if the .layout could specify document-specific insets? > They would be listed on the insert menu, and show up > in the GUI as boxes with whatever caption the .layout > specifies. The .layout should also specify latex code to be > generated, and enforce some structure with simple rules > about how they nest. We already have that: charstyles, which are however pretty limited. But they could be extended (under a different name probably, "style insets"?) > Could something like that do the trick for beamer? (I haven't > used beamer myself . . .) Would be a partial solution at best. We also need optarg insets extended to accept < > as delimiters instead of [ ] . And then a dialog, definable from the .layout file, for picking the various 1- etc strings. (this feature would also help implementing Carlisle's enumerate extension more generally.) > Helge Hafting - Martin
Re: Commit Rules Post-1.5.0
Pavel Sanda wrote:
* hyperref support - mostly a document settings checkbox
to load the package. Nice for PDFs. It should be noted that
there are some limitations - marking something hyper-referenced
with a foreign language will crash latex for example. Good
hyperref support can automatically add the workaround:
\texorpdfstring{std.text with language}{pdfbookmarktext without}
please can you add all comments wrt hyperref to
http://bugzilla.lyx.org/show_bug.cgi?id=3527
?
Done.
People on the user list seems to ask for the SIunits package
is it in bugz ?
Enhanchement bug 4070 filed.
Helge Hafting
Re: Commit Rules Post-1.5.0
Helge Hafting wrote: Well, I put my stuff in. The page is out of date, 1.5 is out and every 1.5 feature could be removed. Or at least the votes replaced with done in 1.5 for the benefit of those who haven't upgraded. Please go ahead. Jürgen
Re: Commit Rules Post-1.5.0
Bo Peng wrote: Maybe not _all_ are badly missed, but here is a wishlist with my wishes as well as stuff from the user's list: Did you have a look at http://wiki.lyx.org/LyX/FeaturePoll ? Maybe we can put these stuff over there, and let the users decide what are the most wanted. Well, I put my stuff in. The page is out of date, 1.5 is out and every 1.5 feature could be removed. Or at least the votes replaced with done in 1.5 for the benefit of those who haven't upgraded. I wonder if enough people track this page to make the votes realistic? Helge Hafting
Re: Commit Rules Post-1.5.0
Martin Vermeer wrote: What feature do you think that lyx is missing badly? The beamer layout requires too much ERT and non-intuitive tweaking. Perhaps something can be done about it in the frame of short title / optional argument. My dream is to have a LyX-beamer that is compatitive also in usability with ppt. I think that what is needed is a standard mechanism to enter in a friendly GUI way structured information in LyX like titlepages, frames in beamer,multiple choice questions, etc. The gui form would be stored in the layout and when you create a new beaamer frame (title page, multiple choixe entry) the ui form would be displayed and you could enter title, subtitle, etc... LyX is limited by the dropdown style list copied from wordprocesssors that works for paragraph formatting but not for structured information. Cheers, Charles -- http://www.kde-france.org
Re: Commit Rules Post-1.5.0
Richard Heck wrote: Helge Hafting wrote: * Layout files should be able to set things like document font, language, paper size and so on - if the layout writer thinks it is appropriate. Today I can't just send someone a custom .layout, I have to tell them to set palatino, margins, and so on too. And they have to do this on every new document, if the custom document type don't match document defaults otherwise used. Please post an enhancement request about this so it doesn't get lost. Enhancement request 4072 filed. * References. - Should be mostly automatic. The writer should not need to insert a label in order to refer to section 3.6.1 - LyX should automatically offer all numbered entities in the reference dialog, and generate the latex label as needed. The explicit label is only needed in cases like a reference to the fifth paragraph in a section - it _might_ end up on a different page than the section heading. This would be nice, indeed. Enhancement request 4073. Helge Hafting
Re: Commit Rules Post-1.5.0
Jürgen Spitzmüller wrote: Helge Hafting wrote: Well, I put my stuff in. The page is out of date, 1.5 is out and every 1.5 feature could be removed. Or at least the votes replaced with done in 1.5 for the benefit of those who haven't upgraded. Please go ahead. Ok, removed votes for implemented stuff, shortening the document. Added a link to new in 1.5. Used strikeout and green done in 1.5 for implemented features. Helge Hafting
Re: Commit Rules Post-1.5.0
Pavel Sanda wrote:
* hyperref support - mostly a document settings checkbox
to load the package. Nice for PDFs. It should be noted that
there are some limitations - marking something hyper-referenced
with a foreign language will crash latex for example. Good
hyperref support can automatically add the workaround:
\texorpdfstring{std.text with language}{pdfbookmarktext without}
please can you add all comments wrt hyperref to
http://bugzilla.lyx.org/show_bug.cgi?id=3527
?
Done.
People on the user list seems to ask for the SIunits package
is it in bugz ?
Enhanchement bug 4070 filed.
Helge Hafting
Re: Commit Rules Post-1.5.0
Helge Hafting wrote: > Well, I put my stuff in. The page is out of date, 1.5 is out > and every 1.5 feature could be removed. Or at least the votes > replaced with "done in 1.5" for the benefit of those who haven't upgraded. Please go ahead. Jürgen
Re: Commit Rules Post-1.5.0
Bo Peng wrote: Maybe not _all_ are badly missed, but here is a wishlist with my wishes as well as stuff from the user's list: Did you have a look at http://wiki.lyx.org/LyX/FeaturePoll ? Maybe we can put these stuff over there, and let the users decide what are the most wanted. Well, I put my stuff in. The page is out of date, 1.5 is out and every 1.5 feature could be removed. Or at least the votes replaced with "done in 1.5" for the benefit of those who haven't upgraded. I wonder if enough people track this page to make the votes realistic? Helge Hafting
Re: Commit Rules Post-1.5.0
Martin Vermeer wrote: > >> What feature do you think that lyx is missing badly? > > The beamer layout requires too much ERT and non-intuitive tweaking. > Perhaps something can be done about it in the frame of short title / > optional argument. My dream is to have a LyX-beamer that is compatitive > also in usability with ppt. > I think that what is needed is a standard mechanism to enter in a friendly GUI way structured information in LyX like titlepages, frames in beamer,multiple choice questions, etc. The gui form would be stored in the layout and when you create a new beaamer frame (title page, multiple choixe entry) the ui form would be displayed and you could enter title, subtitle, etc... LyX is limited by the dropdown style list copied from wordprocesssors that works for paragraph formatting but not for structured information. Cheers, Charles -- http://www.kde-france.org
Re: Commit Rules Post-1.5.0
Richard Heck wrote: Helge Hafting wrote: * Layout files should be able to set things like document font, language, paper size and so on - if the layout writer thinks it is appropriate. Today I can't just send someone a custom .layout, I have to tell them to set "palatino", margins, and so on too. And they have to do this on every new document, if the custom document type don't match document defaults otherwise used. Please post an enhancement request about this so it doesn't get lost. Enhancement request 4072 filed. * References. - Should be mostly automatic. The writer should not need to insert a label in order to refer to section 3.6.1 - LyX should automatically offer all numbered entities in the reference dialog, and generate the latex label as needed. The explicit label is only needed in cases like a reference to the fifth paragraph in a section - it _might_ end up on a different page than the section heading. This would be nice, indeed. Enhancement request 4073. Helge Hafting
Re: Commit Rules Post-1.5.0
Jürgen Spitzmüller wrote: Helge Hafting wrote: Well, I put my stuff in. The page is out of date, 1.5 is out and every 1.5 feature could be removed. Or at least the votes replaced with "done in 1.5" for the benefit of those who haven't upgraded. Please go ahead. Ok, removed votes for implemented stuff, shortening the document. Added a link to "new in 1.5". Used strikeout and green "done in 1.5" for implemented features. Helge Hafting
Re: Commit Rules Post-1.5.0
On Thu, Jul 26, 2007 at 07:18:57AM +0200, Jürgen Spitzmüller wrote: Furthermore, I'd like to support Richard's idea of finishing the character style implementation. (Yay) john
Re: Commit Rules Post-1.5.0
On Wed, Jul 25, 2007 at 05:11:39PM +0100, José Matos wrote: On Wednesday 25 July 2007 16:13:03 Bo Peng wrote: For 1.5.x, you'll need my OK. For 1.6.x, the usual review process applies. Bo I would like to see some kind of plan, nothing too formal but at the same time a general idea where the current development stage is leading us. I would like that each developer answered three questions: Where do you think that LyX needs more attention? Quality assurance. There is messy code that should be cleaned up, half-baked features that should be full-baked, and temptations to add new features that should be resisted -- or at least carefully thought through. What feature do you think that lyx is missing badly? The beamer layout requires too much ERT and non-intuitive tweaking. Perhaps something can be done about it in the frame of short title / optional argument. My dream is to have a LyX-beamer that is compatitive also in usability with ppt. Where do you intend to work during this development cycle? Small things only...
Re: Commit Rules Post-1.5.0
Helge Hafting wrote:
* Layout files should be able to set things like document font, language,
paper size and so on - if the layout writer thinks it is appropriate.
Today I can't just send someone a custom .layout, I have to tell
them to
set palatino, margins, and so on too. And they have to do this on
every new document, if the custom document type don't match
document defaults otherwise used.
Please post an enhancement request about this so it doesn't get lost.
* References.
- Should be mostly automatic. The writer should not need to insert
a label in order to refer to section 3.6.1 - LyX should automatically
offer all numbered entities in the reference dialog, and generate
the latex label as needed. The explicit label is only needed in cases
like a reference to the fifth paragraph in a section - it _might_
end up on a different page than the section heading.
This would be nice, indeed.
- Support package nameref so we can print the name of the
entity referenced too. Perhaps this needs explicit labels.
http://bugzilla.lyx.org/show_bug.cgi?id=3221
* hyperref support - mostly a document settings checkbox
to load the package. Nice for PDFs. It should be noted that
there are some limitations - marking something hyper-referenced
with a foreign language will crash latex for example. Good
hyperref support can automatically add the workaround:
\texorpdfstring{std.text with language}{pdfbookmarktext without}
http://bugzilla.lyx.org/show_bug.cgi?id=3482, mostly. I hope to get to
some of this, but it'd be a good project for someone trying to learn the
code. It's not hugely difficult, I don't think, but it will have a lot
of moving parts.
* user defined textstyles and layouts.
This is on the way, at least to a significant extent.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Commit Rules Post-1.5.0
And as one can see from the immediate opening of the branch (as opposed to the agreement to branch only after 1.5.1 and fix a big bunch of the long standing bugs before) you will probably not get much help on that branch, although that would definitely be needed. My condolences. Although I am eager to implement those 'new' and 'great' features, I fully agree with you on this and I guess Jose can order a feature freeze on trunk. It is already reported that middle-button paste is broken (so I am fixing it), and there should be many more reports after 1.5.0 is delivered. Bo
Re: Commit Rules Post-1.5.0
* hyperref support - mostly a document settings checkbox
to load the package. Nice for PDFs. It should be noted that
there are some limitations - marking something hyper-referenced
with a foreign language will crash latex for example. Good
hyperref support can automatically add the workaround:
\texorpdfstring{std.text with language}{pdfbookmarktext without}
please can you add all comments wrt hyperref to
http://bugzilla.lyx.org/show_bug.cgi?id=3527
?
People on the user list seems to ask for the SIunits package
is it in bugz ?
pavel
Re: Commit Rules Post-1.5.0
José Matos wrote:
On Wednesday 25 July 2007 16:13:03 Bo Peng wrote:
For 1.5.x, you'll need my OK.
For 1.6.x, the usual review process applies.
Bo
I would like to see some kind of plan, nothing too formal but at the same time
a general idea where the current development stage is leading us.
I would like that each developer answered three questions:
Where do you think that LyX needs more attention?
* startup speed
* rendering/scrolling speed
What feature do you think that lyx is missing badly?
Maybe not _all_ are badly missed, but here is a wishlist with my
wishes as well as stuff from the user's list:
* dialogbox-less search/replace. Could be as simple as
docking the existing dialog and adjusting its layout for
such use. No more word found underneath the search dialog!
Ideally, some kind of solution using the minibuffer area, that goes away
whenever the minibuffer gets used for something else. This way, no need
to even _dismiss_ the search dialog.
* Perhaps boxless spellcheck, although that dialog is bigger. No more
moving the dialog to see the context for the mis-spelled word.
* Inset that prints the lyx file name (and optionally the path).
Often asked about on the user list. Nice for our ref:
Latex \jobname isn't up to this due to temp directories and the .lyx
extension. (Or possibly .tar.gz extension, see the next point.)
* Ability to wrap up a master document with child documents,
illustrations and everything in a .tar.gz file that LyX supports
directly.
Shouldn't be that hard - unpack the .tar.gz in the temp directory
instead of copying a set of files.
* Layout files should be able to set things like document font, language,
paper size and so on - if the layout writer thinks it is appropriate.
Today I can't just send someone a custom .layout, I have to tell them to
set palatino, margins, and so on too. And they have to do this on
every new document, if the custom document type don't match
document defaults otherwise used.
* References.
- Should be mostly automatic. The writer should not need to insert
a label in order to refer to section 3.6.1 - LyX should automatically
offer all numbered entities in the reference dialog, and generate
the latex label as needed. The explicit label is only needed in cases
like a reference to the fifth paragraph in a section - it _might_
end up on a different page than the section heading.
- Support package nameref so we can print the name of the
entity referenced too. Perhaps this needs explicit labels.
* A language called no spellcheck. Latex don't support it and won't
need to see it exported, but a spellchecking session should silently
skip over text in this language. Great for computer code and other
non-language content.
No more next next next next next next. . .
* hyperref support - mostly a document settings checkbox
to load the package. Nice for PDFs. It should be noted that
there are some limitations - marking something hyper-referenced
with a foreign language will crash latex for example. Good
hyperref support can automatically add the workaround:
\texorpdfstring{std.text with language}{pdfbookmarktext without}
* People on the user list seems to ask for the SIunits package
from time to time. Support might be in order.
* Cross references to other _unrelated_ documents (i.e. not part of the
same master-child document tree.) It is requested on the user
list, there is apparently a xr package supporting this.
See section 2.4 on page 67 of the other document. . .
* Now that LyX has a unicode main window and a unicode-supporting
UI, lets use the pretty unicode symbols available. Lets loose
ascii constructs like -- --- '' ``. Use the real symbols
instead so LyX don't look so awkward. Now, it still makes sense
to type -- to get the endash - but once completed, it should
transfrom into a real endash the same way as typing \alpha
does in math. Now, the UI might simply be a job for the translators,
but the main window shouldn't have ugly `` either.
* Lots of little things that increase latex compatibility and usefulness.
- Many a latex feature have useful optional
parameters not currently supported. Perhaps the short title
thing could adjust its name depending on what it is actually used
for. . .
- It'd be nice being able to override all counters in a supported
way - people ask about that all the time on the user list.
Right-click the number to get a counter override dialog? Or just
edit them in-place - with section numbers/enumeration numbers
becoming editable entities?
- ability to change stuff in the middle of a document. Perhaps
I want different bullets or page layout in part II? Or in the
appendix? Or one particular list with different bullets?
* user defined textstyles and layouts.
* Support documents with any mix of unicode characters,
at least if the users have
Re: Commit Rules Post-1.5.0
That's all for now. The rest of my time will probably go to 1.5.x. And as one can see from the immediate opening of the branch (as opposed to the agreement to branch only after 1.5.1 and fix a big bunch of the long standing bugs before) you will probably not get much help on that branch, although that would definitely be needed. My condolences. there is still possibility to lock 1.6svn and merge 1.5.1. there after releasing it. pavel
Re: Commit Rules Post-1.5.0
On Thu, 26 Jul 2007 09:34:45 +0200 Georg Baum [EMAIL PROTECTED] wrote: Jürgen Spitzmüller wrote: That's all for now. The rest of my time will probably go to 1.5.x. And as one can see from the immediate opening of the branch (as opposed to the agreement to branch only after 1.5.1 and fix a big bunch of the long standing bugs before) you will probably not get much help on that branch, although that would definitely be needed. My condolences. The good news is that José is away for the coming two weeks... and his OK is needed for 1.6. So Jürgen, be quick ;-)) What about branching 1.5.1 off 1.6 first thing in Bromarv? - Martin
Re: Commit Rules Post-1.5.0
On Thu, 2007-07-26 at 14:53 +0200, Helge Hafting wrote: * People on the user list seems to ask for the SIunits package from time to time. Support might be in order. +1 !!! I currently have 46 macros at the top of my thesis to nicely display the various units in use, with proper squaring, cubing etc. Have fun, Darren
Re: Commit Rules Post-1.5.0
Jürgen Spitzmüller wrote: That's all for now. The rest of my time will probably go to 1.5.x. And as one can see from the immediate opening of the branch (as opposed to the agreement to branch only after 1.5.1 and fix a big bunch of the long standing bugs before) you will probably not get much help on that branch, although that would definitely be needed. My condolences. Georg
Re: Commit Rules Post-1.5.0
Maybe not _all_ are badly missed, but here is a wishlist with my wishes as well as stuff from the user's list: Did you have a look at http://wiki.lyx.org/LyX/FeaturePoll ? Maybe we can put these stuff over there, and let the users decide what are the most wanted. Bo
Re: Commit Rules Post-1.5.0
On Thu, Jul 26, 2007 at 07:18:57AM +0200, Jürgen Spitzmüller wrote: > Furthermore, I'd like to support Richard's idea of finishing the character > style implementation. (Yay) john
Re: Commit Rules Post-1.5.0
On Wed, Jul 25, 2007 at 05:11:39PM +0100, José Matos wrote: > On Wednesday 25 July 2007 16:13:03 Bo Peng wrote: > > > For 1.5.x, you'll need my OK. > > > > For 1.6.x, the usual review process applies. > > > > Bo > > I would like to see some kind of plan, nothing too formal but at the same > time > a general idea where the current development stage is leading us. > > I would like that each developer answered three questions: > > Where do you think that LyX needs more attention? Quality assurance. There is messy code that should be cleaned up, half-baked features that should be full-baked, and temptations to add new features that should be resisted -- or at least carefully thought through. > What feature do you think that lyx is missing badly? The beamer layout requires too much ERT and non-intuitive tweaking. Perhaps something can be done about it in the frame of short title / optional argument. My dream is to have a LyX-beamer that is compatitive also in usability with ppt. > Where do you intend to work during this development cycle? Small things only...
Re: Commit Rules Post-1.5.0
Helge Hafting wrote:
* Layout files should be able to set things like document font, language,
paper size and so on - if the layout writer thinks it is appropriate.
Today I can't just send someone a custom .layout, I have to tell
them to
set "palatino", margins, and so on too. And they have to do this on
every new document, if the custom document type don't match
document defaults otherwise used.
Please post an enhancement request about this so it doesn't get lost.
* References.
- Should be mostly automatic. The writer should not need to insert
a label in order to refer to section 3.6.1 - LyX should automatically
offer all numbered entities in the reference dialog, and generate
the latex label as needed. The explicit label is only needed in cases
like a reference to the fifth paragraph in a section - it _might_
end up on a different page than the section heading.
This would be nice, indeed.
- Support package nameref so we can print the name of the
entity referenced too. Perhaps this needs explicit labels.
http://bugzilla.lyx.org/show_bug.cgi?id=3221
* hyperref support - mostly a document settings checkbox
to load the package. Nice for PDFs. It should be noted that
there are some limitations - marking something hyper-referenced
with a foreign language will crash latex for example. Good
hyperref support can automatically add the workaround:
\texorpdfstring{std.text with language}{pdfbookmarktext without}
http://bugzilla.lyx.org/show_bug.cgi?id=3482, mostly. I hope to get to
some of this, but it'd be a good project for someone trying to learn the
code. It's not hugely difficult, I don't think, but it will have a lot
of moving parts.
* user defined textstyles and layouts.
This is on the way, at least to a significant extent.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Commit Rules Post-1.5.0
And as one can see from the immediate opening of the branch (as opposed to the agreement to branch only after 1.5.1 and fix a big bunch of the long standing bugs before) you will probably not get much help on that branch, although that would definitely be needed. My condolences. Although I am eager to implement those 'new' and 'great' features, I fully agree with you on this and I guess Jose can order a feature freeze on trunk. It is already reported that middle-button paste is broken (so I am fixing it), and there should be many more reports after 1.5.0 is delivered. Bo
Re: Commit Rules Post-1.5.0
> * hyperref support - mostly a document settings checkbox
> to load the package. Nice for PDFs. It should be noted that
> there are some limitations - marking something hyper-referenced
> with a foreign language will crash latex for example. Good
> hyperref support can automatically add the workaround:
> \texorpdfstring{std.text with language}{pdfbookmarktext without}
please can you add all comments wrt hyperref to
http://bugzilla.lyx.org/show_bug.cgi?id=3527
?
> People on the user list seems to ask for the SIunits package
is it in bugz ?
pavel
Re: Commit Rules Post-1.5.0
José Matos wrote:
On Wednesday 25 July 2007 16:13:03 Bo Peng wrote:
For 1.5.x, you'll need my OK.
For 1.6.x, the usual review process applies.
Bo
I would like to see some kind of plan, nothing too formal but at the same time
a general idea where the current development stage is leading us.
I would like that each developer answered three questions:
Where do you think that LyX needs more attention?
* startup speed
* rendering/scrolling speed
What feature do you think that lyx is missing badly?
Maybe not _all_ are badly missed, but here is a wishlist with my
wishes as well as stuff from the user's list:
* dialogbox-less search/replace. Could be as simple as
docking the existing dialog and adjusting its layout for
such use. No more "word found underneath the search dialog!"
Ideally, some kind of solution using the minibuffer area, that goes away
whenever the minibuffer gets used for something else. This way, no need
to even _dismiss_ the search dialog.
* Perhaps boxless spellcheck, although that dialog is bigger. No more
moving the dialog to see the context for the mis-spelled word.
* Inset that prints the lyx file name (and optionally the path).
Often asked about on the user list. Nice for "our ref:"
Latex \jobname isn't up to this due to temp directories and the .lyx
extension. (Or possibly .tar.gz extension, see the next point.)
* Ability to wrap up a master document with child documents,
illustrations and everything in a .tar.gz file that LyX supports
directly.
Shouldn't be that hard - unpack the .tar.gz in the temp directory
instead of copying a set of files.
* Layout files should be able to set things like document font, language,
paper size and so on - if the layout writer thinks it is appropriate.
Today I can't just send someone a custom .layout, I have to tell them to
set "palatino", margins, and so on too. And they have to do this on
every new document, if the custom document type don't match
document defaults otherwise used.
* References.
- Should be mostly automatic. The writer should not need to insert
a label in order to refer to section 3.6.1 - LyX should automatically
offer all numbered entities in the reference dialog, and generate
the latex label as needed. The explicit label is only needed in cases
like a reference to the fifth paragraph in a section - it _might_
end up on a different page than the section heading.
- Support package nameref so we can print the name of the
entity referenced too. Perhaps this needs explicit labels.
* A language called "no spellcheck". Latex don't support it and won't
need to see it exported, but a spellchecking session should silently
skip over text in this language. Great for computer code and other
non-language content.
No more "next next next next next next. . ."
* hyperref support - mostly a document settings checkbox
to load the package. Nice for PDFs. It should be noted that
there are some limitations - marking something hyper-referenced
with a foreign language will crash latex for example. Good
hyperref support can automatically add the workaround:
\texorpdfstring{std.text with language}{pdfbookmarktext without}
* People on the user list seems to ask for the SIunits package
from time to time. Support might be in order.
* Cross references to other _unrelated_ documents (i.e. not part of the
same master-child document tree.) It is requested on the user
list, there is apparently a "xr" package supporting this.
"See section 2.4 on page 67 of the other document. . ."
* Now that LyX has a unicode main window and a unicode-supporting
UI, lets use the pretty unicode symbols available. Lets loose
ascii constructs like -- --- << >> '' ``. Use the real symbols
instead so LyX don't look so awkward. Now, it still makes sense
to type -- to get the endash - but once completed, it should
transfrom into a real endash the same way as typing \alpha
does in math. Now, the UI might simply be a job for the translators,
but the main window shouldn't have ugly `` either.
* Lots of little things that increase latex compatibility and usefulness.
- Many a latex feature have useful optional
parameters not currently supported. Perhaps the short title
thing could adjust its name depending on what it is actually used
for. . .
- It'd be nice being able to override all counters in a supported
way - people ask about that all the time on the user list.
Right-click the number to get a counter override dialog? Or just
edit them in-place - with section numbers/enumeration numbers
becoming editable entities?
- ability to change stuff in the middle of a document. Perhaps
I want different bullets or page layout in part II? Or in the
appendix? Or one particular list with different bullets?
* user defined textstyles and layouts.
* Support documents with any mix of unicode characters,
at least if
Re: Commit Rules Post-1.5.0
> > That's all for now. The rest of my time will probably go to 1.5.x. > > And as one can see from the immediate opening of the branch (as opposed to > the agreement to branch only after 1.5.1 and fix a big bunch of the long > standing bugs before) you will probably not get much help on that branch, > although that would definitely be needed. My condolences. there is still possibility to lock 1.6svn and merge 1.5.1. there after releasing it. pavel
Re: Commit Rules Post-1.5.0
On Thu, 26 Jul 2007 09:34:45 +0200 Georg Baum <[EMAIL PROTECTED]> wrote: > Jürgen Spitzmüller wrote: > > > That's all for now. The rest of my time will probably go to 1.5.x. > > And as one can see from the immediate opening of the branch (as opposed to > the agreement to branch only after 1.5.1 and fix a big bunch of the long > standing bugs before) you will probably not get much help on that branch, > although that would definitely be needed. My condolences. The good news is that José is away for the coming two weeks... and his OK is needed for 1.6. So Jürgen, be quick ;-)) What about branching 1.5.1 off 1.6 first thing in Bromarv? - Martin
Re: Commit Rules Post-1.5.0
On Thu, 2007-07-26 at 14:53 +0200, Helge Hafting wrote: > * People on the user list seems to ask for the SIunits package >from time to time. Support might be in order. +1 !!! I currently have 46 macros at the top of my thesis to nicely display the various units in use, with proper squaring, cubing etc. Have fun, Darren
Re: Commit Rules Post-1.5.0
Jürgen Spitzmüller wrote: > That's all for now. The rest of my time will probably go to 1.5.x. And as one can see from the immediate opening of the branch (as opposed to the agreement to branch only after 1.5.1 and fix a big bunch of the long standing bugs before) you will probably not get much help on that branch, although that would definitely be needed. My condolences. Georg
Re: Commit Rules Post-1.5.0
Maybe not _all_ are badly missed, but here is a wishlist with my wishes as well as stuff from the user's list: Did you have a look at http://wiki.lyx.org/LyX/FeaturePoll ? Maybe we can put these stuff over there, and let the users decide what are the most wanted. Bo
Re: Commit Rules Post-1.5.0
Richard Heck wrote: Now that 1.5.0 is branched, I take it that the trunk will be open for commits again shortly. What are the commit rules at that time? That is: Do we need agreement from someone else to commit? (That doesn't seem a bad idea.) Who will be in charge, in the sense that Jose' has been in charge recently? I know Jurgen is handling 1.5.x henceforth. For 1.5.x, you'll need my OK. Jürgen
Re: Commit Rules Post-1.5.0
For 1.5.x, you'll need my OK. For 1.6.x, the usual review process applies. Bo
Re: Commit Rules Post-1.5.0
On Wednesday 25 July 2007 16:13:03 Bo Peng wrote: For 1.5.x, you'll need my OK. For 1.6.x, the usual review process applies. Bo I would like to see some kind of plan, nothing too formal but at the same time a general idea where the current development stage is leading us. I would like that each developer answered three questions: Where do you think that LyX needs more attention? What feature do you think that lyx is missing badly? Where do you intend to work during this development cycle? I would like to have a wiki page with majors areas of development, and where do they stand in completion. The advantage of this system is that to release the first alpha we have a good idea what needs to be done, and for the beta stage we know which are the major features that needs to be finished. The second reason is that since the other developers know what is going on, even if they took a break for a while, it will be easier to coordinate the work. This is more or less what I had in mind for post-1.5.0. Feedback is welcome. :-) -- José Abílio
Re: Commit Rules Post-1.5.0
Where do you think that LyX needs more attention? File exchangability!!! 1. I am working on an embed file feature so that one can embed figures, listings etc to a .lyx file so that one can open a lyx file with everything in it directly. 2. I would like to have direct ODF (or word) export after our XML transition. Of course, this will encourage us to design a file format that is as close to ODF as possible. Keyboard shortcut etc. 1. It is difficult to find out the shortcuts used and define a new one. I would like to have to a shortcut window that allow easy display/change of shortcuts. This is available to almost all programs that have shortcuts. 2. Based on this, we can think of something like abrreviation/auto-compeletion. Layout overhaul: 1. embedding layout? 2. modualized layouts? 3. layout edit dialog? What feature do you think that lyx is missing badly? See my answer to 1. Where do you intend to work during this development cycle? I am working on the embedding feature. I am not sure if I have time/knowledge for XML. I might work on shortcuts. Bo
Re: Commit Rules Post-1.5.0
On Wed, Jul 25, 2007 at 05:11:39PM +0100, José Matos wrote: On Wednesday 25 July 2007 16:13:03 Bo Peng wrote: For 1.5.x, you'll need my OK. For 1.6.x, the usual review process applies. Bo I would like to see some kind of plan, nothing too formal but at the same time a general idea where the current development stage is leading us. XML file format and whatever appears as road kill in the mean time. But if XML is stabilizing we should aim for a 1.6 release. I would like that each developer answered three questions: Where do you think that LyX needs more attention? Current MVC architecture is too inflexible. Adding new dialogs is a pain. Parameter passing is a pain. Building is too slow. Editing speed in general. What feature do you think that lyx is missing badly? In the long run OpenOffice import/export (even non-perfect) Where do you intend to work during this development cycle? In the unlikely case that I find more time then needed for catching up with email: The points mentioned above under more attention needed Andre'
Re: Commit Rules Post-1.5.0
Bo Peng wrote: Where do you think that LyX needs more attention? 2. I would like to have direct ODF (or word) export after our XML transition. Of course, this will encourage us to design a file format that is as close to ODF as possible. To what extent does oolatex not do this? Granted, it could work better. 1. It is difficult to find out the shortcuts used and define a new one. I would like to have to a shortcut window that allow easy display/change of shortcuts. This is available to almost all programs that have shortcuts. Could possibly be borrowed from KDE apps, with appropriate adjustments. Layout overhaul: 1. embedding layout? 2. modualized layouts? These are orthogonal, yes? In any event, (1) would be easy to implement if we had (i) my modular stuff, which is almost working, and (ii) a layout pane similar to the preamble pane where you could enter layout info on the fly. Embedding would then be a simple matter of dumping all the layout info into that pane---I mean, that's how it would seem to the user. 3. layout edit dialog? This would rock. I've thought about it a bit, and surely it can't be that hard. The backend essentially exists. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Commit Rules Post-1.5.0
Where do you think that LyX needs more attention? 2. I would like to have direct ODF (or word) export after our XML transition. Of course, this will encourage us to design a file format that is as close to ODF as possible. To what extent does oolatex not do this? Granted, it could work better. I have never make oolatex working. Actually, it worked once a few years ago but the whole layout was messed up. Could possibly be borrowed from KDE apps, with appropriate adjustments. Yes. Layout overhaul: 1. embedding layout? 2. modualized layouts? These are orthogonal, yes? In any event, (1) would be easy to implement if we had (i) my modular stuff, which is almost working, and (ii) a layout pane similar to the preamble pane where you could enter layout info on the fly. Embedding would then be a simple matter of dumping all the layout info into that pane---I mean, that's how it would seem to the user. So they are in your hand now. :-) 3. layout edit dialog? This would rock. I've thought about it a bit, and surely it can't be that hard. The backend essentially exists. This as well. :-) Bo
Re: Commit Rules Post-1.5.0
José Matos wrote: What feature do you think that lyx is missing badly? Inline spell checking. Joost
Re: Commit Rules Post-1.5.0
Where do you think that LyX needs more attention? * rendering speed * proper uniform scrolling What feature do you think that lyx is missing badly? * proper math macros Where do you intend to work during this development cycle? I plan to look into the speed and scrolling issue soon. I have some ideas how to make the scrolling (mostly) uniform and remove this hack with the average paragraph height to a large extent. I use my macro patch all day, so stability is quite good now. The next step for me is to improve the user interface to edit macro definitions (i.e. the parameters). I know more or less how it should look like and how to do it. Just a matter of sitting down a weekend to do it. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: Commit Rules Post-1.5.0
José Matos wrote: I would like that each developer answered three questions: Where do you think that LyX needs more attention? What feature do you think that lyx is missing badly? The truth is, LyX is great as it is! ;) However, I would be happy to see the following things, too: * Proper search and replace. Tommaso's ideas sound really great (unfortunately I wasn't able to compile with his proof-of-concept patches, yet). I would love to see this kind of thing go in. If possible, once we're at it, there are also some small, long-standing, find-and-replace issues which should be solved: - Bug 1262 Search Replace: wrap option - Bug 2548 Wishlist: limit find/replace to selected text - Bug 2674 Find and replace should restore initial cursor position - Bug 3696 Find/replace to preserve capitalisation - Bug 3999 Find dialog text is not selected Also, it seems to me that with proper design, the same backend used for the find/replace could also be used for addressing this: - Bug 3713 Keyword completion feature of lyx which I would also be very happy to see (this is what I actually set out to solve when I first joined the list, but then I got waylaid by the RTL stuff...). * Export to other formats --- I would like to be able to write a document in LyX, and *easily* export it to either LaTeX or HTML or DocBook (OpenOffice? Word?...). Today it still doesn't work seamlessly, especially if Hebrew is involved... Hopefully, the XML format will simplify this, perhaps we could even use XSL to transform the LyX document itself directly to HTML or DocBook? Where do you intend to work during this development cycle? 1. Still working on RTL/Bidi stuff: - Visual cursor movement - general RTL maintenance, continuing to solve little issues that still exist 2. Simplifying multilingual support: as much as possible, make the following issues work out of the box for as many languages as the user would like (currently, these require some setting up on the part of the user, and/or are limited to only two languages): - Keymaps - keybinding for switching languages Dov
Re: Commit Rules Post-1.5.0
José Matos wrote: I would like that each developer answered three questions: Where do you think that LyX needs more attention? In the stable series ;-) What feature do you think that lyx is missing badly? Proper character styles implementation and handling of more complex constructs (optargs handling is suboptimal, multiple mandatory arguments are not handled, a general environment inset would be cool). Then, tabular support is way behind LaTeX's possibilities. Where do you intend to work during this development cycle? I have a half-finished patch that switches from aiksaurus to MyThes (OpenOffice's thesaurus), allowing for more languages than English. I'd like to finish this as soon as time permits. Furthermore, I'd like to support Richard's idea of finishing the character style implementation. Then, there are several small things that might be addressed during that cycle, such as the implementation of a subfigure inset and the switch from subfigure to subfig. That's all for now. The rest of my time will probably go to 1.5.x. Jürgen
Re: Commit Rules Post-1.5.0
Richard Heck wrote: > Now that 1.5.0 is branched, I take it that the trunk will be open for > commits again shortly. What are the commit rules at that time? That is: > Do we need agreement from someone else to commit? (That doesn't seem a > bad idea.) Who will be "in charge", in the sense that Jose' has been in > charge recently? I know J"urgen is handling 1.5.x henceforth. For 1.5.x, you'll need my OK. Jürgen
Re: Commit Rules Post-1.5.0
For 1.5.x, you'll need my OK. For 1.6.x, the usual review process applies. Bo
Re: Commit Rules Post-1.5.0
On Wednesday 25 July 2007 16:13:03 Bo Peng wrote: > > For 1.5.x, you'll need my OK. > > For 1.6.x, the usual review process applies. > > Bo I would like to see some kind of plan, nothing too formal but at the same time a general idea where the current development stage is leading us. I would like that each developer answered three questions: Where do you think that LyX needs more attention? What feature do you think that lyx is missing badly? Where do you intend to work during this development cycle? I would like to have a wiki page with majors areas of development, and where do they stand in completion. The advantage of this system is that to release the first alpha we have a good idea what needs to be done, and for the beta stage we know which are the major features that needs to be finished. The second reason is that since the other developers know what is going on, even if they took a break for a while, it will be easier to coordinate the work. This is more or less what I had in mind for post-1.5.0. Feedback is welcome. :-) -- José Abílio
Re: Commit Rules Post-1.5.0
Where do you think that LyX needs more attention? File exchangability!!! 1. I am working on an embed file feature so that one can embed figures, listings etc to a .lyx file so that one can open a lyx file with everything in it directly. 2. I would like to have direct ODF (or word) export after our XML transition. Of course, this will encourage us to design a file format that is as close to ODF as possible. Keyboard shortcut etc. 1. It is difficult to find out the shortcuts used and define a new one. I would like to have to a shortcut window that allow easy display/change of shortcuts. This is available to almost all programs that have shortcuts. 2. Based on this, we can think of something like abrreviation/auto-compeletion. Layout overhaul: 1. embedding layout? 2. modualized layouts? 3. layout edit dialog? What feature do you think that lyx is missing badly? See my answer to 1. Where do you intend to work during this development cycle? I am working on the embedding feature. I am not sure if I have time/knowledge for XML. I might work on shortcuts. Bo
Re: Commit Rules Post-1.5.0
On Wed, Jul 25, 2007 at 05:11:39PM +0100, José Matos wrote: > On Wednesday 25 July 2007 16:13:03 Bo Peng wrote: > > > For 1.5.x, you'll need my OK. > > > > For 1.6.x, the usual review process applies. > > > > Bo > > I would like to see some kind of plan, nothing too formal but at the > same time a general idea where the current development stage is > leading us. XML file format and whatever appears as road kill in the mean time. But if XML is stabilizing we should aim for a 1.6 release. > I would like that each developer answered three questions: > > Where do you think that LyX needs more attention? Current MVC architecture is too inflexible. Adding new dialogs is a pain. Parameter passing is a pain. Building is too slow. Editing speed in general. > What feature do you think that lyx is missing badly? In the long run OpenOffice import/export (even non-perfect) > Where do you intend to work during this development cycle? In the unlikely case that I find more time then needed for catching up with email: The points mentioned above under "more attention needed" Andre'
Re: Commit Rules Post-1.5.0
Bo Peng wrote: Where do you think that LyX needs more attention? 2. I would like to have direct ODF (or word) export after our XML transition. Of course, this will encourage us to design a file format that is as close to ODF as possible. To what extent does oolatex not do this? Granted, it could work better. 1. It is difficult to find out the shortcuts used and define a new one. I would like to have to a shortcut window that allow easy display/change of shortcuts. This is available to almost all programs that have shortcuts. Could possibly be borrowed from KDE apps, with appropriate adjustments. Layout overhaul: 1. embedding layout? 2. modualized layouts? These are orthogonal, yes? In any event, (1) would be easy to implement if we had (i) my modular stuff, which is almost working, and (ii) a "layout" pane similar to the preamble pane where you could enter layout info on the fly. Embedding would then be a simple matter of dumping all the layout info into that pane---I mean, that's how it would seem to the user. 3. layout edit dialog? This would rock. I've thought about it a bit, and surely it can't be that hard. The backend essentially exists. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Commit Rules Post-1.5.0
>> Where do you think that LyX needs more attention? > 2. I would like to have direct ODF (or word) export after our XML > transition. Of course, this will encourage us to design a file format > that is as close to ODF as possible. To what extent does oolatex not do this? Granted, it could work better. I have never make oolatex working. Actually, it worked once a few years ago but the whole layout was messed up. Could possibly be borrowed from KDE apps, with appropriate adjustments. Yes. > Layout overhaul: > 1. embedding layout? > 2. modualized layouts? These are orthogonal, yes? In any event, (1) would be easy to implement if we had (i) my modular stuff, which is almost working, and (ii) a "layout" pane similar to the preamble pane where you could enter layout info on the fly. Embedding would then be a simple matter of dumping all the layout info into that pane---I mean, that's how it would seem to the user. So they are in your hand now. :-) > 3. layout edit dialog? This would rock. I've thought about it a bit, and surely it can't be that hard. The backend essentially exists. This as well. :-) Bo
Re: Commit Rules Post-1.5.0
José Matos wrote: What feature do you think that lyx is missing badly? Inline spell checking. Joost
Re: Commit Rules Post-1.5.0
Where do you think that LyX needs more attention? * rendering speed * proper uniform scrolling What feature do you think that lyx is missing badly? * proper math macros Where do you intend to work during this development cycle? I plan to look into the speed and scrolling issue soon. I have some ideas how to make the scrolling (mostly) uniform and remove this hack with the average paragraph height to a large extent. I use my macro patch all day, so stability is quite good now. The next step for me is to improve the user interface to edit macro definitions (i.e. the parameters). I know more or less how it should look like and how to do it. Just a matter of sitting down a weekend to do it. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: Commit Rules Post-1.5.0
José Matos wrote: I would like that each developer answered three questions: Where do you think that LyX needs more attention? What feature do you think that lyx is missing badly? The truth is, LyX is great as it is! ;) However, I would be happy to see the following things, too: * Proper search and replace. Tommaso's ideas sound really great (unfortunately I wasn't able to compile with his proof-of-concept patches, yet). I would love to see this kind of thing go in. If possible, once we're at it, there are also some small, long-standing, find-and-replace issues which should be solved: - Bug 1262 Search & Replace: "wrap" option - Bug 2548 Wishlist: limit find/replace to selected text - Bug 2674 Find and replace should restore initial cursor position - Bug 3696 Find/replace to preserve capitalisation - Bug 3999 Find dialog text is not selected Also, it seems to me that with proper design, the same backend used for the find/replace could also be used for addressing this: - Bug 3713 Keyword completion feature of lyx which I would also be very happy to see (this is what I actually set out to solve when I first joined the list, but then I got waylaid by the RTL stuff...). * Export to other formats --- I would like to be able to write a document in LyX, and *easily* export it to either LaTeX or HTML or DocBook (OpenOffice? Word?...). Today it still doesn't work seamlessly, especially if Hebrew is involved... Hopefully, the XML format will simplify this, perhaps we could even use XSL to transform the LyX document itself directly to HTML or DocBook? Where do you intend to work during this development cycle? 1. Still working on RTL/Bidi stuff: - Visual cursor movement - general RTL maintenance, continuing to solve little issues that still exist 2. Simplifying multilingual support: as much as possible, make the following issues work "out of the box" for as many languages as the user would like (currently, these require some setting up on the part of the user, and/or are limited to only two languages): - Keymaps - keybinding for switching languages Dov
Re: Commit Rules Post-1.5.0
José Matos wrote: > I would like that each developer answered three questions: > > Where do you think that LyX needs more attention? In the stable series ;-) > What feature do you think that lyx is missing badly? Proper character styles implementation and handling of more complex constructs (optargs handling is suboptimal, multiple mandatory arguments are not handled, a general environment inset would be cool). Then, tabular support is way behind LaTeX's possibilities. > Where do you intend to work during this development cycle? I have a half-finished patch that switches from aiksaurus to MyThes (OpenOffice's thesaurus), allowing for more languages than English. I'd like to finish this as soon as time permits. Furthermore, I'd like to support Richard's idea of finishing the character style implementation. Then, there are several small things that might be addressed during that cycle, such as the implementation of a subfigure inset and the switch from subfigure to subfig. That's all for now. The rest of my time will probably go to 1.5.x. Jürgen
