Wow, first time (except the private acknowledge from Merlin), I get a
recognization of what I want to see/have. Thanks.
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. ;-).
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
