Peter Kümmel wrote:
feed_the_troll(Do we really wanna upgrade to version 3?) ;)
That's for you guys, the active developers, to decide. What I'm trying to
do here is to give you the freedom to make that decision.
Angus
Angus Leeming wrote:
Koji, could you grant LyX permission to license your contributions
under the Gnu General Public License version 2 *or later*.
That will give us the flexibility to upgrade the LyX licence to
version 3 of the GPL as and when it arrives.
Angus, there is no problem in doing
Angus Leeming wrote:
Peter Kümmel wrote:
Yes, I also don't like the hardcoding. The problem is that if we start
to drop events we have to differentiate between good and bad events, and
it is hard to find a solution for all cases. So it would be better not
to drop any key. But what is the
On Mon, 28 May 2007, Abdelrazak Younes wrote:
Lars Gullik Bjønnes wrote:
| | + ListingsParam(string const v, bool o, param_type t,
| | + string const i, docstring const h)
| | : value_(v), onoff_(o), type_(t), info_(i), hint_(h)
| |{}
| | - ///
| | +
On Friday 25 May 2007 15:57:28 José Matos wrote:
Hi,
are we ready for RC1, in the goals that I have stated to RC1 I had
proposed a week between beta 3 and release candidate 1 to avoid any error
that had evaded our search us before.
There are important patches that are being discussed
Committed. The same applies to 1.4.4. If somebody wants to check and
apply
Stefan
Am 28.05.2007 um 00:57 schrieb Stefan Schimanski:
Patch is attached to the bug: http://bugzilla.lyx.org/show_bug.cgi?
id=3310
Stefan
PGP.sig
Description: Signierter Teil der Nachricht
The source view is a drawer as well??? Does that really make sense? I
mean normally tex code is meant to be 80 chars wide and should be
shown like that.
Stefan
Author: spitz
Date: Mon May 28 09:17:47 2007
New Revision: 18537
URL: http://www.lyx.org/trac/changeset/18537
Log:
*
Uwe Stöhr wrote:
Probably \DEL (package ascii).
No, this produces a character similar to _ for me here.
Then your installation is probably wrong. Look here:
ftp://tug.ctan.org/pub/tex-archive/info/symbols/comprehensive/symbols-a4.pdf
(page 49)
Jürgen
José Matos wrote:
Jürgen what is your opinion on this?
Even if this will fall back on me (because this is something I'd really need),
I think this has to wait.
Jürgen
Stefan Schimanski wrote:
The source view is a drawer as well??? Does that really make sense? I
mean normally tex code is meant to be 80 chars wide and should be shown
like that.
What is the link between line width and the dialog being a drawer?
Can't a drawer be set at the bottom?
Abdel.
Am Sonntag, 27. Mai 2007 20:49 schrieb Uwe Stöhr:
I agree with Jürgen that the ordinary greek characters 0x0370..0x03ff
should not be added as math versions.
I don't know why everybody states this when I never wrote to do this.
I simply used the misunderstanding of Jürgen as a cause to
Abdelrazak Younes wrote:
Stefan Schimanski wrote:
The source view is a drawer as well??? Does that really make sense? I
mean normally tex code is meant to be 80 chars wide and should be
shown like that.
What is the link between line width and the dialog being a drawer?
Can't a drawer be set
Abdelrazak Younes wrote:
The source view is a drawer as well??? Does that really make sense? I
mean normally tex code is meant to be 80 chars wide and should be shown
like that.
What is the link between line width and the dialog being a drawer?
Can't a drawer be set at the bottom?
I just
Am Montag, 28. Mai 2007 schrieb [EMAIL PROTECTED]:
Modified: lyx-devel/trunk/src/Thesaurus.cpp
URL:
http://www.lyx.org/trac/file/lyx-devel/trunk/src/Thesaurus.cpp?rev=18538
Arghh, sorry, I will revert this part immediately.
Jürgen
Abdelrazak Younes wrote:
OK, having read Bennett's comment I understand why you did this Jurgen
but I don't think Mac users will agree in general with this change. The
logical position of the view source is at the bottom or at the top.
So, to fix this bug I think we should just let it be
[EMAIL PROTECTED] wrote:
Author: spitz
Date: Mon May 28 09:43:15 2007
New Revision: 18538
URL: http://www.lyx.org/trac/changeset/18538
Log:
Fix bug 3522.
(swith(Abdel, Lars) :-)):
If you change that:
+docstring const BufferParams::writeEncodingPreamble(LaTeXFeatures
features,
+
Georg Baum wrote:
I don't know why everybody states this when I never wrote to do this.
I simply used the misunderstanding of Jürgen as a cause to mention that
adding them 'correctly' would indeed make sense.
Same for me. I didn't mean to point my arguments towards Uwe in any way, but
was
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
OK, having read Bennett's comment I understand why you did this Jurgen
but I don't think Mac users will agree in general with this change. The
logical position of the view source is at the bottom or at the top.
So, to fix this bug I think we
[EMAIL PROTECTED] wrote:
On Mon, 28 May 2007, Abdelrazak Younes wrote:
Lars Gullik Bjønnes wrote:
| | +ListingsParam(string const v, bool o, param_type t,
| | +string const i, docstring const h)
| | : value_(v), onoff_(o), type_(t), info_(i), hint_(h)
| |{}
| |
Abdelrazak Younes wrote:
Are you insulting me?
I'd never dare to do that, Monsieur :-)
Jürgen
Jürgen Spitzmüller wrote:
Georg Baum wrote:
I don't know why everybody states this when I never wrote to do this.
I simply used the misunderstanding of Jürgen as a cause to mention that
adding them 'correctly' would indeed make sense.
Same for me. I didn't mean to point my arguments towards
Jürgen Spitzmüller wrote:
Insert table (just a table, no float) is a string that
don't exist in either nb.po or de.po.
Does the attached patch help?
Michael, could you check that please?
Jürgen
Abdelrazak Younes wrote:
I would say in the LateX export but Georg wouldn't agree with me I think.
I would agree. It would ease to implement a special symbols panel later (that
uses unicode-insert).
Jürgen
Jürgen Spitzmüller wrote:
http://bugzilla.lyx.org/show_bug.cgi?id=3522
reviewed and approved by Georg.
The patch does the following:
- it moves all the encoding checks in BufferParams::writeLaTeX to
an own function writeEncodingPreamble and (so in BufferParams.cpp
most is just
Abdelrazak Younes wrote:
void BufferParams::writeEncodingPreamble(odocstringstream os,
LaTeXFeatures features, TexRow texrow) const
How do I convert a odocfstream (in PreviewLoader) to an odocstringstream? Just
passing it to writeEncodingPreamble gives a compile error.
+docstring
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Are you insulting me?
I'd never dare to do that, Monsieur :-)
:-)
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I would say in the LateX export but Georg wouldn't agree with me I think.
I would agree. It would ease to implement a special symbols panel later (that
uses unicode-insert).
That is a good use-case indeed. Setting the language to properly
Also take a look here: http://bugzilla.lyx.org/show_bug.cgi?id=2475
This bug has to do with the line break. The cursor at the newline
position should be shown in the previous line in front of the line
break symbol. The cursor one position after it should be shown in the
next line. But the
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
void BufferParams::writeEncodingPreamble(odocstringstream os,
LaTeXFeatures features, TexRow texrow) const
How do I convert a odocfstream (in PreviewLoader) to an odocstringstream? Just
passing it to writeEncodingPreamble gives a
Am Montag, 28. Mai 2007 10:13 schrieb Abdelrazak Younes:
Jürgen Spitzmüller wrote:
But since we are on the topic: Georg, how should this specific case be
implemented? I thought about something like
bool Encodings::is_greek(char_type c)
{
return 0x0370 = c = 0x03ff ||
Jürgen Spitzmüller wrote:
José Matos wrote:
Jürgen what is your opinion on this?
Even if this will fall back on me (because this is something I'd really need),
I think this has to wait.
imho the patch solves a very important bug, one which most people would
consider critical:
broken
Georg Baum wrote:
Note that adding the symbols in question to the unicodesymbols file will
automatically solve the problem of broken latex export for greek
characters that are not marked at greek, without any hack needed.
That would be great. But how should the entries look like?
Jürgen
Am Montag, 28. Mai 2007 10:31 schrieb Abdelrazak Younes:
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I would say in the LateX export but Georg wouldn't agree with me I
think.
I would agree. It would ease to implement a special symbols panel later
(that
uses unicode-insert).
Abdelrazak Younes wrote:
Sorry, odocstream should do the job.
Doesn't compile either:
/usr/include/c++/4.1.2/bits/ios_base.h: In copy
constructor 'std::basic_ioswchar_t, std::char_traitswchar_t
::basic_ios(const std::basic_ioswchar_t, std::char_traitswchar_t )':
Edwin Leuven wrote:
Jürgen Spitzmüller wrote:
José Matos wrote:
Jürgen what is your opinion on this?
Even if this will fall back on me (because this is something I'd
really need), I think this has to wait.
imho the patch solves a very important bug, one which most people would
consider
Georg Baum wrote:
Am Montag, 28. Mai 2007 10:31 schrieb Abdelrazak Younes:
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I would say in the LateX export but Georg wouldn't agree with me I
think.
I would agree. It would ease to implement a special symbols panel later
(that
uses
Am Montag, 28. Mai 2007 10:48 schrieb Jürgen Spitzmüller:
Georg Baum wrote:
Note that adding the symbols in question to the unicodesymbols file
will
automatically solve the problem of broken latex export for greek
characters that are not marked at greek, without any hack needed.
That
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Sorry, odocstream should do the job.
Doesn't compile either:
Try 'odocstream '.
Abdel.
Am Montag, 28. Mai 2007 10:55 schrieb Abdelrazak Younes:
Edwin Leuven wrote:
Jürgen Spitzmüller wrote:
José Matos wrote:
Jürgen what is your opinion on this?
Even if this will fall back on me (because this is something I'd
really need), I think this has to wait.
Definitely.
Am Montag, 28. Mai 2007 10:58 schrieb Abdelrazak Younes:
OK, then shouldn't we switch altogether to the unicodesymbols file and
forget about this inputenc package? Or maybe this is too much work?
That would blow up the file size and generate complaints from people who
want to exchange their
Georg Baum wrote:
- Is this bug worth it to redo at least one beta to get the patch the same
testing as the other code?
- Is this bug worth it to delay 1.5.0 by binding other peoples time for
testing and implementing the lyx2lyx part?
The answer in both cases is no IMHO.
People, please
Abdelrazak Younes wrote:
Sorry Edwin, I think - surprise, surprise - that I agree with Georg :-)
no problem.
one question though: since it involves a file format change will it be
possible to introduce it in say 1.5.1?
Abdelrazak Younes wrote:
Try 'odocstream '.
Yes, this works, thanks.
Shall I apply?
Jürgen
Index: src/graphics/PreviewLoader.cpp
===
--- src/graphics/PreviewLoader.cpp (Revision 18538)
+++ src/graphics/PreviewLoader.cpp
Edwin Leuven wrote:
one question though: since it involves a file format change will it be
possible to introduce it in say 1.5.1?
No, unfortunately not.
Jürgen
Jürgen Spitzmüller wrote:
Edwin Leuven wrote:
one question though: since it involves a file format change will it be
possible to introduce it in say 1.5.1?
No, unfortunately not.
mm, that's what i thought, a pity though given that the patch is very
safe imo...
Edwin Leuven wrote:
Jürgen Spitzmüller wrote:
Edwin Leuven wrote:
one question though: since it involves a file format change will it be
possible to introduce it in say 1.5.1?
No, unfortunately not.
mm, that's what i thought, a pity though given that the patch is very
safe imo...
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Try 'odocstream '.
Yes, this works, thanks.
Shall I apply?
Fine with me.
Abdel.
Peter Kümmel wrote:
Edwin Leuven wrote:
Jürgen Spitzmüller wrote:
Edwin Leuven wrote:
one question though: since it involves a file format change will it be
possible to introduce it in say 1.5.1?
No, unfortunately not.
mm, that's what i thought, a pity though given that the patch is very
What about the c/o problematic I reported in my last email?
You mean the automatic translation to c, / and o?
Yes.
That is probably done by
word. iconv is not used here (at least not directly, maybe internally by
qt, but if it would do this change whan asked to convert from utf16
Abdelrazak Younes wrote:
That was what I was going to suggest. But then I remembered that the
goal of 1.6 is XML and this alone will take time I guess.
What LyX is going to gain with a XML file format ? Except being buzz
compliant.
I am not sure
that switching to XML and doing minor file
Uwe Stöhr wrote:
But I would do it like this:
0x2105 \\lyxcareof \\newcommand{\\lyxcareof}
{\\leavevmode\\hbox{\\raise.75ex\\hbox{c}\\kern-.15em/\\kern-.125em\\smash{\\lower.3ex\\hbox{o}}}\\ignorespaces}
# CARE OF
This doesn't work but this:
# following macro for the CARE OF
Charles de Miramon wrote:
Abdelrazak Younes wrote:
That was what I was going to suggest. But then I remembered that the
goal of 1.6 is XML and this alone will take time I guess.
What LyX is going to gain with a XML file format ? Except being buzz
compliant.
XML offers a number of
I wondered, should we use the chars we now have in the latin1 table in
the docs?
(btw. Why is the \author updated even if I am not using
changetracking? Cannot this be considered information leak?)
(PS: I see that my mailer mangles the unicode chars... if we commit
this it will be done
Note that adding the symbols in question to the unicodesymbols file will
automatically solve the problem of broken latex export for greek
characters that are not marked at greek, without any hack needed.
That would be great. But how should the entries look like?
I don't like this. I would
Lars Gullik Bjønnes wrote:
I wondered, should we use the chars we now have in the latin1 table in
the docs?
looks sensible.
(btw. Why is the \author updated even if I am not using
changetracking? Cannot this be considered information leak?)
I think so, too.
Jürgen
christian == christian ridderstrom [EMAIL PROTECTED] writes:
christian I'd say it's our problem as we greatly benefit from having
christian Lars around.
But there are very weird chemical (thermonuclear?) reaction going on
between Abdel and Lars...
JMarc
Uwe Stöhr [EMAIL PROTECTED] writes:
| Note that adding the symbols in question to the unicodesymbols file will
| automatically solve the problem of broken latex export for greek
| characters that are not marked at greek, without any hack needed.
|
| That would be great. But how should
Peter Kümmel [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
| [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
|
| | Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| |
| | | Peter == Peter Kümmel [EMAIL PROTECTED] writes:
| | |
| | | Peter I've reproduced the error and fixed it.
Abdelrazak Younes [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
| | | +ListingsParam(string const v, bool o, param_type t,
| | | + string const i, docstring const h)
| | | : value_(v), onoff_(o), type_(t), info_(i), hint_(h)
| | |
Peter Kümmel [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
| Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
|
| | Peter == Peter Kümmel [EMAIL PROTECTED] writes:
| |
| | Peter I've reproduced the error and fixed it. The problem was, not
| | Peter only page up/down keys were
Stefan Schimanski wrote:
The logic is in fact not very complicated. The assumption is that you
only want a new target_x if you go up/down from inside a row. So if
you are at the left or right of a row you only want to take a new
target_x if it is further to the right than the old one (or if
Lars Gullik Bjønnes wrote:
As usual you don't get it.
As usual I don't get what _you_ mean yes. Why don't you say explicitely
what you mean for a change?
I want us to decide on the preferred way to
write multiline comments or doxygen comments for that matter. What I
don't want is our
Abdelrazak Younes wrote:
What about for 1.5.0 a patch with the file format change and a small
logic to tell Lyx
to just skip the cline format, if it finds any
for 1.5.1 the gui and the latex generator
Advice from an ignorant,
This is very sensible IMHO. Is this possible Edwin?
sounds good
Jean-Marc Lasgouttes wrote:
christian == christian ridderstrom [EMAIL PROTECTED] writes:
christian I'd say it's our problem as we greatly benefit from having
christian Lars around.
But there are very weird chemical (thermonuclear?) reaction going on
between Abdel and Lars...
We just don't
On Monday 28 May 2007 12:28:55 Jean-Marc Lasgouttes wrote:
But there are very weird chemical (thermonuclear?) reaction going on
between Abdel and Lars...
Thermonuclear is not what I associate with chemical reactions. ;-)
JMarc
--
José Abílio
Abdelrazak Younes wrote:
What about
for 1.5.0 a patch with the file format change and a small logic to tell
Lyx to just skip the cline format, if it finds any
for 1.5.1 the gui and the latex generator
Advice from an ignorant,
This is very sensible IMHO. Is this possible Edwin?
On Monday 28 May 2007 11:16:35 Abdelrazak Younes wrote:
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Try 'odocstream '.
Yes, this works, thanks.
Shall I apply?
Fine with me.
+1
Abdel.
--
José Abílio
On Monday 28 May 2007 12:25:08 Jürgen Spitzmüller wrote:
looks sensible.
+1
(btw. Why is the \author updated even if I am not using
changetracking? Cannot this be considered information leak?)
I think so, too.
+1
Jürgen
--
José Abílio
On Monday 28 May 2007 12:07:32 Charles de Miramon wrote:
What LyX is going to gain with a XML file format ? Except being buzz
compliant.
We will have our file format supported by all the xml related tools. Think
about the parser, the grammar is easier to define and so on... Currently
there
Jürgen Spitzmüller wrote:
What would that mean if someone opens a file done with, say, 1.5.2 (with
cline support) with 1.5.1 (without cline support)? Will this file be
displayed and exported correctly? Will it be saved correctly, so that the
file again opens without dataloss in 1.5.2?
José Matos wrote:
We gain xsl to write converters to other formats
If KOffice can be point of comparison. Before switching to ODF, we had a xml
format and nobody (well actually one man) wrote any xsl converters because
it seems that everybody hates xslt.
Cheers,
Charles
--
Jürgen Spitzmüller wrote:
What would that mean if someone opens a file done with, say, 1.5.2
(with cline support) with 1.5.1 (without cline support)? Will this
file be displayed and exported correctly? Will it be saved correctly,
so that the file again opens without dataloss in 1.5.2?
you're
Edwin Leuven wrote:
you're right, going back and forth would be a problem so either we do
the full monty or we forget about this.
for 1.5, you mean. You can commit this immediately to trunk as soon as we have
a BRANCH_1_5_X.
fwiw, the attached patch is working great and imho very safe (i
Charles de Miramon [EMAIL PROTECTED] writes:
| José Matos wrote:
|
|
|We gain xsl to write converters to other formats
|
| If KOffice can be point of comparison. Before switching to ODF, we had a xml
| format and nobody (well actually one man) wrote any xsl converters because
| it
For some reason, changing the type of the dialog switches the default
button from OK to Cancel. This restores the correct default. Must be a
QT bug.
Still seeking two OKs...or at least some reaction!
rh
--
==
Richard G Heck, Jr
Jürgen Spitzmüller wrote:
Edwin Leuven wrote:
you're right, going back and forth would be a problem so either we do
the full monty or we forget about this.
for 1.5, you mean. You can commit this immediately to trunk as soon as we have
a BRANCH_1_5_X.
ok
The bug is that the top- and
Richard Heck wrote:
For some reason, changing the type of the dialog switches the default
button from OK to Cancel. This restores the correct default. Must be a
QT bug.
If it is, it must be local to linux. Here (WinXP, Qt4.2.1) the focus
stays on the OK button.
Still seeking two OKs...or
Edwin Leuven wrote:
The bug is that the top- and bottomlines can no longer be toggled in
booktabs mode.
i don't think so.
you cannot toggle the top line on the *first* row and the bottom line on
the last row.
this is intentional: we don't allow the user to toggle these atm (just
create
Abdelrazak Younes wrote:
For some reason, changing the type of the dialog switches the default
button from OK to Cancel. This restores the correct default. Must be a
QT bug.
If it is, it must be local to linux. Here (WinXP, Qt4.2.1) the focus
stays on the OK button.
Here, everything
Jürgen,
with a little luck, I will be able to do some translator work this
evening - right in time for pre1.
Michael
Jürgen Spitzmüller schrieb:
Jürgen Spitzmüller wrote:
Insert table (just a table, no float) is a string that
don't exist in either nb.po or de.po.
Does the
Try this, just to check: Create a new document; put a listings include
in it; save and close. Open the document. Open the include and type
something in the label field; hit return; re-open the dialog. This
should work. Now create a new include inset, and set it to include.
Close. Re-open the first
Lars Gullik Bjønnes wrote:
ODF is also xml based afaik.
Yes but the logic of formatting of an ODF file and of a LyX file (modelled
on LaTeX) is very different. There is no preamble for example in ODF.
This blog is interesting and it seems to me that LaTeX is rather similar to
Wordperfect.
This patch addresses these bugs:
http://bugzilla.lyx.org/show_bug.cgi?id=3741
http://bugzilla.lyx.org/show_bug.cgi?id=3756
The latter is more a policy question, but the bug report seems right to
me: How double-clicking behaves shouldn't depend upon whether
something's already in the selected
Richard Heck wrote:
This patch addresses these bugs:
http://bugzilla.lyx.org/show_bug.cgi?id=3741
http://bugzilla.lyx.org/show_bug.cgi?id=3756
The latter is more a policy question, but the bug report seems right to
me: How double-clicking behaves shouldn't depend upon whether
something's already
On Monday 28 May 2007 15:50:11 Charles de Miramon wrote:
I fail to see what are the big advantages (except reusing an on-the-shelf
parser). Moving away from LaTeX logic will complexify the LyX - LaTeX
process.
I am not sure what you mean above. The xml format is just the middle man. The
data
Abdelrazak Younes wrote:
Richard Heck wrote:
This patch addresses these bugs:
http://bugzilla.lyx.org/show_bug.cgi?id=3741
http://bugzilla.lyx.org/show_bug.cgi?id=3756
The latter is more a policy question, but the bug report seems right to
me: How double-clicking behaves shouldn't depend upon
José Matos wrote:
I am not sure what you mean above. The xml format is just the middle
man. The data inside lyx remain the same.
and a crucial question is of course the following:
who is planning to work on this (and finish it)?
(count me out btw, i intend to do a bit of tabular cleaning...)
Charles de Miramon [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
|
|
| ODF is also xml based afaik.
|
|
| Yes but the logic of formatting of an ODF file and of a LyX file (modelled
| on LaTeX) is very different. There is no preamble for example in ODF.
Right. It also seems to me
On Mon, May 28, 2007 at 10:20:57AM +0900, Koji Yokota wrote:
Peter Kümmel wrote:
Hasn't Abdel fixed it today? Maybe updating helps.
Yeah, right. With a newer version, Lyx at least proceeds with a
successful initialization and its GUI appears. However, trial of File -
New, File - Open,
José Matos wrote:
On Monday 28 May 2007 15:50:11 Charles de Miramon wrote:
I fail to see what are the big advantages (except reusing an on-the-shelf
parser). Moving away from LaTeX logic will complexify the LyX - LaTeX
process.
I am not sure what you mean above. The xml format is just the
Edwin Leuven wrote:
José Matos wrote:
I am not sure what you mean above. The xml format is just the middle
man. The data inside lyx remain the same.
and a crucial question is of course the following:
who is planning to work on this (and finish it)?
I agree that we should make sure that we
Edwin Leuven [EMAIL PROTECTED] writes:
| José Matos wrote:
| I am not sure what you mean above. The xml format is just the middle
| man. The data inside lyx remain the same.
|
| and a crucial question is of course the following:
|
| who is planning to work on this (and finish it)?
I am. The
Jürgen Spitzmüller wrote:
About the ui: I find it irritating that I have to select the whole row
now to switch lines on/off.
you find it irritating because it is different, but ui-wise i think it
is much more intuitive...
Not for me.
And why should we do it differently than we used to
Abdelrazak Younes [EMAIL PROTECTED] writes:
| Edwin Leuven wrote:
| José Matos wrote:
| I am not sure what you mean above. The xml format is just the middle
| man. The data inside lyx remain the same.
| and a crucial question is of course the following:
| who is planning to work on this (and
\\newcommand{\\lyxcareof}{\\leavevmode\\hbox{\\raise.75ex\\hbox{c}\\kern-.15em/\\kern-.125em\\smash{\\lower.3ex\\hbox{o}}}\\ignorespaces}
\newcommand*\lyxcareof{%
\mbox{\raisebox{.8ex}{c}\kern-.175em\raisebox{.2ex}{/}%
\kern-.18em\raisebox{-.2ex}{o}}}
Thanks I use now your solution
Lars Gullik Bjønnes wrote:
| who is planning to work on this (and finish it)?
I am. The DTD is some 70-80% finished I guess.
Quite a bit of writing is done, parsing/reading is not begun.
i was asking because we should be sure in advance that there is enough
competent and motivated manpower
Ran wrote:
Hi,
I've made I few updates:
1) Updated he.po file:
http://www.yousendit.com/download/UVJpaklxeFhubVUwTVE9PQ
2) Updated Intro:
http://www.yousendit.com/download/UVJpakl0R0ZtUUUwTVE9PQ
3) Updated Splash:
http://www.yousendit.com/download/UVJpaklqVEhENlEwTVE9PQ
4) I've asked before
Richard Heck wrote:
For some reason, changing the type of the dialog switches the default
button from OK to Cancel. This restores the correct default. Must be a
QT bug.
Still seeking two OKs...or at least some reaction!
Hi, Richard.
The button is changed because the GUI view is telling the
Uwe Stöhr [EMAIL PROTECTED] writes:
| 4) I've asked before about having a localized Hebrew bind file, and I
| was given a positive answer. Alas, the file was never committed. So,
| here is the file again:
| http://www.yousendit.com/download/UVJpaklxeFhRYTgwTVE9PQ
This 4. one puzzles me a bit.
On Mon, 28 May 2007, Uwe Stöhr wrote:
That is probably done by word. iconv is not used here (at least not
directly, maybe internally by qt, but if it would do this change whan
asked to convert from utf16 (QString) to ucs4 (docstring) it would be
a bug). Paste from word to a real text
1 - 100 of 318 matches
Mail list logo
