On Mon, May 6, 2013 at 6:14 PM, Robert O'Callahan wrote:
> wrote my thesis which also include a lot of semantics and type theory in
> FrameMaker, which was actually pretty good but is very dead.
>
Correction: it's alive! Amazing.
Rob
--
q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qy
Let me go on a bit of a rampage about TeX for a bit.
TeX is not a markup format. It is an executable code format. It is a
programming language by design! (It's a very poor programming language, but
let's ignore that for the moment.) You run a TeX program to generate the
rendered output. This has s
On Sun, May 05, 2013 at 04:04:44PM -0400, Ehsan Akhgari wrote:
> clang-format is a source code formatting tool developed by Google which can
> do automatic whitespace cleanup, vertical alignment and line breaking
> changes to C++ code. See this video [1] for a recent presentation about
> the tool
On Mon, May 6, 2013 at 10:52 AM, Benoit Jacob wrote:
> 2013/5/5 Robert O'Callahan
>
>> I would also say that one big difference between MathML and a
>> hypothetical TeX-based format is that MathML has a DOM and it's not clear
>> how to fit TeX into a DOM. That may not matter much for rendering, b
Benoit, you said you need proof that MathML is better than TeX. I think it's
the reverse at this point (from a web perspective -- you'll never get me to use
Word instead of TeX privately ;) ).
Anyway, let me try to repeat how I had addressed your original points in my
first post.
1.1. you make
On 5/5/2013 9:46 PM, Benoit Jacob wrote:
I am still waiting for the rebuttal of my arguments, in the original
email in this thread, about how TeX is strictly better than MathML for
the particular task of representing equations. As far as I can see,
MathML's only inherent claim to existence is "
Let me just reply to a few points to keep this conversation manageable:
2013/5/5
> Here are a couple of reasons why dropping MathML would be a bad idea.
> (While I wrote this others made some of the points as well.)
>
> * MathML is part of HTML5 and epub3.
>
That MathML is part of epub3, is use
On 5/5/2013 6:40 PM, Benoit Jacob wrote:
Well, I have written hundreds of pages of TeX; for sure, some large
equations would expand over more than one line of TeX, but I can't remember
going over more than 5 lines of TeX source (without custom helper macros)
per actual line of output, that that w
Is the idea of smartmake to make things also work for non-toplevel folders? For
example, if I edit .cpp only in content/base/src, it should be enough to
rebuild that and toolkit/library. However, `mach build content/base/src` won't
add toolkit/library in that case.
I think this would be a nice
Here are a couple of reasons why dropping MathML would be a bad idea. (While I
wrote this others made some of the points as well.)
* MathML is part of HTML5 and epub3.
* Gecko has the very best native implementation out there, only a few
constructs short of complete.
* Killing it off means Mozil
2013/5/5 Wesley Johnston
> > 1.2.2. TeX is very friendly to manual writing, being concise and
> > close to natural notation, with limited overhead (some backslashes and
> > curly braces), while MathML is as tedious to handwrite as any other
> > XML-based format. An example is worked out at
> >
>
> 1.2.2. TeX is very friendly to manual writing, being concise and
> close to natural notation, with limited overhead (some backslashes and
> curly braces), while MathML is as tedious to handwrite as any other
> XML-based format. An example is worked out at
> http://en.wikipedia.org/wiki/MathML#Exa
2013/5/5 Robert O'Callahan
> On Mon, May 6, 2013 at 3:38 AM, Benoit Jacob wrote:
>
>>2.1. MathML never saw much traction outside of Mozilla, despite having
>> been around for a decade. WebKit only got a very limited partial
>> implementation recently, and Google removed it from Blink. The fac
On Mon, May 6, 2013 at 3:38 AM, Benoit Jacob wrote:
>2.1. MathML never saw much traction outside of Mozilla, despite having
> been around for a decade. WebKit only got a very limited partial
> implementation recently, and Google removed it from Blink. The fact that it
> was just dropped from B
On 2013-05-05 1:20 PM, Gregory Szorc wrote:
On 5/4/2013 9:59 PM, Justin Dolske wrote:
On 5/1/13 8:41 PM, Ehsan Akhgari wrote:
Another disadvantage of project branches in addition to the ones
mentioned before is that it limits/delays the amount of testing that you
can get on Nightly and from all
clang-format is a source code formatting tool developed by Google which can
do automatic whitespace cleanup, vertical alignment and line breaking
changes to C++ code. See this video [1] for a recent presentation about
the tool in the LLVM Developers Conference (the slides are here [2]). And
it cu
It's not a joke.
Could you elaborate on this? In particular, as I wrote to the MathJax list,
I would be very interested in knowing what regressions the removal of
MathML would incur as far as MathJax is concerned.
Benoit
2013/5/5
> I'm not sure if that's a joke or complete misinformation abou
I'm not sure if that's a joke or complete misinformation about the topic. But
obviously the answer is that the MathML support must be preserved. The MathJax
team is strongly in favor of native MathML implementation.
___
dev-platform mailing list
dev-pla
On 5/4/2013 9:59 PM, Justin Dolske wrote:
On 5/1/13 8:41 PM, Ehsan Akhgari wrote:
Another disadvantage of project branches in addition to the ones
mentioned before is that it limits/delays the amount of testing that you
can get on Nightly and from all of the developers who run things like
fuzzer
2013/5/5 Justin Lebar
> Four points here.
>
> 1. We're assuming that MathJax is as good with MathML as it is without
> it, but perhaps we could ask the MathJax folks to comment on whether
> this is true. I'd certainly be a lot more comfortable dropping MathML
> if the MathJax folks said there wa
Four points here.
1. We're assuming that MathJax is as good with MathML as it is without
it, but perhaps we could ask the MathJax folks to comment on whether
this is true. I'd certainly be a lot more comfortable dropping MathML
if the MathJax folks said there was no point.
2.
> A suitable subse
Hi,
Summary: MathML is a vestigial remnant of the XML-everything era, and we
should drop it.
***
1. Reasons why I believe that MathML never was a good idea. Summary:
over-specialized and uniformly inferior to the pre-existing,
well-established standard, TeX.
1.1. MathML is too specialized: w
22 matches
Mail list logo
