https://bugzilla.wikimedia.org/show_bug.cgi?id=8901
--- Comment #14 from Brion Vibber <[email protected]> --- It might be time to start building an RfC for 'determine next stage(s) of SVG handling'; it may be easier to track overall status on a wiki page. Within Bugzilla we should do a couple things for sure: * split out the "rsvg rendering" bugs from the fundamental bugs * find the most important-looking remaining issues and see what we have to do about them A few forward-facing questions: * should SVG source be editable on-wiki like a page? Or is it fine to stick with the upload interface, knowing that editing widgets can piggyback on that? (an editor widget could easily expose source, and use the upload interface to save) * what sort of processing support do we need in addition to serving files direct, if any? ** compression? ** minimizing? ** language filtering? ** parsing links? ** injecting wikitext? ** LTR<->RTL flipping? * what sort of editing tools do we need? ** specialized tools like chart generators/editors? How will we attach a 'type' to the file? ** general vector editors like SVGEdit? ** how do we integrate these tools into VE? ** do we need both desktop and mobile UIs? * if we serve SVGs directly to browsers in the future, do we need tools to assist with file size? ** XML minimization? ** decimating extra digits on coordinates? ** decimating points in detailed paths? * do we need/want animations support? ** is browser support for SMIL consistent, or do we need fallbacks? ** what about non-SVG browsers? fallback content, or generate something? ** what about printing mode? force fallback content, or? Whew, that's enough crazy thoughts for now. :) -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
