[Clipart] Re: OpenOffice SVG Export

[Alan Horkan]

(Answering in reverse...)

> > OpenOffice.org does not have any SVG import.
>
> I think we can go ahead with collecting a library of SVG images and
> figure that with SVG being an emerging standard getting increasing
> amounts of press in the OSS community someone will eventually code
> the support for it into OO.o, improve the support in Mozilla, and
> so on and so forth.

I consider OpenClipart.org as gving OpennOffice.org another incentive to
sort out their SVG support, and had already accepted the unfortunate
roadblock.
I was however surprised that people had different ideas about how much (or
how little) Open Office supported SVG.

> > Firstly let me say that it is insane not to use good layout and pretty
> > printing in most XML particularly SVG which provides SVGZ for those who
> > are concerned about file size.
>
> I don't claim to completely understand why OO.o does this, and I

It was either entirely arbitrary or there was a programmer that believed
those few bytes make a difference.  I'll add it to the list of classic
"pointless options".

Sooner or later you will encounter a corrupt or damaged document, or for
some reason you might want to directly edit the source of a document that
you had not planned to edit so if you have not already turned on the
option and if the source code is not already pretty printed it is too
late.  (I've had similar issues with Dia, which didn't always pretty print
the source XML if you were using the compressed version).

It is not the most convincing arguement but I strongly believe it does
matter that this be done the right way by default, better to err on the
side of caution.

> Though as I said I don't understand what they think they're
> actually *gaining* by not pretty-printing, given that their file
> formats are all zip-compressed anyhow, and whitespace compresses
> like a beach ball in a trash compactor even under basic Huffman
> tree compression.

Elequently put.

> Anyway, my point wasn't about whether it's good or bad for apps
> to produce XML this way; my point was that technically that's
> still valid XML, and so we should realize the possibility that
> an app *might* do it that way.

No arguement from me there.

>  > But still if is possible some genius will inevitably do it (the
>  > same kind of genius thinks writing code with no  comments whatsoever
>  > is a good idea).
>
> That's a little different; program code is pretty much always
> maintained by humans (except for a few weird edge cases like makefiles
> and lex/yacc output and some experimental AI research); XML is
> very often maintained by software.

the cost of adding it is neglidgable...

> Yes, I personally would rather keep it human-readable so that when you
> have to debug it you can, but that's a druther.

...the edge case benifits of having planned ahead and following best
practice can be significant.

Sincerely

Alan H.