broken filters in words

Inge Wallin inge at lysator.liu.se
Tue Dec 6 13:31:03 GMT 2011


On Sunday, December 04, 2011 00:29:36 Sebastian Sauer wrote:
> On 12/03/2011 04:15 PM, C. Boemann wrote:
> > On Saturday 03 December 2011 16:10:06 Jaroslaw Staniek wrote:
> >> On 3 December 2011 15:51, Sebastian Sauer<mail at dipe.org>  wrote:
> >>> On 12/02/2011 05:31 PM, C. Boemann wrote:
> >>>> On Friday 02 December 2011 09:32:56 Boudewijn Rempt wrote:
> >>>>> In Words, the following filters are broken because they convert
> >>>>> to/from the
> >>>>> old kwd format which was removed. They are still installed, though,
> >>>>> and appear in the file dialog as options (and then don't work.

That seems like a bug to me.  Why do they appear if there is no path leading 
from the format in question to one that is supported by Words (i.e. odt)?  
Does the filter chain think that .kwd is still supported?

> >>>>> [list of formats deleted]

> >>>>> 
> >>>>> At the very least, we shouldn't install them -- but should we compile
> >>>>> them
> >>>>> at all? Should the code even remain in the repositories? We've seen
> >>>>> with doc, rtf and html that if we want to reinstate support for
> >>>>> broken file formats, that we usually rewrite the complete filter
> >>>>> 
> >>>>> 
> >>>>> Some of the broken formats, like ms-write are also listed in Words'
> >>>>> desktop
> >>>>> file:
> >>>>> 
> >>>>> 
> >>>>> MimeType=application/vnd.oasis.opendocument.text;application/vnd.oasi
> >>>>> s. open
> >>>>> 
> >>>>> document.text-template;application/msword;application/rtf;text/plain;
> >>>>> ap plic
> >>>>> 
> >>>>> ation/x-mswrite;application/vnd.openxmlformats-officedocument.wordpro
> >>>>> ce ssin
> >>>>> 
> >>>>> gml.document;application/vnd.openxmlformats-officedocument.wordproces
> >>>>> si ngml .template;
> >>>>> 
> >>>>> 
> >>>>> X-Calligra-DefaultMimeTypes=application/vnd.oasis.opendocument.text,a
> >>>>> pp lica
> >>>>> 
> >>>>> tion/vnd.oasis.opendocument.text-template,application/msword,applicat
> >>>>> io n/rt
> >>>>> 
> >>>>> f,text/plain,application/x-mswrite,application/vnd.openxmlformats-off
> >>>>> ic edoc
> >>>>> 
> >>>>> ument.wordprocessingml.document,application/vnd.openxmlformats-office
> >>>>> do cume nt.wordprocessingml.template
> >>>> 
> >>>> Yes I vote we remove them from the repository
> >>> 
> >>> I would prefer to keep them + disable compile + add a comment why /
> >>> what needs to be done so if someone steps in to add/extend a certain
> >>> filter he/she could build up his work on an probably already the
> >>> existing one.
> >> 
> >> I wanted to propose that too as this is actually the way what I do
> >> with obsolete but not yet replaced code.
> >> But for others it would be enough to look in git history. If so, let's
> >> create a tag for that revision.
> > 
> > I don't have that big a problem keeping them around except I really
> > question if they are ever going to be useful. And if so then it's just
> > noise How about we remove, but tag as jaroslaw suggests, and then add a
> > READM docment to filters instead describing to how to checkout that tag
> > ?
> 
> I don't think they are just noice. The WordPerfect filter for example is
> of high quality and it would be a shame to remove it from our repository
> and lose all the time that was invested to come up with that solution.
> 
> Removing it from our repository means we will lose it. Nobody will
> pick-up or care if the code is hidden in some revision making it hard to
> view+port. I think all that code is far from "just noice" and they are
> very useful if you actually work on filters.

Definitely agree.  It's close to being my pet peeve when people say "it's in 
the history" and thereby motivating to remove something.  The truth is that 
nobody ever looks in the history, and any new people that would potentially 
fix one of the filters is just going to assume that there is nothing there.

Instead we should create a wiki page or something that describes the status of 
things and that the filters could be fixed either one by one by porting them 
to ODF or all at once (but possibly giving lower quality) by creating a kwd-
to-odt filter.

> We could also create an external repository for all kind of plugins and
> move them there.
> 
> _______________________________________________
> calligra-devel mailing list
> calligra-devel at kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel



More information about the calligra-devel mailing list