/bottom rules heavier for booktab
This gives a better idea of the TeX output, even though the
width are
not correct.
Riki,
Can I backport to 2.3.2 (along with fixup 84328c85388cc)?
OK.
Done at d371a43.
JMarc
On 09/09/2018 02:15 PM, Jean-Marc Lasgouttes wrote:
> Le 20/07/2018 à 00:30, Jean-Marc Lasgouttes a écrit :
>> commit 8651cd89f6cc16c4e17f197fbbcfe979d09f01c9
>> Author: Jean-Marc Lasgouttes
>> Date: Fri Jul 20 00:26:41 2018 +0200
>>
>> Draw top
On 25/07/2018 12:23, Jean-Marc Lasgouttes wrote:
Le 25/07/2018 à 11:44, Daniel a écrit :
ps. A further but more complicated version of (1) is to simulate a
smaller thickness by using a 2px rule that consist of a black and half
transparent black line.
Well, typically, I do not intend to do com
On 25/07/2018 12:30, Jean-Marc Lasgouttes wrote:
Le 25/07/2018 à 11:40, Daniel a écrit :
Even if you know what you are doing it can be helpful to have visual
guides. I am sure you could do (or maybe you do) programming in a
plain text editor. Still many people prefer editors that support
highl
n favor of bolder rules grows.
JMarc
Le 25/07/2018 à 11:44, Daniel a écrit :
ps. A further but more complicated version of (1) is to simulate a
smaller thickness by using a 2px rule that consist of a black and half
transparent black line.
Well, typically, I do not intend to do complicate clever tricks...
People will probably com
hat do you call first and second? I (3), it looks like top/bottom,
but here ??
Yes, I mean top and bottom. The idea is: Having a slightly thicker
top/bottom rule than the head separation rule is more of an eye candy.
It would not hinder readability if all thick rules (top, bottom, header
separato
, it looks like top/bottom, but
here ??
Yes, I mean top and bottom. The idea is: Having a slightly thicker
top/bottom rule than the head separation rule is more of an eye candy.
It would not hinder readability if all thick rules (top, bottom, header
separator) had the same thickness (2px).
Le 25/07/2018 à 09:08, Daniel a écrit :
Thanks. I think it looks good. I prefer it.
So we disagree ;)
Attached is a comparison with a PDF output (one with, roughly, the same
table size and one with, roughly, the same font size).
Note that when the table is larger in pdf, the rulles are thic
On 24/07/2018 20:49, Jean-Marc Lasgouttes wrote:
Le 24/07/2018 à 18:58, Daniel a écrit :
Send an enjoyable lyx file...
If I understood you correctly you offer to create a screenshot for me.
Attached is the standard example from booktabs package (probably it
will become more vegetarian friend
Le 24/07/2018 à 18:58, Daniel a écrit :
Send an enjoyable lyx file...
If I understood you correctly you offer to create a screenshot for me.
Attached is the standard example from booktabs package (probably it will
become more vegetarian friendly in a future version).
Here is a screenshot at
On 24/07/2018 17:47, Jean-Marc Lasgouttes wrote:
Le 24/07/2018 à 17:33, Daniel a écrit :
I did it now and don't like much. It is in though for your enjoyment.
Damn. No enjoyment for me at the moment since I cannot complile LyX.
But if it lookes like with CSS (attached), I would have indeed en
Le 24/07/2018 à 17:33, Daniel a écrit :
I did it now and don't like much. It is in though for your enjoyment.
Damn. No enjoyment for me at the moment since I cannot complile LyX. But
if it lookes like with CSS (attached), I would have indeed enjoyed it.
Send an enjoyable lyx file...
JMarc
On 24/07/2018 00:14, Jean-Marc Lasgouttes wrote:
Le 23/07/2018 à 22:46, Daniel a écrit :
On 23/07/2018 20:40, Jean-Marc Lasgouttes wrote:
Le 23/07/2018 à 20:26, Daniel a écrit :
With 3 pixels for heavy, I will have to take the width into account
in table cells height computation, while I have
Am Dienstag, den 24.07.2018, 08:28 +0200 schrieb Jean-Marc Lasgouttes:
> Le 24/07/2018 à 01:56, Joel Kulesza a écrit :
> > If something is not yet correct, I propose to revert the whole
> > thing
> > and go back to the time when nobody complained ;)
> >
> >
> > I hope this doesn't occur b
Le 24/07/2018 à 01:56, Joel Kulesza a écrit :
If something is not yet correct, I propose to revert the whole thing
and go back to the time when nobody complained ;)
I hope this doesn't occur but rather the initial salvo of changes are kept.
I will wait to see what the general wisdom i
On Mon, Jul 23, 2018 at 4:14 PM, Jean-Marc Lasgouttes
wrote:
> Le 23/07/2018 à 22:46, Daniel a écrit :
>
>> On 23/07/2018 20:40, Jean-Marc Lasgouttes wrote:
>>
>>> Le 23/07/2018 à 20:26, Daniel a écrit :
>>>
With 3 pixels for heavy, I will have to take the width into account in
> table c
Le 23/07/2018 à 22:46, Daniel a écrit :
On 23/07/2018 20:40, Jean-Marc Lasgouttes wrote:
Le 23/07/2018 à 20:26, Daniel a écrit :
With 3 pixels for heavy, I will have to take the width into account
in table cells height computation, while I have conveniently decided
to ignore it for now :)
Wh
On 23/07/2018 20:40, Jean-Marc Lasgouttes wrote:
Le 23/07/2018 à 20:26, Daniel a écrit :
With 3 pixels for heavy, I will have to take the width into account
in table cells height computation, while I have conveniently decided
to ignore it for now :)
Why is it that you would have to take it in
Le 23/07/2018 à 20:26, Daniel a écrit :
With 3 pixels for heavy, I will have to take the width into account in
table cells height computation, while I have conveniently decided to
ignore it for now :)
Why is it that you would have to take it into account? So far zooming
keeps the cell padding
On 23/07/2018 15:09, Jean-Marc Lasgouttes wrote:
Le 23/07/2018 à 10:16, Daniel a écrit :
Okay, got it. And using 3 pixel for heavy, 1 pixel for thin, and 2
pixel for medium doesn't look good? A reason to even trade-off some of
the good looks is that having only partly a distinction between
dif
Le 23/07/2018 à 15:19, Joel Kulesza a écrit :
On Mon, Jul 23, 2018 at 7:09 AM, Jean-Marc Lasgouttes
mailto:lasgout...@lyx.org>> wrote:
I could set the width of cmidrule to 0, with would be the same as 1
for normal screens and a **barely visible one-real-pixel wide line
on Mac Retina
On Mon, Jul 23, 2018 at 7:09 AM, Jean-Marc Lasgouttes
wrote:
> I could set the width of cmidrule to 0, with would be the same as 1 for
> normal screens and a **barely visible one-real-pixel wide line on Mac
> Retina**.
Please don't do this.
Le 23/07/2018 à 10:16, Daniel a écrit :
Okay, got it. And using 3 pixel for heavy, 1 pixel for thin, and 2 pixel
for medium doesn't look good? A reason to even trade-off some of the
good looks is that having only partly a distinction between different
lines might be misleading.
With 3 pixels
On 22/07/2018 20:29, Jean-Marc Lasgouttes wrote:
Le 22/07/2018 à 18:59, Daniel a écrit :
But I am a bit lost. You state the widths above as em fractions but
say that the values are integers. Do you mean that the list of widths
widths above are as defined in the booktab package but you are using
Le 22/07/2018 à 18:59, Daniel a écrit :
But I am a bit lost. You state the widths above as em fractions but say
that the values are integers. Do you mean that the list of widths widths
above are as defined in the booktab package but you are using integer
values to set the line width in LyX?
T
On 21/07/2018 21:13, Jean-Marc Lasgouttes wrote:
Le 21/07/2018 à 19:50, Daniel a écrit :
The widths are:
heavy=0.008em
thin=0.05em
cmid=0.03em
If I do use these values, I can only see a difference between heavy
and thin beyond 180% zoom (at 100dpi) and the 3 width are different
only over 300%
On Thu, Jul 19, 2018 at 4:28 PM, Jean-Marc Lasgouttes
wrote:
>
> Please try it out. If people like it, it can be backported.
>
> JMarc
I tried this and though I didn't experiment extensively (or try to break
it), I really like it on its first impression. Good addition.
Thanks,
Joel
Le 21/07/2018 à 19:50, Daniel a écrit :
The widths are:
heavy=0.008em
thin=0.05em
cmid=0.03em
If I do use these values, I can only see a difference between heavy
and thin beyond 180% zoom (at 100dpi) and the 3 width are different
only over 300% zoom.
So I do not really see how I could differ
On 21/07/2018 19:08, Jean-Marc Lasgouttes wrote:
Le 21/07/2018 à 12:55, Daniel a écrit :
- a rule is thickest if and only if (it is the first or last) *and* it
stretches along the whole with of the table,
right?
No, I will fix it asap.
And from there, and maybe while you are at it, it might
Le 21/07/2018 à 12:55, Daniel a écrit :
- a rule is thickest if and only if (it is the first or last) *and* it
stretches along the whole with of the table,
right?
No, I will fix it asap.
And from there, and maybe while you are at it, it might not be far from
implementing the other line styl
On 20/07/2018 00:28, Jean-Marc Lasgouttes wrote:
Le 20/07/2018 à 00:30, Jean-Marc Lasgouttes a écrit :
commit 8651cd89f6cc16c4e17f197fbbcfe979d09f01c9
Author: Jean-Marc Lasgouttes
Date: Fri Jul 20 00:26:41 2018 +0200
Draw top/bottom rules heavier for booktab
This gives a better
Am Freitag, den 20.07.2018, 00:28 +0200 schrieb Jean-Marc Lasgouttes:
> Le 20/07/2018 à 00:30, Jean-Marc Lasgouttes a écrit :
> > commit 8651cd89f6cc16c4e17f197fbbcfe979d09f01c9
> > Author: Jean-Marc Lasgouttes
> > Date: Fri Jul 20 00:26:41 2018 +0200
> >
> >
Le 20/07/2018 à 00:30, Jean-Marc Lasgouttes a écrit :
commit 8651cd89f6cc16c4e17f197fbbcfe979d09f01c9
Author: Jean-Marc Lasgouttes
Date: Fri Jul 20 00:26:41 2018 +0200
Draw top/bottom rules heavier for booktab
This gives a better idea of the TeX output, even though the width
Le 30/05/2016 10:36, Andrew Parsloe a écrit :
LyX 2.2.0, windows 7.
When I change either horizontal or vertical alignment of a table by
means of the context menu > Settings, extra vertical rules are inserted
in a table. I've attached an example file. The table toolbar buttons
don&#
LyX 2.2.0, windows 7.
When I change either horizontal or vertical alignment of a table by
means of the context menu > Settings, extra vertical rules are inserted
in a table. I've attached an example file. The table toolbar buttons
don't seem to produce this effect. (In fact I c
Dear LyX developers,
during the LaTeX export, LyX adds to the preamble a number of required
"features" (package loading commands and auxiliary definitions) if the
function ``LaTeXFeatures::mustProvide(string const & name)`` return true.
I want to refine this test (part of bug #9637):
The font-e
On Tue, Sep 11, 2012 at 4:06 AM, Jean-Marc Lasgouttes
wrote:
> Le 11/09/2012 09:39, Scott Kostyshak a écrit :
>
>>> Yes.
>>
>>
>> Is that patch OK?
>
>
> Yes, sure.
It's in.
Thanks,
Scott
Le 11/09/2012 09:39, Scott Kostyshak a écrit :
Yes.
Is that patch OK?
Yes, sure.
JMarc
On Tue, Sep 11, 2012 at 3:29 AM, Jean-Marc Lasgouttes
wrote:
> Le 11/09/2012 09:15, Scott Kostyshak a écrit :
>
>> On Mon, Sep 10, 2012 at 5:01 PM, Jean-Marc Lasgouttes
>> wrote:
>>>
>>> Le 10/09/12 17:14, Stephan Witt a écrit :
>>>
With TAB instead of 8 spaces it works :)
>>>
>>>
>>>
>>> Is
Le 11/09/2012 09:15, Scott Kostyshak a écrit :
On Mon, Sep 10, 2012 at 5:01 PM, Jean-Marc Lasgouttes
wrote:
Le 10/09/12 17:14, Stephan Witt a écrit :
With TAB instead of 8 spaces it works :)
Is it better now?
Should autogen.sh abort if the make doesn't succeed?
Yes.
JMarc
a/autogen.sh b/autogen.sh
index a00eebe..b03318f 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -85,7 +85,10 @@ else
fi
echo "Building po/POTFILES.in..."
-make -s -f po/Rules-lyx srcdir=po top_srcdir=. po/POTFILES.in
+if (! make -s -f po/Rules-lyx srcdir=po top_srcdir=. po/POTFILES.
On Mon, Sep 10, 2012 at 5:01 PM, Jean-Marc Lasgouttes
wrote:
> Le 10/09/12 17:14, Stephan Witt a écrit :
>
>> With TAB instead of 8 spaces it works :)
>
>
> Is it better now?
Yes, it works for me now.
Thank you,
Scott
Le 10/09/12 17:14, Stephan Witt a écrit :
With TAB instead of 8 spaces it works :)
Is it better now?
JMarc
Date: Mon Sep 10 11:55:52 2012 +0200
Streamline a bit po/Rules-lyx
Make use of normal and automatic variables to avoid repetition. Things
could be made shorter by using the %_l10n.pot pattern (GNU make extension).
I can no longer build with autotools. cmake works fine. Is this
been updated.
> >>
> >> - Log -
> >>
> >> commit a57a2d9acfc2a36084d2f322f5089203ae89fc9e
> >> Author: Jean-Marc Lasgouttes
> >> Date: Mon Sep 10 11:55:52 2012 +0200
> >>
> >>Streamline a bit po/Rule
2d9acfc2a36084d2f322f5089203ae89fc9e
>> Author: Jean-Marc Lasgouttes
>> Date: Mon Sep 10 11:55:52 2012 +0200
>>
>>Streamline a bit po/Rules-lyx
>>
>>Make use of normal and automatic variables to avoid repetition. Things
>> could be made shorter by usin
Sep 10 11:55:52 2012 +0200
>
> Streamline a bit po/Rules-lyx
>
> Make use of normal and automatic variables to avoid repetition. Things
> could be made shorter by using the %_l10n.pot pattern (GNU make extension).
I can no longer build with autotools. cmake works fine. Is this just me?
Scott
Vincent van Ravesteijn wrote:
> I'm not yet sure whether we should make one document of both the
> Rules/Language Advice/Style and the implementation/design issues.
i would prefer one doc.
pavel
ut I hide it in the appendix for now among the
other stuff that need to find their way.
> as for structures i tried to collect some things fro maillist in
> http://wiki.lyx.org/Devel/Diagrams
> long time ago, but mostly outdated now i think.
I'm not yet sure whether we should ma
Stephan Witt wrote:
> > Maybe we can create another document on the design principles and
> > major structure in the LyX code. There are already some pieces, but we
> > have to get them up to date and to put them in one place.
> >
> > Comments ?
perhaps kill the old ascii file (or move it to atti
Am 27.10.2010 um 07:04 schrieb Vincent van Ravesteijn:
> Hi All,
>
> I converted the two files about Rules and Recommendation into a LyX
> document. You might want to have a look at it, and put your two cents
> in there about coding principle, style and so forth. It is still a bi
Hi All,
I converted the two files about Rules and Recommendation into a LyX
document. You might want to have a look at it, and put your two cents
in there about coding principle, style and so forth. It is still a bit
a mess, but I hope it will get better.
Everyone is invited to edit. Please turn
Jean-Marc LASGOUTTES wrote:
> This is already on branch and will change the situation only when
> building makefiles with automake 1.11 (would be nice as default). The
> result is much nice compilation messages.
>
> OK for branch?
Yes.
Jürgen
This is already on branch and will change the situation only when
building makefiles with automake 1.11 (would be nice as default). The
result is much nice compilation messages.
OK for branch?
JMarc
Index: src/frontends/qt4/Makefile.am
===
Jean-Marc Lasgouttes wrote:
rgheck writes:
LyX is currently listed as THE most popular download on
eeedownload.asus.com!!
Hmm, not anymore. And the number of downloads is 893... Still some work
to do before ruling the world.
Rabajoie!
rgheck writes:
> LyX is currently listed as THE most popular download on
> eeedownload.asus.com!!
Hmm, not anymore. And the number of downloads is 893... Still some work
to do before ruling the world.
JMarc
LyX is currently listed as THE most popular download on
eeedownload.asus.com!!
rh
On Tue, Apr 08, 2008 at 11:09:25PM +0200, Joost Verburg wrote:
> Andre Poenitz wrote:
>>> You informed be that files specific for a certain operating system (such
>>> as os_win*) can follow the standard conventions for this OS instead of
>>> the LyX conventions. It would be useful to put that in
Andre Poenitz wrote:
You informed be that files specific for a certain operating system (such as
os_win*) can follow the standard conventions for this OS instead of the LyX
conventions. It would be useful to put that in this file as well.
That's what I tried to say with:
+ Note: As an e
On Tue, Apr 08, 2008 at 10:54:04PM +0200, Joost Verburg wrote:
> Andre Poenitz wrote:
>> Somewhat less strong wording on "wrong" usage.
>> Add a comment on null pointers.
>> Remove outdated example.
>> Comments?
>
> You informed be that files specific for a certain operating system (such as
> os_w
Andre Poenitz wrote:
Somewhat less strong wording on "wrong" usage.
Add a comment on null pointers.
Remove outdated example.
Comments?
You informed be that files specific for a certain operating system (such
as os_win*) can follow the standard conventions for this OS instead of
the LyX conve
Somewhat less strong wording on "wrong" usage.
Add a comment on null pointers.
Remove outdated example.
Comments?
Andre'
Index: Rules
===
--- Rules (revision 24183)
+++ Rules (working cop
Andre Poenitz <[EMAIL PROTECTED]> writes:
> So reformulate "short"?
Thanks.
JMarc
On Sun, Sep 30, 2007 at 05:42:51PM +0200, Jean-Marc Lasgouttes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> > -We also require you to provide a ChangeLog entry with every patch, this
> > -describes shortly what the patch is doing. The ChangeLog entry follows
> > -this syntax:
> > +We als
Andre Poenitz <[EMAIL PROTECTED]> writes:
> -We also require you to provide a ChangeLog entry with every patch, this
> -describes shortly what the patch is doing. The ChangeLog entry follows
> -this syntax:
> +We also require you to provide a commit message entry with every patch,
> +this describe
Should be uncontroversial, but I'll wait for a nod.
I have a few more controversial ones up my sleeve...
Andre'
Index: Rules
===
--- Rules (revision 20603)
+++ Rules (working copy)
@@ -12,6 +12,7 @@
but still
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 i
on 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
pr
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
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
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
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
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 automati
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
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
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, c
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
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 h
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
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 ea
> * 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 t
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
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
> > 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 branc
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
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 h
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
(op
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 s
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 ha
José Matos wrote:
What feature do you think that lyx is missing badly?
Inline spell checking.
Joost
>> 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 be
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 coul
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
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
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 lik
For 1.5.x, you'll need my OK.
For 1.6.x, the usual review process applies.
Bo
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 char
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'
Andre Poenitz <[EMAIL PROTECTED]> writes:
| Index: Rules
| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/development/Code_rules/Rules,v
| retrieving revision 1.14
| diff -u -p -r1.14 Rules
| --- Rules 25 Sep 2002 14
1 - 100 of 106 matches
Mail list logo
