On Thu, Aug 07, 2003 at 10:45:18AM +0200, August Mayer wrote:
> I'm sorry if I sounded rude, but I want to start a discussion about this.
'wontfix shows ignorance' isn't a very diplomatic way to start this.
> GIF export is a very important feature, as long as OOO can only export HTML
> with GIF graphics. For example, it is impossible with the Debian version
> to export Impress presentations as HTML, which is a quite commonly used feature.
> Moreover, technically inexperienced people don't know
> that this is specifically a Debian problem, because the exporting works with
> other OpenOffice.org versions.
I agree that it is very annoying that we have to do this.
> It would be interesting how the other distributions handle this problem.
They don't have such strict rules about what gets into the distro.
> Also, if the LZW functionality is centrally provided in some library,
> maybe it would be possible to also ship a non-free version with a LZW
> compression enabled, as is done with e.g. the GIMP.
I _have_ looked into this and its not a quick job by any means. I know the
bug is marked as 'wontfix', but it's more like 'will take a long long time
to fix and needs a lot doing before we can get to it'. Our problem is, we
need to be able to split the packages up becuase single libraries can't be
built outside the source without having their dependendent libraries
available. Both of those problems are mentioned in TODO:
* Replace LZW compression algorithm. Save to Web in writer will not work if
there are graphics in the document, because writer converts all bitmaps to
GIFs using the patented LZW compression algorithm which we have disabled.
See http://www.openoffice.org/issues/show_bug.cgi?id=4950
* Split source into several pieces. At 130MB of source and 90MB of .debs,
OOo is the biggest single package in Debian and updates will cost a lot in
network bandwidth, however small the changes are. We need to split the
source into separate independent units, and the easiest method will be to
split along lines similar to how OOo is split into projects.
The first program that needs extracting is the build tool, dmake. There is
a tempfile vulnerability that prevented me from uploading it as a separate
package. There are filed upstream issues for both of these that are over a
year old, requesting that work be done on removing the patented code. No
other developers worked on these issues.
I actually made a fix for dmake a few weeks ago and, as time permits, will
work on the split. But my time is extreemly limited and my main priority is
keeping the existing packages up to date and uncovering potential problems
before the 1.1 release.
> Also, if Debian developers choose to dig into the code and remove the GIF
> support,
'Debian developers' in this context is just one person, me. There are no
unlimited resources secretly working on all of this. Just one person doing
the patching of actual C++ code for Debian. I made the absolute minimum of
changes needed, no nice error checking, no nice messages. I would love to
do more but I just don't have the time to do everything I would like to all
in my spare time.
> they could also dig only a bit further and change it around to exporting PNGs.
It isn't anywhere near 'a bit further' becuase I'm not familiar enough with
the code, and I would have to learn about how OOo works with bitmaps, how
the PNG library works, work around differeneces in the APIs etc. etc. I
can't do all that in the time I have.
However, I did actually talk to Michael Meeks at Ximian a few days ago on
IRC. As well as saying that the existing .GIF export is pretty bad anyway
becuase the quality is so awful, he mentioned that he hopes to add optional
support for web exporting to PNGs instead.
> I don't think that it's an option to wait until the LZW patent has
> expired somewhen. People need solutions right now, and I, for example,
> won't use the Debian packages until this is fixed. It's also not an option
> in my opinion to let the users compile their own packages; this would mean
> downloading the huge source code of the package, and mastering the
> compile process.
I do not disagree with you. As you point out, OOo is so huge that it is a
problem to do any small job with it, and I think you'll therefore understand
that making changes takes a long time and won't happen instantly while the
team is so small and is working on this in their spare time.
Chris
Attachment:
pgpLNke2z8pL5.pgp
Description: PGP signature