MSoft doesn't write anything cross-platform. Their software for Mac is totally rewritten from spec, which explains why the hideous bugs in Mac IE5 are so different from the hideous bugs in MSWin IE5. I believe some of the code is reused, but even the dev teams are entirely distinct. MSoft's support of Mac software is non-existent as well: just try to find a patch, let alone documentation distinct from the windows docs.
You've missed the entire point of a proper storage format. The format doesn't need to know anything about the program using it. In Word it does. Use XML/Schema/XSL and it is extensible. And make sure you describe the document rather than the program which made it.
Even OLE is just an XSL import statement.
Having spent more of my life than I would have liked working on converters like these, I can testify that this isn't easy. But doing it right will pay off in the end.
BTW, WP was a masterpiece in the days of WP Corp. Borland didn't seem to know quite what to do with it. Novell single-handedly destroyed it. Corel came in with a lot of great things that Novell should have done with it two years prior, but then they seemed to have gotten side-tracked (as if WP hadn't been a side track for them all along). A sad tale all in all. Which team were you on?
The lack of local-formatting-end specifications in the format, and various other idiosyncrasies do tie their implementation of the doc format to the features of each version of Word. But this has nothing to do with how a third party must represent it.
SGML, for instance, was designed specifically to be able to describe any type of document layout that could be conceived, through its style language. XML has inherited this capability.
The fact that they choose to tie themselves to such a poor representation has no bearing whatsoever on how a document must be described by a third party.
The MS file format is specific to features in Word.
Did you think about this at all before you posted? The format has little if anything to do with features in MSWord. Yes, there has to be a way to specify each feature, but it is ridiculous to think that that means we have to use the same format to specify those features. The heights of lunacy in the rest of your post flow directly from this unexamined premise.
In fact, the MS.doc format is hideous in design, and contributes most of the difficulty in creating converters.
It's really a good a idea to know what you're talking about before you make a fool of yourself. At least then you'll know why everyone is laughing at you.
I don't know what you've been smoking, but green is precisely the color you don't need. Red is probably the color you're looking for, but the reality is that plants not only absorb in various spectra, but the required range can vary somewhat between species. Did you know that not all chlorophyll is created equal?
There are photochromatic analyses that have been performed on chlorophyll absorption (and there is more than one type, found in various ratios in plant materials), but even that data doesn't entirely match up with experimental results.
What I want to see is someone producing LED clusters which target specific frequencies needed by plants, without wasting energy on the unused light spectra. And even then I'll want to see solid experimental data backing up its effectiveness.
Stimulated emissions (as in flourescent) might be the only way to adequately spread the incredibly narrow frequency of LEDs into a broader, more useful spectrum.
I can't think of a single reason why a compiler shouldn't be this way. What are you smoking?
I could get rid of GTK if GIMP didn't use it (I use KDE)
GTK was originally written for the purpose of providing a toolset for GIMP. This is like saying you could get rid of fdisk if it wasn't for the drive partitions.
Slashdot Mirror
MSoft doesn't write anything cross-platform. Their software for Mac is totally rewritten from spec, which explains why the hideous bugs in Mac IE5 are so different from the hideous bugs in MSWin IE5. I believe some of the code is reused, but even the dev teams are entirely distinct. MSoft's support of Mac software is non-existent as well: just try to find a patch, let alone documentation distinct from the windows docs.
Every time I java.text.DateFormat.getDateTimeInstance().format( Calendar.getInstance().getTime())
I get a little nostalgic for localtime()
You've missed the entire point of a proper storage format. The format doesn't need to know anything about the program using it. In Word it does. Use XML/Schema/XSL and it is extensible. And make sure you describe the document rather than the program which made it.
Even OLE is just an XSL import statement.
Having spent more of my life than I would have liked working on converters like these, I can testify that this isn't easy. But doing it right will pay off in the end.
BTW, WP was a masterpiece in the days of WP Corp. Borland didn't seem to know quite what to do with it. Novell single-handedly destroyed it. Corel came in with a lot of great things that Novell should have done with it two years prior, but then they seemed to have gotten side-tracked (as if WP hadn't been a side track for them all along). A sad tale all in all. Which team were you on?
The lack of local-formatting-end specifications in the format, and various other idiosyncrasies do tie their implementation of the doc format to the features of each version of Word. But this has nothing to do with how a third party must represent it.
SGML, for instance, was designed specifically to be able to describe any type of document layout that could be conceived, through its style language. XML has inherited this capability.
The fact that they choose to tie themselves to such a poor representation has no bearing whatsoever on how a document must be described by a third party.
Did you think about this at all before you posted? The format has little if anything to do with features in MSWord. Yes, there has to be a way to specify each feature, but it is ridiculous to think that that means we have to use the same format to specify those features. The heights of lunacy in the rest of your post flow directly from this unexamined premise.
In fact, the MS .doc format is hideous in design, and contributes most of the difficulty in creating converters.
It's really a good a idea to know what you're talking about before you make a fool of yourself. At least then you'll know why everyone is laughing at you.
I don't know what you've been smoking, but green is precisely the color you don't need. Red is probably the color you're looking for, but the reality is that plants not only absorb in various spectra, but the required range can vary somewhat between species. Did you know that not all chlorophyll is created equal?
There are photochromatic analyses that have been performed on chlorophyll absorption (and there is more than one type, found in various ratios in plant materials), but even that data doesn't entirely match up with experimental results.
What I want to see is someone producing LED clusters which target specific frequencies needed by plants, without wasting energy on the unused light spectra. And even then I'll want to see solid experimental data backing up its effectiveness.
Stimulated emissions (as in flourescent) might be the only way to adequately spread the incredibly narrow frequency of LEDs into a broader, more useful spectrum.
GCC: Tons of flexibility, huge compiler
I can't think of a single reason why a compiler shouldn't be this way. What are you smoking?
I could get rid of GTK if GIMP didn't use it (I use KDE)
GTK was originally written for the purpose of providing a toolset for GIMP. This is like saying you could get rid of fdisk if it wasn't for the drive partitions.
the minimal usable Linux install is about 400MB
?!What?! This isn't even worth addressing.