- From: <osserman@math.mit.edu>
- Date: Sat, 28 Jun 2003 18:20:49 -0400
- To: www-math@w3.org
>You mean something that would place mathml fragments by coordinates >to overlay an image? It would be possible but rather a large extension I >think, experience with commutative drawing packages in latex suggests it >wouldn't really be enough, the better ones xypic, pstricks etc have a >certain level of feedback so the math typesetting and node positioning >can interact. You wouldn't get this via a mechanism that just allowed >positioning of fragments over an image, I think. Yes, this is exactly what I mean. At its simplest, it seems like it would be a very simple extension, both in terms of spec and of rendering. Am I missing something? I agree that there are potential issues with node positioning versus typesetting, and that for diagrams with nodes, or figures in progress, this would absolutely not be a standard one would want to author in directly, but it does seem to have a number of important practical advantages as far as actual deployment: it gives something close to an ideal method of describing a finished figure (granted, there are potential issues with linking text resizing to image resizing, or not, but I believe these would end up being of secondary importance), and it offers a reasonable backup plan for finished diagrams for authors who aren't willing to restrict their content to the Mozilla/Amaya audience for the foreseeable future. The bottom line is, if something along these lines isn't offered, what are the realistic options for figures and complicated diagrams? >Yes I was an algebraic topologist in a previous life, so I could >probably dig out a few commutative diagrams, what isn't so clear though >are requirements for commutative diagrams in a web/mathml context. >Is static layout sufficient or would a usable system require the layout >to change if window sizes/ font sizes were changed? >is css positioning adequate (I made some inconclusive experiments >some time back) SVG positioning is certainly adequate (if svg renderers >can actually cope with the svg foreign object mechanism to allow mathml >fragments) but is that overkill.... I really don't know the answer to >any of these questions. Ah yes, these are the subtler questions. In my experience with this sort of thing, most of the issues will only become clear after people start using the system widely. But aside from the issues I mentioned suggesting that CSS is definitely not adequate for reasonable applications (unless I was missing something important in my discussion in the prior email), I'd say off the top of my head (and to some extent, this is merely a matter of taste/opinion): Static layout is probably reasonable, and certainly far better than nothing. One might hope for a certain degree of resizing of the flexible elements (ie, arrows) to find the sweet spot for larger diagrams between overly crowded and not fitting in the window. Whether or not font resizing should force diagram resizing would be heavily implementation-dependent. My sense is that the ideal would be a system in which imbedded MathML could be resized to match font resizing on the rest of the page, and the location, if not the size, of the other elements would be adjusted according. And of course if the entire page were magnified, the diagram should be as well (but that's really the easy part). In implementations involved MathML anchored to parts of a bitmap, it would probably be acceptable to tie the size of the fonts in the bitmap to the size of the bitmap itself. Brian
Received on Saturday, 28 June 2003 18:20:51 UTC