>>>>> "MH" == Martin Hensel <[log in to unmask]> writes: >> These paragraphs made quite clear that the author didn't know a >> thing about TeX constraints (and is erroneous about space handling >> in HTML and XML as well). Obviously somebody who is new to >> technical details of existing markup languages. >> >> So the probability to find something worthwile in the rest of the >> text was not high enough to spend the time reading further. MH> Could you please explain to me, where I'm wrong with HTML and XML? You complained that TeX is inconsistent in its space handling. You mentioned in your paper the example of leading spaces in lines, used for indentation, that one can do with HTML/XML/other programming languages, but not with TeX. (1) At this moment, i.e., in the first two paragraphs of your content, you mixed already your topic. You didn't write about author interface any more, but about programmer's interface. (2) In the programmer interface, it's very easy to ignore spaces at all; many TeX programmers do it. So the problem is avoidable there. (3) In author-land, where I can see your problem actually, HTML has very similar problems to TeX. White space is collapsed to one space usually, but sometimes it's ignored, sometimes it's output. Now, I'd say that more TeX users understand TeX's space processing, than HTML users understand HTML space rules. Not least that's because in the HTML arena (a) one has to look for the processors, i.e., the browsers, and their space handling; and (b) one may want to look at the definition. Concerning the browsers: they simply don't implement the standard correctly. My staff regularily has to reject designs from so-called "Web designers" who rely on Dreamweaver and don't pay enough attention to browser-specific problems. Concerning the definition, HTML is still an SGML application and thus includes all the RS/RE cruft. Not made easier by the definition of block vs. in-line elements. IMO that implies that few people do really understand the formal definition. (If you haven't appreciated that yet, buy the SGML Handbook by Charles Goldfarb and wonder about the complexity lawyers can introduce when they define formal languages.) (4) XML doesn't collapse white space. That's the job of the processor. E.g., XSLT has even special syntactic facilities to handle elements where it should be ignored (sometimes ;-) and where it shouldn't. And the quotations in your email didn't address the problem in your document at all. Yes, you quoted HTML space handling, but no, you did _not_ show the differences to TeX where HTML is supposed to be more "regular" and easier to handle for the user. Yes, you quoted the XML white space definition, but no, you did _not_ address white space handling in PCDATA. Btw, you haven't even mentioned the real ideosynchrasies of TeX, like handling of ^^0d. That brings me to the real issue: Do you actually know that most of TeX's white space handling happens before tokenization, i.e., before the programming starts at all? You do know the basic principles of the TeX macro proces, do you? You did understand that some people on this list have their doubts and that they demand from you that you show your basic knowledge before they look at your proposals? I hope that I didn't trump on you too much. To ease your feeling, I'll refrain from further contributions to this thread -- as I've said, IMO the newsgroups are a better avenue to find user feedback about your ideas than this mailing list. Cheers, Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Joachim Schrod Email: [log in to unmask] Roedermark, Germany ``How do we persuade new users that spreading fonts across the page like peanut butter across hot toast is not necessarily the route to typographic excellence?'' -- Peter Flynn