From: Nico Poppelier <nico@valacar.elsevier.nl>

Date: Fri, 10 May 1996 09:33:26 +0200 (MET DST)

Message-Id: <199605100733.JAA25198@thorin.elsevier.nl>

To: w3c-math-erb@w3.org

Date: Fri, 10 May 1996 09:33:26 +0200 (MET DST)

Message-Id: <199605100733.JAA25198@thorin.elsevier.nl>

To: w3c-math-erb@w3.org

I've found the report below on the Web server of the ISO TC46/SC4/WG6 (owner of the site: Eric van Herwijnen). For your convenience I've removed the HTML tags and mailed it you. I'm getting a little bit concerned with the lack of progress in this group and also with the impression Dave has given during the Illinois workshop. *Are* we working on something here or are we not? Nico ------------------------------------------------------------------------ Notes on SGML Math Workshop Held as part of the University of Illinois Digital Library Initiative (UIUC DLI) University of Illinois at Urbana-Champaign May 1, 1996 Written up by Evan Owens, Electronic Publishing Manager, Journals Division,University of Chicago Press The workshop was very well attended; discussion was lively. The plan of the meeting was presentations in the morning and early afternoon followed by an extended period of group discussion. As I understand it, the reason for calling the workshop was that the UIUC Digital Library Project was having difficulty getting the SGML Math supplied by the publisher partners to be rendered effectively on screen by SoftQuad's Panorama. So the immediate goal was to solve that problem. The University of Chicago Press is not a participant in UIUC DLI project, so it is possible that I may have misstated some of the background. PART 1 - PRESENTATIONS (1) Stephen Wolfram, inventor of Mathematica The relevance of Mathematica to SGML Math becomes apparent in the later discussion. Wolfram hosted lunch and dinner for the attendees. Wolfram Research has spent 5 years and millions of dollars to develop typesetting capabilities of Mathematica. They believe that it can now typeset math to the level of the best commercial system; its page layout capabilities are comparable to WordPerfect or Word and not quite as good as Pagemaker. Unlike TeX, Mathematica can gracefully break formulas into lines without operator intervention because it understands the structure of the math; if it didn't understand the structure, it couldn't calculate. Also it knows how tightly the operators are bound. Input is palette, keyboard, and strings; has full internal Unicode support. Mathematica has an open architecture for customizing. All formatting styles are pairs: screen and paper style. Uses monospaced fonts on screen for legibility. To interpret math, it needs to know unambiguously the role of every element in the formula. E.g., is "e" an exponential constant or a variable named "e". Mathematica keeps additional information in its internal representation of the math. Traditional text book math cannot always be made unambiguous. Mathematic converts from traditional form notation to its internal format using a large collection of heuristic rules; this doesn't always work. When editing in traditional notation, one can easily make something that can't be converted back; their editing environment will prompt about this. It can handle also handle abstract notation, though it needs to given processing rules. Inside Mathematica, everything is a symbolic expression. Traditional form math is a set of transformation rules. Mathematica's spacing and display is much better than TeX's. It can export math to gif, eps, pict, TeX, HTML, speech, or to ASCII that can be reloaded into Mathematica. Export to/from TeX is done using transformation rules. They have a version that takes math input, sends it to a math server that renders it and returns GIFs; also an inline app to render math into ActiveX and Netscape inline addins. Wolfram Research would like to work with SGML Math community. Mathematica notebooks are are markup language; one could map the structure of the entire notebook (not just the maths) into an SGML DTD. (2) Dave Raggett, WWW Consortium From other comments later, it appears that the WWW Consortium math committee is split and that Dave Raggett's ideas are just one proposal under consideration. Raggett: Web vendors not interested in Math Special review board of Wolfram, Adobe, AMS trying to develop open spec. His proposal has nothing to do with SGML at all. (My question to him later was, was it fair statement to say that this proposal is to punt, to take math entirely out of HTML; his answer was yes). His plan is to use SGML notations and allow documents to specify the server (URL) where a set of rules (knowlege base) would be available to render the math. The actual HTML would be very simple: perhaps only three tags: inline formula, display formula, and a tag to identify where the render was to be found. Then, inside the tag, any kind of notation could be used. His demonstration used prolog. This proposal was not well received by the audience; comments later included, how many years will it take until this is working; and isn't this just avoiding the issue? (3) Roy Pike, Semantic Math He presented his paper; text is available elsewhere so I won't repeat it here. He came down hard in support of semantic math as the solution to all problems. Comments from the audience seemed to be that this was a good long term goal but didn't solve the problem at hand: rendering math for screen display. It was apparent that semantic math and Mathematica had a lot in common; Pike had been to visit Wolfram and has apparently seen their common interest: a robust semantic math would be a format that Mathematica could easily export to. Another important comment (from me and others) was that it is unrealistic to expect that we are going to be able to afford to disambiguate math in a production environment; if we can't get this from the authors then it isn't going to work. Pike seems to favor working on the assumption of a perfect world; unfortunately most of us in publishing living in very imperfect worlds. (4) Publisher Perspectives: Evan Owens, UCP/AAS I spoke very briefly on what I see as the important issues: SGML math won't work unless we have tools to get the math from the authors and to edit it robustly. We need authoring and editing environments or appropriate translation tools. I also describe our project and how we convert math from LaTeX to SGML to typesetting systems and back. (5) Publisher Perspectives: AIP Tim Inglesby and Scott Johnson of the AIP spoke at some length about their work with SGML and ISO 12083 math. (6) Paul Grosso, ArborText Paul proposed that the semantic layer be applied on top of the current ISO 12083 DTD through attributes; I asked whether this would be comparable to the ICADD stuff; he said that he was not specifically thinking of architectural forms but that was a possibility. There were some reservations expressed about this from the DLI team in that their search engine searches on tags not attributes; I pointed out that one could easily generate special output for searching and that there were advantages to do so. Paul talked about how SGML Open had dealt with tables; he proposed that SGML Open be used as a forum for working out a minimum subset of math that all vendors would support. (7) Paul Topping, Design Science Their product is MathType, an equation editor that is used in MS-Word and other products, including Corel Ventura. Their new version in Unicode based and will support drop in translators. They are currently implementing the translator architecture and have not started working on an ISO 12083 to Mathtype and return translator. (8) Murray Malone, Panorama Didn't say much except if you identify the problems, we'll fix them. Said a lot more later in the discussion. Part II. Discussions The scheduled discussion period turned into a real free-for-all; this summary will reflect the confused state of the discussion. I've grouped some of the discussion logically rather than chronologically to help sort it out. Paul Grosso (ArborText) was not present for this discussion, alas. It was clear that we were going to have some major differences of opinion. To break the ice, we started with a somewhat less controversial topic. (1) Searching Mathematics It was argued that complex searching of mathematics was comparable to the kind of searching of chemistry that is done in Chem Abstracts. That kind of searching depends on knowledge that would only be available in semantic math (or Mathematica). This was seen as an argument in favor of <a href="pike.htm">Roy Pike's proposal</a>. Side issue: it was argued that it will be unicode and not SGML entities that will make complex searching possible. (Mathematica is already unicode based.) (2) Legibility of Screen Math Long discussion of the inherent problems of displaying math or other complex text on screens. Mathematica defended their mono-space math screen fonts. AIP argued that print quality was necessary and that Panorama was totally unacceptable. One of the DLI people had written a dissertation on the screen display of maths. It was pointed out that horizontal scrolling is very bad; ditto zooming in and out; that text that wraps to the width of the screen is highly desirable. This entire discussion seem obvious to me; I've said from day one that if we were designing a journal for screen reading, it wouldn't have two narrow columns. This is a major strength of Mathematica, that it can robustly re-break equations to various screen widths! (3) Short Term versus Long Term There was discussion of some immediate solutions such as using applets: Java, OLE, ActiveX or working out the bugs in Panorama, versus the long term solution of semantic math. AIP made the point that they (and others) have to have a solution now; they have math intensive journals that need to go on line. Java Applets apparently don't pass font information back to the viewer (e.g., baseline) so they don't work well for inline math. Work on style sheets for HTML might solve this eventually. (4) Mathematica's Offer It was proposed that it would be possible to use the plug-in reader version of Mathematica to render math. Mathematicas format is published but proprietary. Stephen Wolfram offered to allow an ISO standard that would closely correspond to their work on the semantics of math. Wolfram Research would agree not to sue. Mathematica claims that it doesn't take a lot of intervention to move from traditional math to semantic; their heuristic rules help considerably with this. Mathematica has taken a journal produced in TeX, Complex Systems, and converted it entirely to Mathematica notebooks with active math. At one point in the discussion, Wolfram offered to just the solve the problem for us, to do the development on a semantic math DTD that would map in and out of Mathematica's internal format. The people from SoftQuad didn't like this at all, as this would effectively cut them out of the market. COMMENTARY: of course, that is going to happen anyway as active math is going to be much more desirable than static math. (5) Who's doing what with Math The room was polled as to who is doing what with math of the organizations present: - IEE is using embedded TeX - AMS is entirely TeX - AAS (us) is SGML math, but AAP DTD - Beacon Graphics (various projects) uses AAP math DTD - AIP is using ISO 12083 math post-typesetting (6) SGML OPEN Model Murry Malone (SoftQuad) proposed that the model used for tables by the SGML OPEN be followed: that the vendors get together and agree on a subset of functionality that everyone will support. The implication was that this would be visual math with semantic as the optional layer. (7) DECISIONS AND PLANS At the end of the discussion it was proposed that the short term goal be better implementation of the current ISO 12083 math and that the long term goal be semantic math. (7A) Short Term It was proposed that the NSF fund another workshop, this one on ISO 12083 Math implementation, that we get together and work up documentation on proper coding practices. Murray Malone offered the SGML OPEN summer meeting in Montreal as a venue for such a meeting. There is a risk that such a meeting will degenerate into an argument with the AIP about how to code ISO 12083 math, since they are the only people doing at the moment. But it might be useful. (7B) Long Term There was discussion about whether the meeting should vote to support Pike's proposal. The eventually consensus was to not vote one way or another as the proposal was too new. (8) Comments and Observations Odd meeting in various ways: - strong influence of Wolfram Research (lunch, dinner, and lots of bodies) - lack of preparation/communication between Softquad, the DLI project, and AIP - large turnout shows real interest in topic, but very few people seem willing to actually do SGML math My personal opinion is that the future of SGML math rests entirely on the tool makers. Right now, the only serious SGML math (in the USA) is being done using the AAP DTD because that is what ArborText has implemented. Without tools to create, edit, and present SGML math no one is going to bother with it. AIP even said that they had to write a tool to convert ISO 12083 math to TeX so that they could render it and see if they are coding it correctly. My guess is that Wolfram will decide that an SGML input output filter isn't any harder than their existing TeX filter and they will move ahead. That will shape the future discussion; as has been amply demonstrated on the internet "working code wins" and not necessarily international standards. ------------------------------------------------------------------------ Dr. Nico A.F.M. Poppelier Elsevier Science, APD, ITD Email: n.poppelier@elsevier.nl. Molenwerf 1, 1014 AG Amsterdam Phone: +31-20-4853482. The Netherlands Fax: +31-20-4853706. ------------------------------------------------------------------------ The truth, the whole truth, and nothing but the truth. And maybe some compromises.Received on Friday, 10 May 1996 03:43:59 UTC

*
This archive was generated by hypermail 2.4.0
: Saturday, 15 April 2023 17:19:56 UTC
*