On Tue, Jul 10, 2012 at 8:56 AM, Achim Flammenkamp <[email protected]> wrote: > Wow, first time (except the private acknowledge from Merlin), I get a > recognization of what I want to see/have. Thanks.
You're welcome! I think the concept isn't something that everyone on the list has been saying to themselves, "I've been waiting for that!", so it's probably a smaller group of people who are going to jump in on the topic. > On Tue, Jul 10, 2012 at 07:24:14AM -0700, Chris Steipp wrote: >> >> I looked into this for you. It's not a very complicated situation. > Maybe I used the wrong english when firstly advertise my problem/wish here > yesterday. ;) > >> There is a security consideration that unfortunately will add some >> complexity, if this is going to be deployed on wmf sites. It may be >> part of the reason 5899 was never deployed. SVGs can include >> javascript which is a security concern, and remote images and css >> references which can violate our privacy policy. > But this still is the case for the uploaded SVGs now, isn't it? > To keep things simple, handle SVG-pages/SVG-files EXACTLY like article-, > user-, talk-, category-, ... etc pages on wikimedia-foundation EXCEPT ONE > SITUATION: when displaying this kind of page. Let's call it (for simplicity > and marking/context-handling) a page of category SVG (later this may be > extended to other XML-syntax, but this is a far aimed future :) ). > > Run all kind of processes (some useless/ obviously meaningless filters maybe > avoided) to keep administration as easy and as similar as text-pages (and > because it is a text-page!). > >> So at minimum, we would need to re-run the image through our filtering >> (currently UploadBase::detectScript()) before it's saved, and throw an >> error if any scripts are detected. Or, we can do what we do with >> wikitext and convert/filter the output just before we display it, > What do to when displaying/uploading such an SVG-file then? I propose > (feel free to improve): It MUST start with "<svg .... > (implicitly assuming e.g. <?xml version="1.0" encoding="UTF-8" ... ?> > <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" ...> > ) > and then everything until and including the matching (nested <svg> are > possible > and comments or literal text in quotes may occur) </svg> will be passed to the > SVG_to_bitmap converter which already exists and works -- a bit buggy. ;-). So if I'm understanding you, then if you go to http://commons.wikimedia.org/SVG:myPic.svg, you see an article-like rendering of the xml that makes up the svg. You can then edit the xml like a normal article. Whenever the "article" is saved, if it contains a <svg></svg> object, and if the native size is less than 1024x2048 (or can be correctly scaled to a size smaller than this), then we also create a bitmap/png at the native or scaled resolution. There would then be some sort of action to call the bitmap for display, maybe http://commons.wikimedia.org/SVG:myPic.svg?action=bitmap, that would show the generated bitmap, with the correctly set content-type header, probably "image/png". This could then be used inside <img> tags, etc. If that's the case, then that addresses the security issues of having javascript / external references in the picture. However, that then prevents us from displaying the image as an svg, and gaining the advantages of that format (i.e., smaller size for simple images). But it may be a good first step, until we can put into place strict output rules for what xml is allowed in the svg. > > This should result in a rendered bitmap of a known boundingbox in pixels which > is displayed as a bitmap, followed by the remainding text (after this matching > </svg>-token) of the SVG-page like any other wikipedia-text page below this > rendered image on the displayed page. Typically this remainding text should > contain the currently so-called description of the image, but NOTHING FIXED > given (like now generally for image-files) - everything is changable by the > user. > >> according to a set of rules of what entities and attributes are >> allowed, which will be very different from the set that are used for >> html. > So we only need to take care what this "SVG_to_graphic converter" may/can do > with this svg-code. But such a thing already is done/exists if displaying now > SVG-files on wikimedia/wikipedia. Thus I believe nothing new is to invent. But > e.g. we may ignore attributes like <image> or similar commands which would > cause triggering of further external software, not only this/our rendering > algorithm -- do it like it is now done (if you take no time to improve it). :) > >> So because of that, I think it will be a bit of work-- but at the same >> time I think it's great someone is tackling the issue! Maybe you would >> be able to leverage the work that's going on with content type >> handling (http://meta.wikimedia.org/wiki/Wikidata/Notes/ContentHandler)? > I can and will try to help as I am able with best knowledge and best > conscience. > Hence I will next throw a view to this URL. > > A technical remark: the SVG-code will impose certain width/height conditions > and colorfullness of an image. I don't know whether it makes sense to restrict > the colorfullness? But if the SVG code defines a say 9 x 87654321 pixel-image, > we are best not to satisfy this demand. :-) Let's define (just a quick shot): > 1) width <= 1024 pixel, height <= 2048 (browser are typically/easily scrolling > down and up but more difficult to scrolling left/right for humans) and > moreover > try to preserve the original aspect ratio. Which in this case would result in > a > empty image, but a displayed warning "this image is 9 x 87654321 sized, but > nothing is displayed to avoid inconvience" or a similar standard statement. > I think it is bad to try to find a "somehow" displayable transformation of > such > an image. I even would gave a warning for a "12345x6789" image which is > displayed as "1024x563" that exact aspect ratio could not be preserved. And a > "12345x67890" image would be displayed as "823x4526" image to preserve the > exact > aspect ratio. > > Sorry, the previous lengthy paragraph is not well-tought by me -- but it is a > minor technical note which must be solved in reality. > > BTW: Whether to check/filter when storing new versions (or creating a first > one) > or when displaying its content, is a question of payload, IMHO. I would guess > to check after each change occurs, this should be more practicable. > > BTW2: If you have problems imagining SVG-code as a natural language, consider > it as an Arabic language coded with english words which letters/font/writing > you have to display. :-) > > Achim > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
