> Inside mathed it's more or less LaTeX. You have the same ambiguity.
> LyX makes no effort to guess the semantics of your formula.
Ok.
> I think it should be possible to create a 'invisible' '*' i.e. a
> character that translates to nothing when output to LaTeX and to '*'
> when converted to Mu
I'm probably sticking my nose in where it doesn't belong, but ...
On Wed, 19 Apr 2000, Nicolas M. Thiery wrote:
> Converters latex/openmath and latex/mathml exists (see
> http://www.openmath.org/), but I have been told that their job is
> pretty difficult because of ambiguities when extracting th
>I that really a good idea? It is better to keep similar things
> together. What I'd rather see is a hierarchical menu (Sections,
> Lists...).
Yes, enumerate and itemize are no longer close...
But it is much easier that way, nontheless. I'm using it all the time and it is
a big relief
--- Start of forwarded message ---
Date: Wed, 19 Apr 2000 17:07:53 +0200
Message-Id: <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Feedback from www.lyx.org
FROM: [EMAIL PROTECTED]
Antonio Zugaldia ([EMAIL PROTECTED]) entered the
following feedback message on the LyX home page:
---
> Mathed basically reads and writes LaTeX quite well and this won't
> change even if internal structures are changed. So in order to protect
> you from the messy internals I'd suggest to take LaTeX as a starting
> point. So the problem boils down to a 'part of LaTeX to MathML'
> converter. If yo
Angus Leeming <[EMAIL PROTECTED]> writes:
| What do you use if snprintf() is not defined on your system?
Why will a stringstream not work?
|
| #define def_simple_output(type, form) \
| void output_simple(type const& data) { \
| space(); \
| unrequire(20-snprin
> Well, I guess all that would be really needed is two functions for
> converting back and forth between the contents of a mathed and
> openmath/mathml/?. How difficult would this be ?
Mathed basically reads and writes LaTeX quite well and this won't
change even if internal structures are changed
Andre Poenitz <[EMAIL PROTECTED]> writes:
| I attach a small patch that should clean up insets/figinset.C a bit.
Ok, it is looks ok I'll just apply it. However note that I really
don't want this cleaned up, I want it rewritten!
| It should not change anything visible or any internal structure,
I attach a small patch that should clean up insets/figinset.C a bit.
It should not change anything visible or any internal structure,
it justs uses tostr() and strstreams instead of sprintf
and factors out common code to some local functions.
Andre'
Index: figinset.C
===
> Well I don't think that Hard-Core LyX Developers ;) would oppose if
> you could reimplement Mathed in a clean way (it is messy and with
> lots of hacks) I just don't know what Alejandro the former writer of
> Mathed is doing, last time I heard from him he was very busy, but he
> also told us tha
Angus Leeming <[EMAIL PROTECTED]> writes:
| Well I use them all the time in the math editor to show me whether I'm inside
| or outside a macro --- at least I have to bound my macro with ERT {} and would
| much prefer it if I could get this info from a special char.
This is not what I put into sp
Dekel Tsur <[EMAIL PROTECTED]> writes:
| > (I realy don't like the special chars)
|
| Why?
Becasue they are in the 256 char namespace...
| I've already implemented the first point. Should I submit it now, or after
| 1.1.5 ?
Regardless of what we do it should be done after 1.1.5.
Lgb
XTL's example code "xdr", designed to test XDR_format now compiles and runs on
Alphas without error using either gcc-2.95.2 or DEC cxx under both LinuxAlpha
and Tru64 unix. Hoorah!
xtl/text.h has problems still and so I have a question for the C gurus out
there:
What do you use if snprintf() is
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> Are you serious? Dekel's approach sounds *much* cleaner and if
Andre> you don't render the red dots there should be no visible change
Andre> at all.
You can have red dots without special character. And if you hide the
special char
> Well I guess that this may be resolved much better when using the
> direction where the cursor came from. So when entering from left we should
> use bold otherwise we could use normal.
And some day LyX's behaviour does not just depend on the position of the
cursor and the direction it was comin
Dekel> Furthermore, the use of special char is also for the purpose of
Dekel> differentiating the position before the font change and after the font change:
Dekel> Suppose you have a word "abcd" where ab is in the default font, and cd is in
Dekel> bold. Now, what happens when you place the cursor
On 19-Apr-2000 Dekel Tsur wrote:
>
> Furthermore, the use of special char is also for the purpose of
> differentiating the position before the font change and after the font change:
> Suppose you have a word "abcd" where ab is in the default font, and cd is in
> bold. Now, what happens when you
> "Gady" == Gady Kozma <[EMAIL PROTECTED]> writes:
Gady> This patch against 1.1.4fix1 redoes the layout menu in the
Gady> toolbar.
Gady> A) The menu is alphabetaized.
I that really a good idea? It is better to keep similar things
together. What I'd rather see is a hierarchical menu (Sectio
> 1. The paragraph stores a vector (FontList) of pairs (position, font),
> sorted by positions, containing the positions in the paragraph in which the font
> changes, and the corresponding fonts.
You don't even need the position. The information is implicitly contained
in the rest of the structur
On Wed, Apr 19, 2000 at 12:52:46PM +0200, Lars Gullik Bj&resh;nnes wrote:
> Dekel Tsur <[EMAIL PROTECTED]> writes:
>
> | For the current kernel, I thought of the following changes to the
> | way the fonts
> | are stored by the LyX paragraph class:
> |
> | 1. The paragraph stores a vector (FontL
Dekel Tsur <[EMAIL PROTECTED]> writes:
| I've looked for your kernel in the 'lyx' cvs module, but the code there is
| incomplete. Is there a working version of your kernel? Is it still the plan
| to use it instead of the current kernel? When?
We jumped the gun a bit when we put the "new kernel"
> I think this is a bad idea for performance reasons. Notice that it's
> not only memory issues: It's also the issue of displaying on screen.
> Displaying on screen is the most important bottleneck, and it has to
> be fast. It will not be fast if the fundamental data structure is
> one character a
>
> In my opinion any step in this direction would mean a complete rewrite
> of the math inset. Anything short of that probably means wasting a lot
> of time with ugly hacks and workarounds. But that's just my opinion and
> know that a few people disagree...
Well I don't think that Hard-Core LyX
> Of course, such a project is only interesting if it's done in close
> collaboration with the development team of lyx. Would you be
> interested by such an extension of lyx ? Do you have an idea of how
> hard this would be to implement ?
I definitely would be interested, even if you can't count
24 matches
Mail list logo