| |||||||||||||
Microsoft: Boiling Frogs Since 1975Microsoft: Boiling Frogs Since 1975Posted Apr 16, 2012 11:51 UTC (Mon) by anselm (subscriber, #2796)In reply to: Microsoft: Boiling Frogs Since 1975 by khim Parent article: Paoli: Microsoft will engage with the open source and standards communities
You mean, like ISO/IEC 29500 (the Office Open XML standard)? That would be the very huge one that not even Microsoft Office actually implements, and that could only be passed at ISO by means of a Microsoft sleazefest which made the whole standards process a farce. Yep, sounds like a genuine effort to me.
(Log in to post comments)
Microsoft: Boiling Frogs Since 1975 Posted Apr 16, 2012 12:45 UTC (Mon) by khim (subscriber, #9252) [Link] That would be the very huge one that not even Microsoft Office actually implements, and that could only be passed at ISO by means of a Microsoft sleazefest which made the whole standards process a farce. The pass at ISO is totally different thing, this is not where software engineers are involved. As far as completeness is concerned OOXML standard is quite good: in many aspects it's better defined then, e.g. ODF. The fact that it's not implemented by anyone is separate aspect, as I've said before: while technical guys do their work admirably their managers know what they need to do even better. Typical Microsoft-standard is complete enough and detailed enough to make sure it can be used for PR without fraud charges (this is where technical guys are needed and where they do good work), but genuine interoperability is a danger and should be avoided as much as possible. Actually it's possible that MS Office does implement the ISO standard. ISO added a lot of erratas to the document after retification with justifications which basically say: OOXML standard says A, but MS Office does B thus we need to change OOXML to make compatible with MS Office. This is good technical work, but obviously this is pure PR, interoperability is not even considered.
Microsoft: Boiling Frogs Since 1975 Posted Apr 16, 2012 14:29 UTC (Mon) by anselm (subscriber, #2796) [Link] Typical Microsoft-standard is complete enough and detailed enough to make sure it can be used for PR without fraud charges (this is where technical guys are needed and where they do good work), but genuine interoperability is a danger and should be avoided as much as possible. Right. So when Microsoft was forced by the European Commission to document the SMB protocols, the outside expert that Microsoft itself had selected to oversee compliance rejected their documents as unusable so these needed to be redone. Way to go, Microsoft. Actually it's possible that MS Office does implement the ISO standard. ISO added a lot of erratas to the document after retification with justifications which basically say: OOXML standard says A, but MS Office does B thus we need to change OOXML to make compatible with MS Office. This is good technical work, but obviously this is pure PR, interoperability is not even considered. I'd say this is being done to keep OOXML a moving target that only Microsoft can implement (if anybody). Remember that OOXML includes features that can only be implemented in a conforming manner by essentially reproducing weird bugs of obsolete Excel releases. This is abominable technical work as far as I am concerned. One would hope that any engineer with a shred of self-respect would resign in disgust before allowing something like this to be published on their watch, no matter what the managers say. Also note that huge numbers of technical issues were basically ignored while the standard was being ramrodded through the ISO committee. If the standard had been any good in the first place, this would not have been that much of an issue. Again, abominable technical work preparing the standard to begin with. Microsoft says that the next version of Microsoft Office is supposed to implement OOXML properly. Whether that will actually happen is anybody's guess.
Microsoft: Boiling Frogs Since 1975 Posted Apr 16, 2012 19:50 UTC (Mon) by khim (subscriber, #9252) [Link] Remember that OOXML includes features that can only be implemented in a conforming manner by essentially reproducing weird bugs of obsolete Excel releases. Compatibility is a bitch, yes. This is abominable technical work as far as I am concerned. Why? If the goal is to faithfully preserve the existing corpus of documents (and this was justification given for OOXML existence when ODF was already ratified as ISO standard) then something like this is basically the only way. One would hope that any engineer with a shred of self-respect would resign in disgust before allowing something like this to be published on their watch, no matter what the managers say. I think you've mixed engineer (who's by definition is concerned with applying scientific knowledge, mathematics and ingenuity to develop solutions for technical problems) with someone else. Perhaps scientist from Ivory tower? That's separate occupation. Engineers are often do things like this (as a couple of examples: Chrome's user-agent string and HTML5 content sniffing) and when they work - they are justifiably proud. Also note that huge numbers of technical issues were basically ignored while the standard was being ramrodded through the ISO committee. If the standard had been any good in the first place, this would not have been that much of an issue. Actually standard was in quite good shape if you'll consider it's size and time given to develop it. Again, abominable technical work preparing the standard to begin with. Nope. It was just pushed through the ISO way before it was polished enough. This is not a technical issue. Technical issues are slowly fixed as I've pointed out above. Once again: Microsoft knows how to develop standards. It knows it very well indeed. But you must always keep in mind that it's goal is PR, not interoprability.
Microsoft: Boiling Frogs Since 1975 Posted Apr 16, 2012 19:58 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
> Compatibility is a bitch, yes.
but where 'compatibility' is defined as "implement this the same way it worked in Excel 95" with no documentation about what that way is, it's absolutely impossible for anyone other than Microsoft to ever be complaint with the standard
the fact that such wording was allowed in a standards document says a lot about the poor quality of the standard.
Microsoft: Boiling Frogs Since 1975 Posted Apr 16, 2012 20:45 UTC (Mon) by khim (subscriber, #9252) [Link] but where 'compatibility' is defined as "implement this the same way it worked in Excel 95" with no documentation about what that way is, it's absolutely impossible for anyone other than Microsoft to ever be complaint with the standard Sure. And that's the point! The fact that engineers added these bits means they really care about backward compatibility and the fact that managers were able to get ISO approval means that they have done admirable job obtaining this elusive seal of approval. To edit old documents you really need all these bits which instruct you to “calculate line heigh like a WordPerfect 6.x” or to “emulate Word 5.x for Macintosh small caps formatting”. And engineers absolutely can document them, but why should they if ISO is already satisfied? What's your problem? Ah, you mean, you can not use this standard in any other program? Sorry, was never in the cards. It's not for you, it's for Microsoft's PR department. This is how Microsoft does most standards. Recall VML/SVG again. Microsoft only implements standards faithfully if there are real danger that it's creations will be just thrown away if some kind of standard will not implemented. Even then it carefully checks if it's actually needed to create something interoperable or just something certified. Microsoft, of course, much, much, MUCH prefer the latter. Think Windows NT 3.1 with it's POSIX subsystem which was needed to circumvent POSIX-compatibility requirements by certain government institutions. POSIX programs had no access to GUI because it was not required to get the certification. This nicely solved both needs: Windows NT was approved because it was POSIX-compliant and it was never used as POSIX-compliant OS because this mode was deliberately crippled. OOXML is the same just in revers: Microsoft created the standard and then pushed it (and genuinely improved it!) till it got an ISO stamp of approval. Then stopped because, you know, mission is accomplished, you only need to keep the OOXML work active enough for the ISO to not withdraw the ratification. the fact that such wording was allowed in a standards document says a lot about the poor quality of the standard. Come on. When ODF was ratified as ISO standard it contained similar worlds WRT the whole spreadsheet language definition! If you start to expand the scope of the standard then you risk expanding the work till it'll taked decades and will just be eventually abandoned. The difference comes later: OOXML was basically frozen (and noone, except Microsoft, knows how to “emulate Word 97 east asian line breaking”) while ODF was developed further and by now version 1.2 includes extensive documentation - but this part comes later and, as I've said, has nothing to do with the quality of the Microsoft's engineers.
Microsoft: Boiling Frogs Since 1975 Posted Apr 16, 2012 22:00 UTC (Mon) by anselm (subscriber, #2796) [Link] And engineers absolutely can document them, but why should they if ISO is already satisfied? The point here is that ISO wasn't actually satisfied (in a meaningful way). People identified all sorts of technical problems with the proposed OOXML standard but Microsoft had carefully arranged to (a) allow as little discussion of the technical issues as possible and (b) have various ISO countries which up to that point had not shown any interest whatsoever in the standardisation of office document formats send voting representatives who just incidentally happened to be employed by Microsoft partner companies. This is what allowed the standard to pass, not its technical excellence (which wasn't anything to write home about in the first place). the fact that managers were able to get ISO approval means that they have done admirable job obtaining this elusive seal of approval. There are various adjectives in the English language that one might use to describe this sort of behaviour, but at least as far as I'm concerned »admirable« is not among them. »Reprehensible« or »sleazy« would be more to the point.
Microsoft: Boiling Frogs Since 1975 Posted Apr 16, 2012 22:20 UTC (Mon) by khim (subscriber, #9252) [Link] The point here is that ISO wasn't actually satisfied (in a meaningful way). ISO ratified and published the standard. This finishes the story. Or rather it finishes the first part: now the task is to keep it on back-burner with just enough activity to keep it alive and not provoke ISO to withdraw it's approval. This task also goes fine. This is what allowed the standard to pass, not its technical excellence (which wasn't anything to write home about in the first place). Sure. But all standards have shortcomings. ODF has many holes, too (just the latest wart), especially ODF 1.0 (which was ratified by ISO, remember?), so why are you so hostile WRT OOXML technical excellence? The sad fact in OOXML saga is the simple truth: ODF was just as immature (perhaps even more immature) when it was approved by ISO. Of course there was significantly more urgent need because previous ISO abomintation was widely rejected by office suites, but as far as pure technical side is concerned… no, ODF wasn't anything to write home about.
Microsoft: Boiling Frogs Since 1975 Posted Apr 16, 2012 22:47 UTC (Mon) by anselm (subscriber, #2796) [Link] But all standards have shortcomings. ODF has many holes, too (just the latest wart), especially ODF 1.0 (which was ratified by ISO, remember?), so why are you so hostile WRT OOXML technical excellence? Personally I would be very reluctant to ascribe any sort of »technical excellence« to a standard that takes up 7000 pages and still is not sufficient to enable third parties to implement conforming software – which ODF, for all its faults, appears to manage well, and at a fraction of the size.
Microsoft: Boiling Frogs Since 1975 Posted Apr 16, 2012 23:05 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
Have you checked the recent ODF standard with all referenced standards? It's far more than 7000 pages.
Microsoft: Boiling Frogs Since 1975 Posted Apr 16, 2012 23:31 UTC (Mon) by anselm (subscriber, #2796) [Link] Yes, but most of that (like the XML specification) is independently useful. Where I come from, building on other existing standards is generally considered a Good Thing™. On the other hand, Microsoft apparently came up with enough new stuff for OOXML – stuff that does not appear to be standardised elsewhere – for them to take 7000 pages to write it all down. If you add pre-existing stuff like the XML specification, which the OOXML standard also references but does not actually include, the document set gets bigger still.
Microsoft: Boiling Frogs Since 1975 Posted Apr 17, 2012 1:15 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
>Yes, but most of that (like the XML specification) is independently useful
Yeah? How about SVG which has exactly _zero_ fully-conforming renderers? And now they've decided to play the favorite OpenSource game and rewrite SVG 2.0 almost from scratch. I've worked with VML back in early 2000-s and it was many times easier to write a simple renderer for it.
Then there are questions of CSS in ODF, but my comments would be unprintable.
Frankly, supporting a subset of OOXML without crazy magic formatting options has about the same complexity as supporting ODF. Except that OOXML is internally more consistent.
Now, OOXML is clearly not ideal. But it's OK-ish, and ISO quite fairly standardized it on its technical merits.
Microsoft: Boiling Frogs Since 1975 Posted Apr 17, 2012 5:33 UTC (Tue) by khim (subscriber, #9252) [Link] Except that OOXML is internally more consistent. Only someone with agenda can claim that these three lines (which mark test as red in .docx, .xlsx and .pptx) are consistent: No, OOXML is most definitely not consistent. It encodes warts of all the legacy documents quite well (as it was the goal of it's creation) but consistency? Not in the cards. It was not the goal of it's creators, thus you hardly can fault them. Now, OOXML is clearly not ideal. But it's OK-ish, and ISO quite fairly standardized it on its technical merits. Note: I never said it. OOXML is internal Microsoft's format and it's one of the better documented proprietary formats. Usually ISO was quite reluctant to standardize such things because, frankly, they have only limited appeal for anyone except the primary author. Usually just some subset was standardized (such as PDF/X, PDF/A, PDF/E, PDF/VT, or PDF/UA). The fact the full pig was pushed through ISO tarnishes it's reputation in IT industry beyond repair, but this is separate issue from the standard's technical quality.
Microsoft: Boiling Frogs Since 1975 Posted Apr 16, 2012 23:23 UTC (Mon) by khim (subscriber, #9252) [Link] Personally I would be very reluctant to ascribe any sort of »technical excellence« to a standard that takes up 7000 pages and still is not sufficient to enable third parties to implement conforming software – which ODF, for all its faults, appears to manage well, and at a fraction of the size. Why should it achieve this goal if it was not designed for that? It was designed to preserve formatting of the old documents - and it does it well. I've seen plenty of documents which survive .doc⟷.docx or .xls⟷.xlsx roundtrip just fine but completely lose formatting when roundtripped as .doc⟷.odt or .xls⟷.ods. Some of them keep formatting when opened in LibreOffice even, yet they still breaks apart when saved as .odt or .ods! Once again: OOXML have achieved all goals it was designed to achieve. It's pretty compatible with legacy formats (when MS Office is used) and it's pretty compatible with other Office suites (such as iWorks) which are developer with Microsoft's help. Thus it obviously achieved all the goals it was set to achieve and as such is quite professional and successful standard. You bitch about the fact that it does not make it possible to create credible competitor for the MS Office - but this, too, was the important goal and it was successfully achieved so what's your problem? You don't like situation when standards are used to stifle competition? This is not technical problem with the standard, sorry.
Microsoft: Boiling Frogs Since 1975 Posted Apr 16, 2012 23:37 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
it's hard to say if it's really compatible with all the legacy formats as there isn't any software that fully implements it (Even MS Office doesn't fully implement it, at best it only every implemented some draft version)
but it's easy to define a format with 100% backwards compatibility on paper.
File format, one line of ASCII text followed by an additional block of data who'ss format is identified by the line of text.
the line of text can have the value
'ODF 1.0' in which case the second block is in the format specified by PDF 1.0
'Word 2007' in which case the second block is in the format of Microsoft Word 2007
etc.
In a couple of pages I could specify a format with better compatibility than anything that Microsoft has ever even thought about.
and it would be about as much use as the OOXML format in terms of actually allowing anyone to implement it
your repeated claims that OOXML has achieved success only work if you completely ignore all technical measures of success and only consider political and marketing shenanigans, and even then there was enough of a stink over this that it's only a qualified success at best
Microsoft: Boiling Frogs Since 1975 Posted Apr 17, 2012 5:13 UTC (Tue) by khim (subscriber, #9252) [Link] but it's easy to define a format with 100% backwards compatibility on paper. Sure. That's why I'm talking about real world documents (mostly financial), not about some abstract paper. and it would be about as much use as the OOXML format in terms of actually allowing anyone to implement it It'll be much harder to implement it even partially, but yes, you'll achieve compatibility goal. ODF have not done it and thus it's not compatible. It's as simple as that. your repeated claims that OOXML has achieved success only work if you completely ignore all technical measures of success Bullshit. I've given you a criteria: take a bunch of old documents from some collection (private and/or government one), convert them to ODF and OOXML, convert them back, watch the result. This is technical criteria (it was guiding policy for Unicode standard BTW, only there they converted plain text documents in different encodings back and forth). OOXML works (as implemented by MS Office), ODF fails (as implemented by LibreOffice). Most of the failures are caused exactly by refusal of ODF to support legacy warts which you so despise.
Microsoft: Boiling Frogs Since 1975 Posted Apr 18, 2012 21:15 UTC (Wed) by vonbrand (subscriber, #4458) [Link] For a fair comparison, convert StarOffice documents to ODx and back, not MSFT cruft. And BTW, the "conversion" there is mostly wrapping/unwrapping, there is no real "conversion." Or use Office to convert from DOC to ODT and back.
Microsoft: Boiling Frogs Since 1975 Posted Apr 18, 2012 22:03 UTC (Wed) by khim (subscriber, #9252) [Link] For a fair comparison, convert StarOffice documents to ODx and back, not MSFT cruft. I don't know where your idea about “fair” comes from. There are bazillion documents created in the format of old versions of MS Office. Number of documents in StarOffice format is minuscule in comparison. That's why OOXML was designed and presented as format usable and compatible with “old proprietary formats of MS Office”, not with “old proprietary formats of all existing programs”. This is how it was presented in ISO and this is what said format does. If ISO accepted this goal as design criteria (and looks like it did) then indeed OOXML is the best possible solution. And BTW, the "conversion" there is mostly wrapping/unwrapping, there is no real "conversion." Sure, but it works. Not perfectly, but much better then ODT. Or use Office to convert from DOC to ODT and back. The results are usually significantly worse then with LibreOffice. That's because when LibreOffice is faced with something unsupported by ODF (but supported by old, proprietary formats) it tries to somehow change the document to fit. MS Office just drops these parts on the floor. And it'a easy to understand why: LibreOffice has no choice while MS Office has much better format (better for the purpose of editing old documents, that is): OOXML.
Microsoft: Boiling Frogs Since 1975 Posted Apr 17, 2012 0:52 UTC (Tue) by vonbrand (subscriber, #4458) [Link] I'm sorry, but roundtrips DOC --> DOCX --> DOC done by the very same people who inflicted said formats on us don't tell anything at all.
Microsoft: Boiling Frogs Since 1975 Posted Apr 17, 2012 5:19 UTC (Tue) by khim (subscriber, #9252) [Link] It does. It proves that such round-trip is possible. The next step is, of course, it to see if anyone else can do that. And, suprise, surprise, it's possible: LibreOffice can not save documents in OOXML format, but at can read them and half-round trip (convert from legacy format to OOXML using MS Office, open said OOXML in LibreOffice then save as legacy format and open in MS Office) still works better then ODF roundtrip. You may dislike Microsoft shenanigans as much as you want but OOXML is technically the best candidate for the problem it was designed to solve. If such technical problem (standard with support for legacy Microsoft's formats) deserves an ISO approval or not is separate issue.
Microsoft: Boiling Frogs Since 1975 Posted Apr 17, 2012 8:32 UTC (Tue) by anselm (subscriber, #2796) [Link] It proves that such round-trip is possible. Considering that OOXML is mostly an XML encoding of the legacy Microsoft Office formats, anything else would be … unusual. On the other hand, Microsoft might have botched even that, the way they have botched so many other things, so it's probably best to be grateful for small miracles. Finally, the alleviation for the »changing the printer driver changes the formatting« in Word is apparently to save your document as RTF and then load it back from the RTF file. Go figure.
Microsoft: Boiling Frogs Since 1975 Posted Apr 17, 2012 10:34 UTC (Tue) by cortana (subscriber, #24596) [Link]
The fact that changing your printer driver alters the formatting of a document kind of boggles my mind. WTF does the printer driver have to do with it? What if you have more than one printer installed?
Microsoft: Boiling Frogs Since 1975 Posted Apr 17, 2012 13:33 UTC (Tue) by khim (subscriber, #9252) [Link] What if you have more than one printer installed? Then you can find out that your painstakingly composed document tested on 360dpi dot-matrix printer falls apart when you try to do a final output on 600dpi LaserJet. The fact that changing your printer driver alters the formatting of a document kind of boggles my mind. This is quite unfortunate, but you should remember then first versions of MS Word were supposed to create something acceptable for 72dpi printer! It's impossible to create anything good-looking for such a low resolution unless your document is completely built around this final output device. And then we have this pesky backward-compatibility concerns, of course.
Microsoft: Boiling Frogs Since 1975 Posted Apr 17, 2012 14:14 UTC (Tue) by anselm (subscriber, #2796) [Link] It's impossible to create anything good-looking for such a low resolution unless your document is completely built around this final output device. Tell that to Donald Knuth, who came up with TeX in the late 1970s/early 1980s. At that time, TeX output looked substantially the same (modulo resolution) whether produced on a really low-res Xerox graphics printer or a several-thousand DPI phototypesetter, and certainly a lot nicer than Word output does even today. Especially when mathematics are involved. These scientists certainly gave Microsoft's »engineers« a run for their money. Anyway, 72 dpi is a bit on the low side. Even the 24-pin dot matrix printer I used to have in the 1980s was capable of 360-dpi output in graphics mode, and was actually reasonably fast at 180 dpi. Wikipedia claims that »Word for DOS has been designed for use with high-resolution displays and laser printers, even though none were yet available to the general public«, which makes the strange printer driver issues even more mystifying considering that, even leaving TeX out of the game, there were various other word processing packages on the market at the time, for different platforms including not just DOS and the Mac but also the Apple II and Atari ST, which managed to produce output on a par with (or surpassing) Word but identically across a range of different output devices.
Microsoft: Boiling Frogs Since 1975 Posted Apr 17, 2012 16:25 UTC (Tue) by khim (subscriber, #9252) [Link] Tell that to Donald Knuth, who came up with TeX in the late 1970s/early 1980s. I'm pretty sure Knuth knows limitations of TeX better then me. It was basically unusable on 72dpi printer. If you had high-quality printer with real double-strike 144dpi mode then yes, it was possible to use TeX - just barely. When 24pin 180dpi/360dpi printers TeX become reality on PC, but it was way too late: WordPerfect and Lotus 1-2-3 were the “established standard” by then. Later MS Office replaced them. These scientists certainly gave Microsoft's »engineers« a run for their money. Rilly? You mean in your universe Joe Average uses TeX and not MS Word to print his creations? This is some kind of interesting universe, I must admit. But here and now TeX is historical curiosity (even mathematical journals often use MS Word instead of TeX and general public does not even know TeX exists). Even the 24-pin dot matrix printer I used to have in the 1980s was capable of 360-dpi output in graphics mode, and was actually reasonably fast at 180 dpi. By that time battle was basically already won: in the era of 9-dot matrix printers TeX was doubly unusable (typical computer had no memory to run TeX and 72dpi printer generated unreadable output if you used it) and people used WordPerfect and WordStar. WordPerfect was more popular by far. Later MS Office won the crown (that's why you see so many WordPerfect warts in OOXML), but, of course, it needed compatibility to do that. Which makes the strange printer driver issues even more mystifying considering that, even leaving TeX out of the game, there were various other word processing packages on the market at the time, for different platforms including not just DOS and the Mac but also the Apple II and Atari ST, which managed to produce output on a par with (or surpassing) Word but identically across a range of different output devices. Which ones do you have in mind? How popular they were back then? People rarely moved documents between computers in that era, but quality of the output was important. Even if printers had 144dpi mode it was slow and unreliable. MS Word was actually not widely used (it came later but of course it inherited warts of previous editors), but layout in most popular editors was already dependent on printer driver. Later MS Word needed to keep the status quo to be accepted. The lesson here is simple: scientists may create truly beautiful things… which will be used by other scientists (and scientists wannabe). But engineers produce things for “real users” and this is quite different art.
Microsoft: Boiling Frogs Since 1975 Posted Apr 17, 2012 21:59 UTC (Tue) by anselm (subscriber, #2796) [Link] I'm pretty sure Knuth knows limitations of TeX better then me. It was basically unusable on 72dpi printer. The problem, if there was one at all, wasn't one with TeX – it is really that the Computer Modern fonts (at the time essentially the only game in town) don't look their best on low-resolution output devices, and as far as CM is concerned, 600 dpi is »low resolution«. TeX itself was perfectly capable of producing good-looking output even on 72dpi printers (I think you mean 9-pin dot matrix printers), within the limits of the device, if you were willing to wait for the output. It was also possible to adapt Knuth's line breaking/spacing algorithm from TeX to optimise output on dot matrix printers using the built-in fonts at text-printing speed (the relevant paper was published in Software Practice & Experience, I forget the correct citation); I spent quite a lot of time playing with this, way back then, and always wondered why the word processor people wouldn't pick this up. The popularity (or not) of TeX is a non-issue here; you claimed that it was impossible to produce good-looking output on a low-res device without tying one's software to that device, and I cited TeX as a counter-example. A single counter-example disproves »impossible«. I win. Which ones do you have in mind? In the late '80s I (like many other students at my university) used an Atari ST, and people would always prepare documents at home and print them at the university because the laser printers there were a lot more convenient than the dinky dot matrix printers they had at home. I don't recall people complaining that Signum or StarWriter (the great-great-grandfather of today's LibreOffice) would mess up the formatting when a file was moved from one computer to the other. By that time I was a TeX user, anyway, so it was a non-issue for me. But even earlier on the Apple II it made no difference whether you printed stuff on an Epson FX-80 or a Centronics 737 (which were the two printers I was using at the time); they would look subtly different because the built-in fonts were different, but the spacing, page breaks, etc. would of course be identical – which is something that Word apparently hasn't nailed in 2012.
Microsoft: Boiling Frogs Since 1975 Posted Apr 17, 2012 23:10 UTC (Tue) by khim (subscriber, #9252) [Link] TeX itself was perfectly capable of producing good-looking output even on 72dpi printers (I think you mean 9-pin dot matrix printers), within the limits of the device, if you were willing to wait for the output. You are mixing draft mode (fast, 72dpi, one pass) with NLQ mode (slow, 144dpi, two passes). Cheap printers cheated and had no “real” NLQ at all (they just passed over the same dots the second time - which produced darker picture but kept the resolution @ 72dpi) and more expensive ones were about 5 times slower in NLQ mode thus most documents were printed in draft mode (only letter sent by mail were sometimes printed in NLQ mode). you claimed that it was impossible to produce good-looking output on a low-res device without tying one's software to that device, and I cited TeX as a counter-example Yup. At 72dpi TeX produces unreadable text. You either need to use “large, friendly letters” (often not an option because maximum size of letter was limited) or you needed to use slower 144dpi mode - which was also often not an option (even if you had it on your device it was too slow). A single counter-example disproves »impossible«. Right. But you don't have it. TeX is unusable @ 72dpi thus it's obviously not a proper counter-example. And 72dpi is important: Mac used this dpi on screen - exactly to make it easier to produce best possible WYSIWYG for these printers. But even earlier on the Apple II it made no difference whether you printed stuff on an Epson FX-80 or a Centronics 737 (which were the two printers I was using at the time); they would look subtly different because the built-in fonts were different, but the spacing, page breaks, etc. would of course be identical. Of course these will be identical! They have identical resolutions and identical printer fonts (as far as spacing is concerned). MS Word handles such cases just fine - and always did. It's only when you go from dot-matrix @ 144dpi to dot-matrix @ 360dpi or to laser @ 300✕Ndpi you get real problems. I don't recall people complaining that Signum or StarWriter (the great-great-grandfather of today's LibreOffice) would mess up the formatting when a file was moved from one computer to the other. Not sure about Signum, but StarWriter had the same problem as TeX: it produced ugly-looking documents on low-resolution devices. This was probably one reason for why the students tried to print on laser printer whenever possible. The popularity (or not) of TeX is a non-issue here It's absolutely of the issue here. TeX was not initially popular because it was unusable on low-res output devices and when high-res devices become available people continued to use what they were accustomed to use. 1001st repeat of the same story: scientists claim the won because their solution is more technically advanced and engineers claim they won because they created solution which is actually used by people. Shows the difference between good scientist and good engineer quite nicely, isn't it?
Microsoft: Boiling Frogs Since 1975 Posted Apr 18, 2012 7:03 UTC (Wed) by anselm (subscriber, #2796) [Link] TeX is unusable @ 72dpi thus it's obviously not a proper counter-example. That's what you say. This is what is called the »No true Scotsman« logical fallacy. TeX output at 72dpi is quite readable as far as I'm concerned. Stuff using Computer Modern is not exactly beautiful at 72dpi but that (as I said) is mostly a font problem, not a TeX problem. I spent considerable time in the 1980s writing a DVI previewer for the Atari ST, which had approximately that screen resolution, and it worked fine. TeX was not initially popular because it was unusable on low-res output devices I think that was more to do with the fact that in the early to mid '80s there was no good cheap/free TeX implementation for the PCs of the day. TeX was fine on real computers. Also, TeX was originally meant for typesetting books, not office correspondence, so the observation that it didn't catch on for office correspondence does not detract from the fact that its output was basically OK, which is the original issue.
Microsoft: Boiling Frogs Since 1975 Posted Apr 17, 2012 16:01 UTC (Tue) by oldtomas (guest, #72579) [Link]
"The fact that changing your printer driver alters the formatting of a document kind of boggles my mind."
It boggled mine too -- at the time. But I can confirm that. Quite a while ago, a friend of mine (to whom I played the role of "local friendly hacker") upgraded from a dot matrix printer (360 dpi, remember those?) to an inkjet (300 dpi).
His carefully written tables kind of exploded :-)
Turns out that the internal measuring unit of Word used to be "whatever The Printer is able to resolve", in a typically Microsoftish nonchalant way.
So tab stops could, with some luck be at such points that the different resolution pushed some material one tab stop further -- some not.
Microsoft: Boiling Frogs Since 1975 Posted Apr 16, 2012 21:34 UTC (Mon) by anselm (subscriber, #2796) [Link] I think you've mixed engineer (who's by definition is concerned with applying scientific knowledge, mathematics and ingenuity to develop solutions for technical problems) with someone else. I don't need to be lectured by you about what it means to be an engineer. I am one myself and I can tell you that I would rather flip burgers than see my name attached to anything like the OOXML standard. As far as I am concerned, engineering is not just about making things work any which way but also about simplicity, elegance, and beauty. If Microsoft Office had been built by good engineers to begin with, the crocks that are now codified in the OOXML standard would never have been required in the first place. Nope. It was just pushed through the ISO way before it was polished enough. This is not a technical issue. Technical issues are slowly fixed as I've pointed out above. Microsoft had to produce an office document standard as quickly as possible and with the least amount of interference from people who would have been able to point out that it stinks to high heaven. Which is why they came up with a huge but very shoddy »standard« and used ECMA (which basically rubberstamps everything its members submit) and the ISO fast-track procedure, together with all sorts of sleazy tricks to avoid, as far as possible, bringing the shortcomings of the proposal to light. If things had gone the way these things are supposed to go, the pile of manure that became ISO/IEC 29500 would never have been standardised no matter what – both because there was a perfectly workable similar standard (ISO/IEC 26300:2006) already in existence and because there were literally thousands of technical objections (by real engineers) that by rights would have had to be addressed before the standard was even finalised. Attempting to fix these issues piecemeal after the fact is not how things are supposed to be done. You can try to whitewash what Microsoft did with ISO/IEC 29500 all you want; the fact remains that a pig stays a pig even with lipstick on. Once again: Microsoft knows how to develop standards. It knows it very well indeed. No it doesn't. It knows how to produce documents that vaguely look like standards from a distance but are virtually useless to anybody but itself. If you need to look at Excel 95 to figure out what the OOXML standard really means – note that Microsoft didn't bother to actually specify in the standard what the flag in question did, just that it was supposed to trigger behaviour »compatible to Excel 95« –, then this is an obvious problem for anybody outside Microsoft (which is presumably the point of the exercise). They tried to pull off the same sort of thing with the SMB protocols but got caught by their own outside expert. If Microsoft really knew very well how to develop standards then, as far as we can tell from the outside, they do a very good job at concealing that ability from the general public.
Microsoft: Boiling Frogs Since 1975 Posted Apr 16, 2012 21:55 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
>If you need to look at Excel 95 to figure out what the OOXML standard really means – note that Microsoft didn't bother to actually specify in the standard what the flag in question did, just that it was supposed to trigger behaviour »compatible to Excel 95«
Can you point out the list of trigonometric functions usable in spreadsheets and their parameter types in ODF 1.0?
Microsoft: Boiling Frogs Since 1975 Posted Apr 16, 2012 22:22 UTC (Mon) by anselm (subscriber, #2796) [Link] There is a big difference between not standardising something and standardising something in a way that is virtually impossible for everybody except a single party to implement. The trigonometry functions in ODF 1.0 were left out to keep the scope of the first version of the standard manageable. They got added in a later version of the standard. Problem solved. In the meantime there was fairly widespread consensus about what a »sine« and »cosine« is as well as what sort of data type such a function would take or return, and there were various open-source implementations of ODF-based spreadsheet software to refer to. On the other hand, we're pretty much stuck with the weird bits in OOXML that refer to Excel 95 and Word for the Macintosh without actually telling us what they are really supposed to do. There is no source code you can look at to figure them out. And since they're in the standard already they are very difficult to get rid of again.
Microsoft: Boiling Frogs Since 1975 Posted Apr 16, 2012 22:46 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
That's about the worst way to standardize something because it causes a plethora of incompatible implementations. And we see this right now - there are no two ODF implementations that render complex documents the same way.
Yeah, that annoying 'backwards compatibility' problem again.
We recently tried to migrate a medium-sized organization to a mix of Google Docs (managers need to edit documents during business trips) and OpenOffice. We've failed miserably - there were TONS of incompatibilities, even though both ostensibly support ODF.
In the end, managers decided 'screw Linux and that commie hippies in Google' and went to Microsoft and Office Live with that godawful Sharepoint. And I can't really blame them, at least Microsoft is fairly compatible with itself and you receive something working for your $$$$$.
Microsoft: Boiling Frogs Since 1975 Posted Apr 16, 2012 23:03 UTC (Mon) by anselm (subscriber, #2796) [Link] there are no two ODF implementations that render complex documents the same way. With Word, there's only one implementation and even that does not manage to render documents consistently, depending on which printer driver (and version) you have installed. This is even before you bring in other software that is ostensibly compatible. I'd say the situation is just as bad.
Microsoft: Boiling Frogs Since 1975 Posted Apr 16, 2012 23:10 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
Dependency on printer driver (actually, on paper size settings) is well-known and easy to work around. It mostly bites users when constant switching between Letter/A4 is required. Other times you can simply ignore it.
And no, Microsoft has a top-notch online collaboration suite that is almost perfectly compatible with their desktop products, we've found some inconsistencies but they were truly minor.
And no, the actual OOXML files that MS produces do not use the magic 'behave like Excel 95' entries, they are fairly straightforward and easy to parse/generate. It's pretty clear to everybody that MS tries to be bug-compatible with earlier versions so everyone who don't need to work with old documents can simply ignore these commands.
Microsoft: Boiling Frogs Since 1975 Posted Apr 16, 2012 22:05 UTC (Mon) by khim (subscriber, #9252) [Link] Once again: Microsoft knows how to develop standards. It knows it very well indeed. I don't really see how you can say that. It knows how to produce documents that vaguely look like standards from a distance but are virtually useless to anybody but itself. Bingo! That's the ticket! This is the whole point of the exercise! If Microsoft really knew very well how to develop standards then, as far as we can tell from the outside, they do a very good job at concealing that ability from the general public. Nope. They do this quite openly. I think you just expect something different from them. For Microsoft “standard” is “something accepted by some standards organization”, nothing more, nothing less¹). And as you admit they create these standards and get stamps of approval quite regularly, so why do you say they can not develop standards? As far as I am concerned, engineering is not just about making things work any which way but also about simplicity, elegance, and beauty. That's secondary issues. RFC 1925 may be April Fool's RFC, but it sets the priorities straight. It Has To Work is the first and most important rule. If something works then we can start talks about simplicity, elegance, and beauty. If it does not work then everything else does not matter! If Microsoft Office had been built by good engineers to begin with, the crocks that are now codified in the OOXML standard would never have been required in the first place. This is where you are wrong. If Microsoft Office had been built by good engineers (by your definition) then OOXML would have been similar to what we have today. Just the name of primary sponsor would have been different. Apple or may be some other firm would have presented it while Microsoft would have been extinct. Battle was quite serious back in 1990th and most of warts we observe today in OOXML have roots in that battle. That's why there are these WordPerfect and Lotus 1-2-3 compatibility flags, that's why there flags for bugs introduced in previous versions of MS Office. 90%+ market share of MS Office and ugliness of OOXML are flip sides of the very same coin. ¹) Actually Microsoft also tries to shift attention from “official standards” to “standards de-facto” and now developers often complain that Linux does not support “standard development tools” (i.e. Visual Studio) and “standard APIs” (i.e. DirectX). But this campaign lies in totally separate managerial universe and AFAICS is not driven by Microsoft's engineers.
|
|||||||||||||