> On Thu, Mar 2, 2023 at 12:53 PM David A. Wheeler <[email protected]>
> wrote:
> 2. The text just runs off to the right, instead of going over multiple lines,
> making long ones unreadable. That's important but easy for the non-MathML
> case (just a little CSS), though I don't know how hard that is for
> MathML/MathJax.
>
> On Mar 2, 2023, at 4:33 PM, Mario Carneiro <[email protected]> wrote:
> This is a pretty fundamental problem with MathJax style displays, and I don't
> have a good solution. LaTeX generally isn't great about automatic line
> breaking inside mathematics, but metamath routinely involves very large
> formulas, so although this looks good for the mid-sized examples the large
> ones really suffer. A related issue is that mathjax isn't really able to cope
> with having thousands of large and complex formulas on a page and the CPU
> time / draw time really spikes on some of the examples. For MM0 I'm planning
> to mostly just sidestep this issue by using ASCII-first displays, perhaps
> using unicode or programming fonts with ligatures but not much more. That way
> line breaking is limited to just pretty printing which can feasibly be
> written with a handcrafted JS library.
That makes sense. I don't *object* to beautiful presentations, but if that's
unsolved, we could generally prefer pointing to the Unicode versions (where
long formulas are easily handled).
MathJax is well aware of the need for automatic line breaking. They hope to
have s version 3 that resolves it:
https://docs.mathjax.org/en/latest/output/linebreaks.html
https://stackoverflow.com/questions/40628064/mathjax-automatic-line-breaking-when-resizing
... I'm fine with letting them solve the problem & we use their solution. I
don't know when they'll actually do that (if ever).
>
> 3. I think it's important we support existing URLs. That's easy with
> pregeneration, just rename to taste. If this is dynamically generated, that
> would require some changes to support the .html endings *and* support
> returning static pages.
>
> I don't think this will be difficult no matter what we do, since we can set
> up all the necessary routing in nginx.
Not *difficult*, but some are harder than others if we *dynamically* generate.
In nginx you would typically specify a location pattern as a parameter, and if
it matches,
call a program (e.g., using fastcgi). Here's an example:
https://www.nginx.com/resources/wiki/start/topics/examples/fastcgiexample/
You'd *like* to have the web server directly serve static files (they're good
at that!),
but currently directories like "mpeuni" have a lot of files, some of which
might be dynamically generated
while others are probably statically generated. Typical websites put them in
separate directories,
to make it easy to tell them apart.
If they're all dynamically generated via the same program, or all statically
generated, then that's moot.
> I am not above potentially making mpegif redirect to mpeuni though (or a
> future URL scheme), or serving only dynamic pages for deprecated formats. I
> think we should try to make https://us.metamath.org/mpeuni/areacirc.html link
> to a theorem about the area of a circle in perpetuity but not necessarily
> serving exactly the same HTML as it does today.
Agreed. Heck, even if we stay with metamath-exe I would think we'd be open to
improvements.
But since many people link to our pages, I want them to keep working to get
"something interesting".
> 4. This one omits many of the capabilities of the metamath-exe generator,
> e.g., compare with <https://us.metamath.org/mpeuni/areacirc.html>.....
> By the way (and I realize this wasn't directed at both tools), mm-web-rs was
> designed explicitly as a carbon copy replacement for metamath-exe generation,
> and supports all of these things. (Thierry's generator as I understand it is
> more of an exploration of what we could have if we break with the traditional
> format.)
> IIRC if you open them in a browser side by side the result is identical
> except for distinct variable groups, which use a different (arguably better)
> heuristic for collecting $d pairs into cliques. (Exact clique cover is an NP
> hard problem, though, so some amount of approximation is required.)
Better is better!
> I think the variable coloring heuristic uses some hard-coded typecode names
> so it is not suitable for general databases; there are actually quite a few
> aspects of the web site generator that are tailored for set.mm which should
> probably use $t commands instead.
We could start with hard-coding, then move towards supporting a general form.
I agree that in the long term we want to be general.
I suspect type code coloring primarily useful to new users... but since we *do*
want to new users/readers, that's still relevant. We could even add it later,
but it also doesn't seem *that* hard to implement (at least hard-coded).
> I would link an example here, but I'm not sure where to host it. On that
> note, we might consider a place on the main website for experimental stuff
> now that us2 is down. Do you know if there is a spot which already works for
> this? I'm thinking of some place where it is safe to just drop files and have
> them persisted across website builds, with a URL that implies that they may
> go offline at any time.
I can trivially create the name "experimental.metamath.org" (or whatever you
like), and point it somewhere. The real question is, where should it point?
* It *could* point to the metamath.org site. It doesn't have a lot of space for
many more copies, and if you're not ready for it to get attacked that'd be a
bad thing. That requires no new money.
* You could set up a site literally anywhere else. A linode node costs
$6/month. Heroku has a low-cost plan (not free though).
--- David A. Wheeler
--
You received this message because you are subscribed to the Google Groups
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/metamath/43D8322B-BE83-4BD7-9CC0-320C5B08679C%40dwheeler.com.
