Michel Fortin wrote:
I know that. But special parsing rules, just as new CSS properties,
need changes to happen in the browser. If someone is going to improve
the browser, it'd be much better to improve the presentational layer
with a few reusable CSS rules than to add a collection of
Alexey Feldgendler wrote:
border-character isn't going to work. When scaled non-proportionally,
characters get ugly, with horizontal elements getting thick. The { and }
characters will suffer the most from this. TeX applies custom logic to
stretchy braces, and I think we shouldn't try
Michel Fortin wrote:
Le 20 juin 2006 à 6:53, Robert O'Callahan a écrit :
I would also like to see a complete description of the CSS extensions
required for real high-quality rendering.
I can't claim this is complete, but two ideas come to my mind right now:
[4 suggestions]
Also, as far as
Le 22 juin 2006 à 3:52, White Lynx a écrit :
Adding CSS extensions makes sense, but I fear it could take
infinite time,
therefore it is better to keep markup within XML/CSS2.1 framework
so we could
start using it today and then gradually improve situations on CSS
side.
It will surely
Juan R. Gonzalez-Alvarez wrote:
I assume that authors agree. Therefore, now is matter for developers, they
have the last word.
Basically there is nothing in proposal that could be difficult to implement,
morover on first stage XHTML with fallback style sheets can work without
any kind of
Le 21 juin 2006 à 7:16, White Lynx a écrit :
1. formula, dformula, dformgrp - just containers, no problems.
2. sub, sup - already exist nothing to add
3. stack - requires support for inline-blocks. No problems in MSIE,
Opera, Prince.
Safari and Mozilla will have to fix bug affecting
Michel Fortin wrote:
4. In the same reasoning, it would be great if there was a way adjacent
elements could share the same horizontal space, like sup and sub
when they are next to each other:
Csup1/supsub2/sub
To avoid changes on CSS side in current proposal
this is
Michel Fortin wrote:
My proposal was fractions, and *only* fractions.
This rises question how to mark formulae produced by combining expressions with
fractions and indices. At least one element for this purpose would be
necessary. Even DocBook and TEI that does not have their own math markup,
On Wed, 21 Jun 2006 21:48:25 +0700, Michel Fortin
[EMAIL PROTECTED] wrote:
1. Some border-character property, which would work mostly like CSS
3's border-image, but would put a stretchable character in the border.
The browser would be in charge of stretching. border-image with SVG
could
Le 21 juin 2006 à 13:29, Alexey Feldgendler a écrit :
On Wed, 21 Jun 2006 21:48:25 +0700, Michel Fortin
[EMAIL PROTECTED] wrote:
1. Some border-character property, which would work mostly like
CSS 3's border-image, but would put a stretchable character in the
border. The browser would
Le 21 juin 2006 à 12:00, White Lynx a écrit :
Michel Fortin wrote:
4. In the same reasoning, it would be great if there was a way
adjacent
elements could share the same horizontal space, like sup
and sub
when they are next to each other:
Csup1/supsub2/sub
To avoid
Michel Fortin wrote:
Bugs will need to
be fixed with many CSS engines,
Withdrawing proposal does not mean that this bugs need not to be fixed.
They has to be fixed in any case.
and even then the current markup
proposal isn't something I'd call pretty even for simpler structures
Ian Hickson wrote:
There is nothing to read between my lines. I am being as honest and candid
as possible. There is no conspiracy here. I have given you the exact
reasoning I have used, I have suggested how you can move forward. I am
being quite sincere.
Very well. In this case please
On Tue, 20 Jun 2006 14:43:23 +0700, White Lynx [EMAIL PROTECTED]
wrote:
Very well. In this case please make one small step to show that WHATWG
HTML is open to scientific content and add just four elements to HTML5
(feel free to use different element names if nesessary): formula,
fraction,
Michel Fortin wrote:
Something that's definitely missing for
elementary algebra is a construct capable of representing a fraction.
So I propose that HTML 5 adds fractions, and only fractions.
Yes please, that would be a great start. It is quite cheap and a
reasonable way to get a certain
Robert O'Callahan wrote:
From my point of view, a fraction element that can be implemented using
inline-block in the UA style sheet seems like a reasonable thing to support
in HTML5, since it's basically no effort and is a small increment over
existing sup etc.
Thus fractions work in MSIE,
Alexey Feldgendler wrote:
How should formula be used? There has been some discussion about it.
In case when everything is reduced to fractions and simple indices,
it can be optional. But having such an element is still important for those
who want to mark formulae explictly.
I've never said
On Tue, 20 Jun 2006 18:47:42 +0700, White Lynx [EMAIL PROTECTED]
wrote:
How should formula be used? There has been some discussion about it.
In case when everything is reduced to fractions and simple indices,
it can be optional. But having such an element is still important for
those who
Ian Hickson wrote:
On Mon, 19 Jun 2006 [EMAIL PROTECTED] wrote:
1) It has been proven that via Standard CSS 2.1 not designed for math
one can render math better than browsers with native support (as
Firefox 1.0) and infinitely better than MSIE, Safari, and Opera
(rendering natively zero
On Tue, 20 Jun 2006 19:20:28 +0700, White Lynx [EMAIL PROTECTED]
wrote:
How should formula be used? There has been some discussion about it.
In case when everything is reduced to fractions and simple indices,
it can be optional. But having such an element is still important for
those who
Le 20 juin 2006 à 3:40, White Lynx a écrit :
Yes. The same markup is used in ISO 12083, AAP Math DTD and most of
other DTDs
that I have seen, modulo naming conventions this markup is:
fraction
numnumerator/num
dennumerator/den
/fraction
That was what I had in mind. I used to prefer frac
Henri Sivonen wrote:
On Jun 20, 2006, at 10:42, White Lynx wrote:
Henri Sivonen wrote:
There are only stretchy brackets.
No stretchy parentheses or braces in sight.
Did you check fences part at http://www.geocities.com/chavchan/css/
annotated.css
I didn't. I checked the sample
On Jun 20, 2006, at 15:26, [EMAIL PROTECTED] wrote:
However, it look better that via native
MathML support browsers (without downloading and installing special
fonts).
Comparing anything to a MathML implementation without giving the
MathML impl the fonts it needs is totally bogus.
Yes,
Robert O'Callahan wrote:
I'll speak up as one of the Mozilla layout developers, but speaking only
for myself.
Since we already have a MathML implementation --- which works fairly
well in my experience ---
Do you mean structurally invalid, inacessible, not searchable, and
sometimes
White Lynx wrote:
The difference between fractions and the rest of proposal is that markup
for fractions is the same across many DTDs and it is hard to imagine
something different (only W3C can). Thus markup for fractions is more or
less unique. In the rest of proposal uniqueness it is not
On Sun, 18 Jun 2006, White Lynx wrote:
Ian Hickson wrote:
Certainly. The question is how. There have been several proposals. My
recommendation to those who think it is possible to re-use CSS to get
an acceptable level of Math support would be to go through the
Microformats process to
On Mon, 19 Jun 2006 14:20:25 +0700, Ian Hickson [EMAIL PROTECTED] wrote:
Assuming that the people involved value their time at an average of $10
per hour, that's 3179 man-hours at $10 each, so $31,790 per element name.
Just wanted to point out: your calculations don't scale when a batch of new
On 17 Jun 2006, at 2:15PM, White Lynx wrote:
Oistein E. Andersen wrote:
The current proposal does not seem to include the following elements of
ISO-12083:
- fence with arbitrary delimiters (possibly not a good idea)
Probably it is better to list number of delimiters explicitly like in LaTeX.
Oistein E. Andersen wrote:
- labelled arrows [...]
'over' and 'under' elements can be used to put label above or below the
arrow (also it will not stretch arrow).
Do you mean that ISO-12083 labelled arrows are not supposed to stretch?
They are supposed to stretch, this is part of
Anne van Kesteren wrote:
Quoting [EMAIL PROTECTED]:
Since MathML does not fit into the WHATWG philosophy, I would
aknowledge information about your own solution to the problem of
mathematical markup on the web.
Oh please, cut the crap. Did you miss the message from Ian saying how
it could
James Graham wrote:
That's a really particular use case which is hardly representative of
the web as a whole. As sad as it is, 99.9% of authors have no use for
maths (otherwise all these problems would have been solved long ago).
Maths is certainly less of a core feature for most authors
Ian Hickson wrote:
On Mon, 12 Jun 2006 [EMAIL PROTECTED] wrote:
WHATWG doesn't have a position on this -- different contributors
have different opinions, and no clear consensus is being reached as
far as I can tell.
It has been taken one! The draft of the specification recommends the
James Graham wrote:
Except that XML will not work with HTML4.
XML = SVG therefore
Except that SVG will not work with HTML4.
[http://www.carto.net/papers/svg/samples/svg_html.shtml]
[http://www.december.com/html/tech/svg.html]
[http://www.december.com/html/demo/hellosvg.html]
One of the
**What is the goal?**
If I understand James and Ians statements correctly, the play is that
either one provides a perfect markup in less than 12 tags can offer us
dinamical pages with TeX quality for liquid layouts and generic web fonts
(even TeX cannot), was implemented in browsers with zero
James Graham wrote:
Is math really a core feature?
Yes, absolutely .. the upcoming microlearning / nanolearning units
inevitably need math.
That's a really particular use case which is hardly representative of
the web as a whole. As sad as it is, 99.9% of authors have no use for
maths
Quoting Stefan Gössner [EMAIL PROTECTED]:
I wish, that WHATWG would have a similar motivation to offer
lightweight math capabilities parallel to MathML, as they were
motivated to support vector graphics via the canvas element parallel
to SVG.
OMG. Have you even read what canvas is about? :-)
On Sat, 17 Jun 2006, White Lynx wrote:
Basic Web application features SHOULD BE IMPLEMENTABLE using behaviors,
scripting, and style sheets IN IE6 TODAY
Given that canvas has been implemented in IE6, I have no worries that an
HTML-based Math markup language based on MathML (and creating a
On Sat, 17 Jun 2006, James Graham wrote:
That's a really particular use case which is hardly representative of
the web as a whole. As sad as it is, 99.9% of authors have no use for
maths (otherwise all these problems would have been solved long ago).
Maths is certainly less of a core
Quoting White Lynx [EMAIL PROTECTED]:
Certainly. The question is how. There have been several proposals. My
recommendation to those who think it is possible to re-use CSS to get an
acceptable level of Math support would be to go through the Microformats
process to prove the case.
What is the
Anne van Kesteren wrote:
Certainly. The question is how. There have been several proposals. My
recommendation to those who think it is possible to re-use CSS to get an
acceptable level of Math support would be to go through the Microformats
process to prove the case.
What is the
White Lynx wrote:
James Graham wrote:
You have to choose your battles and, personally, I
agree with the idea that, if the proponents of CSS-based maths want to
work in the structure of the WHATWG, they should demonstrate the
feasibility of their approach using a microformat. Given the
James Graham wrote:
You have to choose your battles and, personally, I
agree with the idea that, if the proponents of CSS-based maths want to
work in the structure of the WHATWG, they should demonstrate the
feasibility of their approach using a microformat. Given the constraints
under
Ian Hickson wrote:
Certainly. The question is how. There have been several proposals. My
recommendation to those who think it is possible to re-use CSS to get an
acceptable level of Math support would be to go through the Microformats
process to prove the case.
What is the difference
Michel Fortin wrote:
Yes, sub/sup will behave like HTML sub/sup with offsets being based
on font size like it is currently done in HTML implementations,
while llim/ulim and marker/submark will have offsets based on size
of their base (operator, fence, matrix etc.) not font size like
James Graham wrote:
So how does it fit in the scope of fundamental principles upon which
the WHAT working group intends to operate?
http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html
I don't see anything contradictory there
Web application technologies SHOULD BE BASED ON
On 16 Jun 2006, at 2:27PM, White Lynx wrote:
Oistein E. Andersen wrote:
The proposal states that op should be used to mark resizable operators,
but this presumably does not mean that the size of such operators is actually
intended to change.
It is intended to be larger.
Yes, but the size is
Le 17 juin 2006 à 7:01, White Lynx a écrit :
Yes, sup/sub will work like in HTML. This behavior is not perfect
in case
of resizable operators, fences, matrices and vectors however in
this cases operator limits (llim/ulim) and fence markers (marker/
submark) provide necessary functionality.
Oistein E. Andersen wrote:
The proposal states that op should be used to mark resizable operators,
but this presumably does not mean that the size of such operators is
actually intended to change.
It is intended to be larger.
Yes, but the size is not intended to vary as a function of
Michel Fortin wrote:
Yes, sup/sub will work like in HTML. This behavior is not perfect
in case
of resizable operators, fences, matrices and vectors however in
this cases operator limits (llim/ulim) and fence markers (marker/
submark) provide necessary functionality.
That's what I
Anne van Kesteren wrote:
Web application technologies SHOULD BE BASED ON technologies
authors are familiar with,
including HTML, CSS, DOM, AND JAVASCRIPT
As it would work with that, it's not really a problem.
How it will work with CSS? New parsing rules at least does not improve
Anne van Kesteren wrote:
The core features of an XML vocabulary should require the use of
elements
from ONLY ONE NAMESPACE.
Is math really a core feature?
Yes, absolutely .. the upcoming microlearning / nanolearning units
inevitably need math.
Stefan Gössner wrote:
Anne van Kesteren wrote:
The core features of an XML vocabulary should require the use of
elements
from ONLY ONE NAMESPACE.
Is math really a core feature?
Yes, absolutely .. the upcoming microlearning / nanolearning units
inevitably need math.
That's a really
Anne van Kesteren wrote:
Quoting [EMAIL PROTECTED]:
Since MathML does not fit into the WHATWG philosophy, I would
aknowledge information about your own solution to the problem of
mathematical markup on the web.
Oh please, cut the crap. Did you miss the message from Ian saying how
it could
Since MathML does not fit into the WHATWG philosophy, I would
aknowledge information about your own solution to the problem of
mathematical markup on the web.
Oh please, cut the crap. Did you miss the message from Ian saying how
it could integrate?
If by integrate you mean
White Lynx wrote:
So how does it fit in the scope of fundamental principles upon which
the WHAT working group intends to operate?
http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html
I don't see anything contradictory there (and in any case I'm not sure the
document you
Le 16 juin 2006 à 9:27, White Lynx a écrit :
Yes, sub/sup will behave like HTML sub/sup with offsets being based
on font size like it is currently done in HTML implementations,
while llim/ulim and marker/submark will have offsets based on size
of their base (operator, fence, matrix etc.)
James Graham wrote:
No it is not. You have demonstrated that CSS can do a mediocre job at
simple mathematics. This is not an unimpressive achievement but neither
does it suggest that general maths layout based purely on CSS is
possible without substantial modifications to CSS itself.
Quoting [EMAIL PROTECTED]:
Since MathML does not fit into the WHATWG philosophy, I would aknowledge
information about your own solution to the problem of mathematical markup
on the web.
Oh please, cut the crap. Did you miss the message from Ian saying how
it could integrate?
--
Anne van
Oistein E. Andersen wrote:
As a first step, I have tried to transform the TeX code used on
Wikipedia (http://en.wikipedia.org/wiki/Help:Formula) into HTML5.
This raises some issues, see http://xn--istein-9xa.com/HTML5/WikiTeX.pdf for
all the details. I have tried to follow the current
Oistein E. Andersen wrote:
This issue [font selection] belong to presentational layer and has to be
addressed
on CSS side (there are no problems on XSL and/or DSSSL side as one can make
appropriate transformations).
I am not so sure about that.
In fact I am not sure either.
The
White Lynx wrote:
If this
demonstrates that it really is possible to create viable math markup in
HTML and have it completely styled in CSS then that would be a good step
This step is already made,
No it is not. You have demonstrated that CSS can do a mediocre job at simple
mathematics.
?istein E. Andersen wrote:
Conversion to MathML is obviously more difficult because the base has to
be found and encoded explicitly. Still, I do _not_ say that conversion
from TeX to HTML5 will be trivial in all cases.
Then we agree. As stated a the beginning of discussion by some, TeX
On 10 Jun 2006, at 10:1AM, White Lynx wrote:
Oistein E. Andersen wrote:
traditional French typographical conventions for mathematics require lowercase
variables in italic, but uppercase ones in roman.
Do we need extra values like text-transform:french-italic; and
french-bold-italic;
that would
On Sat, 10 Jun 2006, White Lynx wrote:
Agree. Once conceptual issues will be resolved and WHATWG will clarify
its position regarding math markup, we can return to naming conventions
and if majority prefer brief element names, ISO 12083 element names will
be replaced with shorter ones.
[EMAIL PROTECTED]
this may be difficult to achieve in practice, because TeX
conversors reading TeX sources are unable to provide correct MathML markup
for prescripts.
Conversion to MathML is obviously more difficult because the base has to be
found and encoded explicitly. Still, I do _not_ say
Oistein E. Andersen wrote:
each mark-up element must be kept as short as possible.
Some people argue that short element names being misleading and not
intuitive does not actually improve readability, some people like short
element
names as they are more convenient for authoring.
The
?istein E. Andersen wrote:
root3of125/root was already proposed in HTML Math of 1994 and
rejected because technical issues. Also rejected in ISO12083 math of
1995.
What i meant was to use root3of125/root as a shorthand notation
for something like rootorder3/orderof125/of/root, in which
case
Le 10 juin 2006 à 5:01, White Lynx a écrit :
I do not think that automatic mixing of roman and italic would be
a good
idea at the browser side if one search a rapid cheap
implementation fully
compatible with current standards.
That is probably quite right.
Yes, roman as a default is Ok
Michel Fortin wrote:
Well, now that I think of it, there will be some problems with any
pure CSS implementation (for current browsers at least, but maybe
with CSS3 too). Aligning fraction separators correctly with the base
line when num and den do not have the same height for instance: I
Ian Hickson wrote:
I am not at all convinced that it makes any sense to rely on CSS to render
mathematics. CSS simply doesn't have the expressive power to obtain
acceptably good mathematical typography, and adding features to CSS to
obtain this level of expressiveness would require a huge
I would highly appreciate a lightweight, pragamatic solution for doing
math on the web in a convenient way. This solution could parallel MathML
the same way as Canvas parallels SVG. And that does not necessarily
mean, it should be javascript or Latex based -- though it might be.
Personally I
James Graham wrote:
[EMAIL PROTECTED] wrote:
James Graham wrote:
I could go on but
at least in academic fields, LaTeX is either the only format
accepted for publication or the preferred format.
In mathematics, and theoretical physics sure, in rest of science? I
doubt. In chemistry,
On Jun 8, 2006, at 01:18, Ian Hickson wrote:
On Thu, 8 Jun 2006, Henri Sivonen wrote:
If we made MathML work in HTML, possibly with rules that make the
syntax easier (by implying tags as I suggested earlier)
The implied stuff seems scary. I was hoping for no more tag inference
beyond HTML 4
Quoting Henri Sivonen [EMAIL PROTECTED]:
I did, however, see
* White Lynx disapproving of MathML and pushing his own stuff
* Moose eventually conceding that MathML cannot be rendered using CSS
alone. (No surprise there.)
* Jonny Axelsson and Hixie alluding to Opera not having a business
case
Juan wrote:
I think that markup would be more easy possible with posibility of
ampliation, such that better authors could do a better job but average
users could easily obtain results in a cheap and rapid way.
That's something very desirable, I think, as it follows the general
spirit of
Henri Sivonen wrote:
My point was that math rendering tends to be addressed by a guy with a
mission rather than companies if the companies decide, on business
grounds, to prioritize their todo lists differently. For example, TeX
and Gecko-MathML were both created using the guy with a
On 8 Jun 2006, at 10:3AM, White Lynx wrote:
Oistein E. Andersen wrote:
each mark-up element must be kept as short as possible.
Some people argue that short element names being misleading and not
intuitive does not actually improve readability, some people like short element
names as they are
On 9 Jun 2006, at 11:0AM, [EMAIL PROTECTED] wrote:
Ãistein E. Andersen wrote:
2) Fight verbosity
m, [...] frac2den3/frac and root3of125/root [are] clearly
better suited than formula, fraction2denominator3/fraction and
radical3radicand125/radical.
However frac2den3/frac is an shorthand for
Anne van Kesteren wrote:
but just putting
this in the specification as well and requiring UAs to support it by
default seems too much to ask, imho
Maybe, but taking into account that WHATWG does not want to establish several
levels
of compliance, what can we do?
I see at least three
Anne van Kesteren wrote:
I've already sort of proposed to add Ruby to HTML. Simple Ruby is
already supported by Internet Explorer in HTML (I think the XHTML
module was based on that implementation) and it makes sense to have it
for certain foreign (to me at least) use cases.
Alexey Feldgendler wrote:
Why have f at all? When I'm writing about varx/var, why should I
write fvarx/var/f? What would be the difference? I think a
formula element is only needed for what is called display equations --
they are rendered out of line, usually centered, and sometimes
Michel Fortin wrote:
Use integral and bounds for integrals.
integral
bounds
sub0/sub
sup100sup
/bounds
3varx/var dvarx/var
/integral
There are at least 30 different operators that would require similar markup,
following this line one
Dan Brickley wrote:
It would also be both considerate and sensible
(if anyone does want to undertake such a task) to talk to the
MathML folks first.
So far we are addressing problems that were invented and deployed by MathML
folks.
--
___
Surf
White Lynx wrote:
Dan Brickley wrote:
It would also be both considerate and sensible
(if anyone does want to undertake such a task) to talk to the
MathML folks first.
So far we are addressing problems that were invented and deployed by MathML
folks.
But you are, apparently, assuming that
Oistein E. Andersen wrote:
As Henri Sivonen put it: «[I]t is futile to insist on semantics that
you can't pull out of LaTeX as it is normally authored.» I would
like to use a slightly different wording: It is futile to insist on
encoding anything that does not change the appearance of a
On Thu, 08 Jun 2006 07:58:40 +0700, Øistein E. Andersen [EMAIL PROTECTED]
wrote:
Correct splitting of continuous fractions seems like a similar non-problem.
If a fraction is really overly long, then the author should probably split it
manually.
There are certain rules for correct splitting
On Thu, 08 Jun 2006 14:24:36 +0700, White Lynx [EMAIL PROTECTED] wrote:
Why have f at all? When I'm writing about varx/var, why should I
write fvarx/var/f? What would be the difference? I think a
formula element is only needed for what is called display equations --
they are rendered out of
Alexey Feldgendler wrote:
What exactly is a formula?
If you ask this question from the point of view of browser developer or browser
itself,
then the answer is simple formula2 + 2 = 4/formula is formula, while
2 + 2 = 4 is plain text. If you ask it from the point of view of mathematician
or
On Thu, 08 Jun 2006 20:38:39 +0700, White Lynx [EMAIL PROTECTED]
wrote:
What exactly is a formula?
If you ask this question from the point of view of browser developer or
browser itself, then the answer is simple formula2 + 2 = 4/formula is
formula, while 2 + 2 = 4 is plain text. If you
Alexey Feldgendler wrote:
What exactly is a formula?
If you ask this question from the point of view of browser developer or
browser itself, then the answer is simple formula2 + 2 = 4/formula is
formula, while 2 + 2 = 4 is plain text. If you ask it from the point of
view of
Some people has prompted to reuse LaTeX.
People who want reuse LaTeX can do it, in the same way that one can
reuse existing jsMath. However, mixing of two different languages is
usually considered to be a bad practice. For example x 5 is okay in TeX
but prohibited in XML. A = 3$ amp; B = 5%
Ian Hickson wrote:
I would say MathML is not widely used because MathML doesn't work in
HTML, personally.
I do not know from where this idea get up. SVG is relatively popular and
implemented in many browsers, but the same browsers implementing SVG are
rejecting MathML. They are rejecting
Henri Sivonen wrote:
I think it is an economic problem rather than a technical problem.
Yes, this may be reason that a single man was able to do math in a browser
via XML-MAIDEN project in a few months, whereas dozens of others and even
entire communities cannot do it even after of 10 years.
Le 7 juin 2006 à 20:28, Ian Hickson a écrit :
For something as big as Mathematics, we want to simply re-use an
existing language, not invent a new one. Inventing a new language
for encoding content with as wide a problem-space as mathematics
would require months, as well as the time of
Le 8 juin 2006 à 4:24, White Lynx a écrit :
Michel Fortin wrote:
Use integral and bounds for integrals.
integral
bounds
sub0/sub
sup100sup
/bounds
3varx/var dvarx/var
/integral
There are at least 30 different operators that would require
On Thu, 8 Jun 2006, James Graham wrote:
White Lynx wrote:
Dan Brickley wrote:
It would also be both considerate and sensible (if anyone does want
to undertake such a task) to talk to the MathML folks first.
So far we are addressing problems that were invented and deployed by
James Graham wrote:
They have to use LaTeX to prepare documents
for publication,
it is the only language they know for typesetting
mathematics and, in general, the web is not their major target medium.
However, for current markup proposal, web is major target medium,
which means that if
[ Sorry for the delayed reply guys, being quite busy for a week and I have
to do some catching up on this thread. ]
Le Thu, 01 Jun 2006 19:22:50 +0300, [EMAIL PROTECTED]
a écrit:
Michel Fortin wrote:
One thing I know however is that the next time I'll have to put an
equation on a web
Le Thu, 01 Jun 2006 21:25:49 +0300, James Graham [EMAIL PROTECTED] a écrit:
But authors _will_not_ learn anything other than LaTeX.
Authors will learn something else _if_ that's proven to be better. Yes,
it's true authors don't generally jump on whatever comes new (that's the
reason
Le 5 juin 2006 à 9:51, White Lynx a écrit :
Sketch of the proposal is available, comments are welcome.
At this stage prose is far from being polished, but I hope it is
readable.
Ok, so let's comment. First I'd say I like the path you've taken. I
like the fact that you make it easy to
1 - 100 of 136 matches
Mail list logo
