#9 Muffin maybe has quirks with non-html

[Anonymous]

Hi,

I just wrote a new filter to transform the text of text-files being processed by Muffin. It works quite well (so far) on the text of HTML files, but it has a weird effect with other files (regular text, CSS, that sort of thing):

If the file contains no text that matches the rules in my filter, everything is OK.

If the file contains something that does match, the contents of the file do not get through.

For instance, if my filter were looking for the text
"font-family", it completely blocks all the contents of any cascading stylesheet (in a separate .css file, not in an HTML file) that changes any font-family property.

My filter implements ContentFilter and uses the InputObjectStream and OutputObjectStream to communicate with the environment (the rest is regex matchng and lookup in a Hashtable). Perhaps these classes make an untoward assumption about the data consisting of HTML?

[Ben Tels]

Logged In: YES
user_id=115918

Never mind -- solution found in another location.

Not a bug; please consider report withdrawn.

[Kyle Hamilton]

Logged In: YES
user_id=7718

So where was the problem?

[Kyle Hamilton]

Logged In: YES
user_id=7718

So where was the problem?

[Ben Tels]

Logged In: YES
user_id=115918

In an assumption I have made on token typing. With the correct assumptions, its works. As it turns out, however, token typing isn't even necessary, so my filter is even more general than it was before.

[Julian Morrison]

Logged In: YES
user_id=21754

Here's something that may be related... go search on google,
via muffin, and it's broken. It's broken if filtering is
enabled (via the file menu) even if there are *no* actual
filters active, yet it is not broken when filtering is
disabled via the file menu. That might help you hunt the bug.