 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Maybe someone can clear this up for me...
It seems either your organization needs the Word97 word break
algorithms, or it doesn't.
If it doesn't, what's the broughaha about OOXML not specifying what it
means?
If it does, either Open Office interprets it correctly, or it doesn't.
If Open Office interprets it correctly, what's the problem?
If Open Office doesn't interpret it correctly, you can't use Open Office
anyway, so you'd be unable to obey the government mandate to use open
software where available.
It seems like this whole "the spec is underspecified in small ways"
complaining is just really "we don't want MS to have a standard here
because the point was to keep people from using MS software."
There's never going to be enough information in the spec to reproduce
what the software does, or the spec would be bigger than the source code
of the software.
Something else nobody has answered for me: Does the ODF spec actually
specify the line breaking algorithms and how they're applied in
different settings?
(Note: I'm not disagreeing the spec is incomplete. I'm not disagreeing
that MS has f'ed up the ISO with their party games. But on the other
hand, is anyone really surprised when something like ISO goes up against
something like MS they lose?)
--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where's that?"
"It's the Age of Channelwood."
"We should go there on vacation some time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
http://ooxmlisdefectivebydesign.blogspot.com/
Looks like he added lots more info. Only this post was available when I
first saw that blog:
http://ooxmlisdefectivebydesign.blogspot.com/2007/08/microsoft-office-xml-formats-defective.html
...about how hard it is to do something as "simple" as changing a cell
to have a constant value instead of a formula (a 5-second operation in
Excel itself).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> It seems like this whole "the spec is underspecified in small ways"
> complaining is just really "we don't want MS to have a standard here
> because the point was to keep people from using MS software."
The whole idea with a standardized open format is the same as with
any other standard: That anyone can make a compatible implementation
of that standard. This is good for fair competition and disallows
monopolies.
What Microsoft is trying to do is a PR stunt: "Hey, we support open
standards, we are the good guys." They want to give a positive image
of themselves. If the "standard" is, however, only implementable by
Microsoft, this kind of PR is mischievous. On the outside they look
like they are advocating open standards and fair competition, but in
reality they are only strengthening their own monopoly. They are also
abusing the standardization system to strengthen their own monopoly,
which is the exact opposite of what standardization is for.
If their format becomes standardized that's a great asset. They can
go to governments and companies and say: "This is *standard*. You should
use this. ISO standardization is a guarantee for quality. And, you see,
our programs are the only ones which fully implement this standard, and
thus you should use our programs and not those other programs which only
implement it partially."
That's *not* the purpose of standards. That's the exact opposite of what
standards are for. Standards are not a tool to promote monopolies.
That's what people are complaining about.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> It seems either your organization needs the Word97 word break
> algorithms, or it doesn't.
>
> If it doesn't, what's the broughaha about OOXML not specifying what it
> means?
>
> If it does, either Open Office interprets it correctly, or it doesn't.
>
> If Open Office interprets it correctly, what's the problem?
>
> If Open Office doesn't interpret it correctly, you can't use Open Office
> anyway, so you'd be unable to obey the government mandate to use open
> software where available.
>
> It seems like this whole "the spec is underspecified in small ways"
> complaining is just really "we don't want MS to have a standard here
> because the point was to keep people from using MS software."
>
> There's never going to be enough information in the spec to reproduce
> what the software does, or the spec would be bigger than the source code
> of the software.
>
> Something else nobody has answered for me: Does the ODF spec actually
> specify the line breaking algorithms and how they're applied in
> different settings?
You know what? PostScript is an open standard. Sure, it's not, to my
knowledge, backed by any official standards body. But there is a written
technical specification, available for free, and a large amount of
software supports that standard. (And most of it isn't from Adobe, the
creator of that standard.)
Identical remarks apply to PDF. Anybody who wants to can implement that
standard, and lots of programs have done, and they all worth together.
Not because these programs are "clones" of what Adobe has produced, but
because they understand the same file format.
Note that there are no important parts of this standard that are not
completely defined. (There is space for implementors to add their own
extensions, but everything you need to be able to read and process the
format is in the specs.)
If you write word processor documents in a *truely* open format, you can
move it between different word processor applications. You can also (at
least in principle) run an external spell checker over it, and have all
sorts of other analysis and processing tools work on it. It's not like
you're trying to "duplicate Word" by implementing the standard.
The trouble is, the M$ standard is something that looks like a standard,
but would be really hard for anybody except M$ to implement. Things like
using raw bitmaps instead of XML tags, because that happens to be how
Word already works internally and it's easier not to change it. Things
like controlling aspects of how Word displays the preview on screen.
Basically, the way the "standard" is written means that the only way to
implement it is to duplicate Word. You can't [easily] implement it in a
slightly different way. And that's not the point of standards...
Of course, a document format standard *already* exists. And it's pretty
obvious why M$ wants to invent another one rather than use the existing
one...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Note that there are no important parts of this standard that are not
> completely defined.
But that's my point. Are the parts that aren't well-defined in OOXML
also "important"? Or they just stuff that Word needs to put there to
make sure that when you export it and then import it again, you get
exactly the same results?
> The trouble is, the M$ standard is something that looks like a standard,
> but would be really hard for anybody except M$ to implement.
So the complaint isn't with the standard as much as it is with how
difficult it is to understand or implement the standard?
I hate to say this, but there's all kinds of standards like that out
there. :-) Especially in the telephone world.
> Basically, the way the "standard" is written means that the only way to
> implement it is to duplicate Word. You can't [easily] implement it in a
> slightly different way. And that's not the point of standards...
Agreed that the only way to implement all of it would be to essentially
duplicate every aspect of what Word does. But that's my point. If this
document standard is a way of storing Word documents, and you want to be
able to store them and bring them back into Word without change, you
need to dump to the file every ability that Word has.
If you don't want to implement Word97WrapMode in your word processor,
then ignore that flag, yes?
> Of course, a document format standard *already* exists.
It looks like the standard allows you to include arbitrary scripts in
arbitrary scripting languages. Kind of hard to ensure interoperability.
It also lets you name the fonts without including the glyphs. Again,
hard to ensure that what comes out is what went in.
> And it's pretty
> obvious why M$ wants to invent another one rather than use the existing
> one...
Well, sure. Because the existing one can't store Word documents. That's
kind of my point.
If ODF doesn't specify how text is laid out on a page, and Word does,
then you can't export Word to an ODF document and have it come out
correctly.
It's analogous to imagining a word processing standard that doesn't
specify the fonts, and then asking how you'd make your word processor
export to that format, yes?
If you need the features of Word, and you want to interact with Word,
you're going to wind up with a document format that has all the cruft of
Word in it. If you don't need the features of Word, you don't need to
use Word, and you don't need to worry about Word97WrapMode or whatever
might be in all the gruesome poorly-documented bitmaps, yes?
--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where's that?"
"It's the Age of Channelwood."
"We should go there on vacation some time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> ....about how hard it is to do something as "simple" as changing a cell
> to have a constant value instead of a formula (a 5-second operation in
> Excel itself).
"Excel 2007 cannot open the file we have manually updated"
Well, no, I can understand that. Excel opens the file, says "Hey, the
value of the sum of the columns you added up doesn't match when I
recalculate it, so something must be corrupt in the file." Seems to
make sense to me.
(Plus, ODF says this doesn't work anyway, because you corrupted the
digital signature. :-)
"If the changes are made on a server without Excel 2007 installed and
the resulting spreadsheet is distributed to employees throughout the
organization, then every single employee will have to get through a full
spreadsheet recalculation (arbitrarily lengthy) next time they open the
spreadsheet." Well, yeah, duh. I'm going to change a spreadsheet full
of calculations, not do the calculations myself, and then ask the
spreadsheet to open it, and ... what would you expect?
"What this shows pretty clearly is that either we lack the tools, or
Microsoft does not think we should be doing that in the first place."
Or, maybe, if you're going to edit a spreadsheet that contains formulas,
you should understand spreadsheet formulas? Or accept the fact that the
program that does will fix it for you? I can't even imagine why this is
a complaint.
Then he complains that if he corrupts every single formula in the
spreadsheet, then he can't edit it in a way that lets Excel load it
without recalculating stuff?
* *
Oh jeez. His second complaint is that floating point numbers aren't exact.
* *
His third complaint is "the format is too hard. Whaaaaaaa!"
His first three complaints about the format all consist of "I can't take
a spreadsheet, make arbitrary changes to it, and expect it to still
work." Well, yeah, the point of spreadsheet software is to sync the
interrelationships between the pieces.
OK, enough.
--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where's that?"
"It's the Age of Channelwood."
"We should go there on vacation some time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New a écrit :
>> And it's pretty
>> obvious why M$ wants to invent another one rather than use the
>> existing one...
>
> Well, sure. Because the existing one can't store Word documents. That's
> kind of my point.
>
I think the problem is that we should be defining a standard to store
text documents, not Word documents...
If anyone needs a standard to store Word documents, it's right there in
Word, just save the file :-) If there are parts of the standard that
depend on this specific software, you might as well define the standard
as "whatever Word is able to spit from the file" and be done with it.
As far as I know this is not the case of ODF, PDF, Postscript... Even if
there are unspecified behaviours, they shouldn't be described in terms
of what a particular piece of software does with it. But then I've never
read the specs of those formats either ;-)
In this specific case, someone implementing the standard and discarding
the parts "doLikeWordn.nnn" is not choosing a behaviour where the
standard does not say what should happen, or not implementing an
extension, he is plainly not respecting the standard.
If only Microsoft can implement the standard, it's not a standard, it's
a file format. It can be the de-facto standard but that's not the same
at all. It does not bring any of the benefits a standard should bring.
--
Vincent
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Vincent Le Chevalier wrote:
> I think the problem is that we should be defining a standard to store
> text documents, not Word documents...
We have one already. ;-)
Seriously, the only reason this came up is because lots of people are
using Word, and their governments basically said "You shouldn't be using
Word, because it's not a standard."
> If anyone needs a standard to store Word documents, it's right there in
> Word, just save the file :-) If there are parts of the standard that
> depend on this specific software, you might as well define the standard
> as "whatever Word is able to spit from the file" and be done with it.
I agree. That's why I was asking why it was a big deal that the standard
didn't specify how to understand everything Word can do.
> In this specific case, someone implementing the standard and discarding
> the parts "doLikeWordn.nnn" is not choosing a behaviour where the
> standard does not say what should happen, or not implementing an
> extension, he is plainly not respecting the standard.
But does it matter? If you need it to do like Word97 does it, use Word,
and you're screwed if your government says you're not allowed to. If you
don't need it to do like Word97 does it, why do you care if the software
you're using doesn't respect that standard?
I mean, if the standard doesn't say how word breaking works *with* the
DoLikeWordNN and it doesn't say how work breaking works *without* the
DoLikeWordNN, then I'd argue you can safely ignore the DoLikeWordNN and
meet the standard.
Just like the Ada standard says "Behavior X is undefined." That doesn't
mean that no matter what you do, you're not following the standard.
If "BreakLinesLikeWord97" behavior isn't defined, then it's safe to
ignore it and still call yourself standards compliant, just like
whatever code you generate for running off the end of an array in C is
going to be standards compliant.
> It does not bring any of the benefits a standard should bring.
Right. I'm not saying the standard is good, or should pass. I'm saying
the arguments against it that I've seen are stupid arguments. :-)
--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where's that?"
"It's the Age of Channelwood."
"We should go there on vacation some time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Vincent Le Chevalier wrote:
> In this specific case, someone implementing the standard and discarding
> the parts "doLikeWordn.nnn" is not choosing a behaviour where the
> standard does not say what should happen, or not implementing an
> extension, he is plainly not respecting the standard.
Oh, and incidentally, if you *care* whether "doLikeWordn.nn" works, ODF
isn't going to work for you either. ODF doesn't say how to break lines
(at least that I could find), so if you *need* the word breaking to be
in this mode, you *can't* use Open Office or something like that. If you
*don't* need the word breaking to be right, you can use some converter
that ignores this flag.
Note this flag is irrelevant to writing a spell checker, a document
indexer, etc as well, so the argument is kind of silly in that way, too.
--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where's that?"
"It's the Age of Channelwood."
"We should go there on vacation some time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Governments mandate ISO standards are to be used for documents so that
they won't be locked into using a single supplier for their software.
MS forces their under specified format through ISO.
Governments say "OOXML is an ISO standard, lets use it."
Because the "specification" of the standard is incomplete MS is the only
body which can implement it.
End result - government departments are still locked into using MS office.
As for the "do this like word97", the correct way to handle this would
have been to include sufficient algorithms in the specification to allow
a translator to convert old word documents into the new format.
From what I've been reading it seems that MS office won't actually be
compliant with the ISO version of OOXML anyway so governments should
refuse to buy it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
