Re: Labeled diagram and figure questions

>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