Skip to content
This repository has been archived by the owner on May 2, 2018. It is now read-only.

Preamble support breaks (Theorem environment is broken) #429

Open
rspuzio opened this issue Sep 24, 2013 · 10 comments
Open

Preamble support breaks (Theorem environment is broken) #429

rspuzio opened this issue Sep 24, 2013 · 10 comments

Comments

@rspuzio
Copy link

rspuzio commented Sep 24, 2013

If one types

\newtheorem{defn}{Definition}

in the preamble and

\begin{defn}
Definition
\end{defn}

in the body, it should typeset a definition. Instead,
it writes a big red "\defthm" at the top of the output
and a "\defn" where the definition should have been.
For an example, please see the test object:

http://planetmath.org/testobj

@holtzermann17
Copy link
Contributor

Thanks Ray, that sounds like a LaTeXML configuration issue. @dginev what do you advise?

@dginev
Copy link

dginev commented Sep 24, 2013

Compiling this file locally works well, both with pdflatex and latexml. However, is there something being sent to LaTeXML besides that file? The file attempts to be self contained, but if another preamble is set additionally things might break badly.

Indeed, pasting the source at http://latexml.mathweb.org/editor works as expected. You probably need to not send an additional preamble though.

@dginev
Copy link

dginev commented Sep 24, 2013

OR, am I missing the separation here? I am looking at the source tab at: http://planetmath.org/node/42485/source
Is that what I should be looking at?

@holtzermann17
Copy link
Contributor

http://latexml.planetmath.org/editor also gives good results, using the
"Metadata" profile and pasting in the source code. And I've just gotten
the article to build without an error after adding a % to the end of body.

What might be going on: maybe @rspuzio has a default preamble that doesn't
include amsthm...? No, I tried switching users and as rspuzio I added
another % and the article is still working.

It seems like a transient bug. Can we reproduce in another article...?

@rspuzio
Copy link
Author

rspuzio commented Sep 25, 2013

It definitely looks like there is something flaky around here.
I saw that, after Joe's fixes, everything looked good. To
test it further, I added a theorem environment and a theorem.
It checked out fine with the LaTeXML web service, but on PM it
is a worse disaster --- now it claims not to understand any
definitions made in the preamble, including foo and goo, which
have nothing to do with amsthm.

@holtzermann17
Copy link
Contributor

I edited the article again (logged in as you) and fixed it again. So, maybe we're starting to narrow this down to a... ¿browser specific issue? What browser are you using?

@dginev
Copy link

dginev commented Sep 25, 2013

This can't be browser specific, it's LaTeXML failing due to the input. My only gues is that the preamble and the article body aren't playing well together (or what is sent to LaTeXML ends up invalid somehow).

@holtzermann17
Copy link
Contributor

My thought was that Ray's browser is assembling things wrong (e.g. there's a little Javascript involved with the way preambles are displayed, maybe that's the issue?). The thing is - I sent the (")same(") preamble and body through Planetary, logged in as the same user, and got back a correctly rendered result.

But of course ultimately I agree with you Deyan, that whatever is sent is producing a LaTeXML error.

@rspuzio One thing we could do is set up a time to do some "live debugging" - you can press save again and trigger the error, and I can see what's happening in the backend, so we can at least see what's getting assembled and sent.

@rspuzio
Copy link
Author

rspuzio commented Sep 25, 2013

One thing we could do is set up a time to do some "live debugging"

Let's do that this Saturday.

@holtzermann17
Copy link
Contributor

@rspuzio and I tracked this down to a problem with previewing, e.g. as described in #281 (which I haven't fixed yet). Basically, preambles aren't getting handled right in the preview, and then if you save what you previewed, you get the red ink...

Since I almost never preview anything, that's why I hadn't seen this bug before. Now that it's traced properly, it should be relatively easy to fix.

@ghost ghost assigned dginev Dec 16, 2013
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants