Recent changes to tickets

#12 OPTION MIME Support

David Costanzo — Sun, 02 Jun 2019 15:58:44 -0000

status: open --> closed

#12 OPTION MIME Support

מיכאל — Mon, 27 May 2019 01:06:20 -0000

great now

#12 OPTION MIME Support

David Costanzo — Sun, 26 May 2019 21:19:24 -0000

This one limits the width of the window resizing to the screen's width. It's not perfect, as you may still have to move the window to see the content, but I don't intend to fix that. I've already put too much time into this.

#12 OPTION MIME Support

מיכאל — Sun, 26 May 2019 17:35:37 -0000

The width of the monitor screen should determine the width of the window.
Sometimes the window is very wide and goes beyond the boundaries of the screen.

#12 OPTION MIME Support

David Costanzo — Sun, 26 May 2019 16:05:08 -0000

I disagree with your argument that it's incorrect for a client to reformat content which a server provides. For example, if the server were actually returning full HTML documents (complete with <html>, <head>, <body>, and <script> tags), I think the client would have an obligation to modify that HTML as it concatenates the definitions from several databases into a single document. The Dict extension does not do this, nor do I intend to make it do this, but I think it's incorrect that it doesn't.

As for your observation that <CODE> tag could interfere with the formatting from the server, I agree with that. There was also a bug in the previous attachment that included a newline from the MIME header in the definition, which I think is the line break that you were seeing.

This new attachement, which I consider to be a release candidate, no longer adds the <CODE> for text/html content. It uses CSS to add spacing between definitions.

#12 OPTION MIME Support

מיכאל — Sun, 26 May 2019 12:30:23 -0000

Very good. However, the result may be ideal if you remove the CODE tag or change its modifiers so that there is no effect on the line break. Now this tag manifests itself as if the characters ‘\ n’ are replaced with the tags
. I consider that such behaviour is not correct since MIME header:

Content-type: text/html; ...

determines the type of information as a hypertext — a subtype html points to that text format wich already exists with all needed tags and extra tags are not needed.

... Michael

#12 OPTION MIME Support

David Costanzo — Sat, 25 May 2019 09:26:52 -0000

Thanks for the explanation. I see now that I had misread the RFC. For dictd, the MIME header is blank, not missing. That is conforming and it means to assume plain/text.

I got something working, which I have attached as @dict.xpi. I haven't tested it much or even commited the code changes, but I got the HTML for 02580 to appear and I'm too tired to continue tonight. As I mentioned above, to install it, you'll have to into "about:config" and disable code signing on all extensions.

By the way, if you log into SourceForge and use the Web interface to reply to this ticket, instead of replying by email, it will look better when viewed from SourceForge.

#12 OPTION MIME Support

David Costanzo — Sat, 18 May 2019 22:40:58 -0000

I looked into this today, but wasn't able to figure out how to get a DICTD server to return the mime content.

The protocol looks simple, the client should send

OPTION MIME

And the server replies with

250 ok - using MIME headers

But, even so, subsequent responses to DEFINE commands are missing the content-type/content-encoding headers.

I tried heb-rus_strong on dict.bibleonline.ru, but I wasn't able to discover words in that dictionary. Can you provide a word that is in the heb-rus_strong dictionary and which has MIME content that I can use for testing?

By the way, I also saw your bug report on dictd, made at about the same time as this request. Is it possible that the dictd servers which I'm talking do don't support OPTION MIME, even though RFC 2229 says that all servers must support it?

#12 OPTION MIME Support

David Costanzo — Sat, 13 Oct 2018 14:39:17 -0000

I was able to build dict-extension on Windows XP and load it into the now-unsupported Firefox that was on the machine. To load the extension, I had to go into "about:config" and disable code signing on all extensions. Presumablly, if you running an unsupported web browser on an unsupported operating system, you don't care much about security and so this wouldn't upset you.

However, you're the only person who would ever be able to use this, and only until your Windows XP machine dies, so if I did implement this feature, I'd be doing it for you alone (I wouldn't even be able to use it) and you'd only be able to use it for a limited time.

If the DICTD servers supported an HTTP-based protocol, then I think I'd be able to write a new "dict-extension" that could run on modern Firefox browsers. I was thinking of writing one that used Wictionary instead, but then I figured someone else would eventually do that and do a better job than I could do. Do the modern DICT servers have an HTTP protocol for information exchange (as opposed to the web view)? Or does using HTTP defeat the whole purpose of DICT?

By the way, my volunteer programming time is currently going to a fairly large task on a different project that I think will take at least six more months to complete. Once that's done, I'll take another look a this, with no promises to implement it.

#12 OPTION MIME Support

מיכאל — Thu, 27 Sep 2018 06:40:22 -0000

All clear. I have Windows XP. Firefox is no longer updated (thank God!). Maybe for this reason I can still use your extension.