your points are well known to me as I have over a decades bug filing experience,
Thomas originally agreed that a monthly reminder would be helpful.
![my logo]()
in view of your remarks, the lack of progress and the negative feedback I shall no longer be placing this request.
if at a later date you need help with SVG testing or bug filing please contact me.
I had actually expected that lynx accessibility team would appreciate the benefits of implementation and co-operated.
regards
On 8 Sep 2008, at 13:38, Tim Chase wrote:
no, is rather ambiguous in this instance.
I interpret the terseness of Thomas's response as
0) no, xml-svg support has not lost appeal
1) no, progress hasn't been made towards developing a patch
2) life keeps him busy, so it's nowhere near the top of the stack of things to do, and lynx development is likely something he does for fun in his Copious Free Time (tm)
3) bugging monthly doesn't help move it up the stack of things to do, and may subconsciously move it down in the stack
4) the problem may remain ill-defined (how much detail, accepting what sorts of SVG documents (e.g. in-line SVG vs linked SVG), how to deal with SVG fragments that are missing helpful text such as a <title> element, how to treat the element to be displayed, and perhaps config options related to SVG control) so the path to implementation is fraught with gotchas
5) Lynx already has support for piping an external SVG reference (not inline SVG, however, though a little magic could transform an XHTML document and extract SVG fragments from within) to an external program, so *today* you can pipe it through some sed/awk/xslt transformation to learn details about the SVG
6) the fastest route to implementation is if you code it (or hire someone to code it if programming isn't your forte) and send patches -- this puts you in the driver's seat regarding the time-table and implementation details. Even if the patches you send aren't accepted into an official release, you have a locally patched version that does what you want.
-tim