PHP mentoring program

List overview All Threads
Download

newer

older

Announcement: Peter Youngmeister...

How to display the title with...

Sumana Harihareswara

9 Jul 2012 9 Jul '12

9:58 a.m.

http://phpmentoring.org/ #phpmentoring on Freenode IRC Mentoring and apprenticing are ways to learn, get recognition, get advice and find new opportunities, and find role models (or become one). Check it out. -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation

Show replies by date

Achim Flammenkamp

9 Jul 9 Jul

10:17 a.m.

New subject: Maintaining (and thus editing) SVGs' text like wiki text-pages

Hello It is now quiet silent, since 19. June, after I opened this topic about on 6th june on wikipedia. The latest discussion is stored at URL http://commons.wikimedia.org/wiki/Commons:Village_pump/Archive/2012/06#Main… I wonder what has happened. This was also the 3rd different try/community on wikimedia where I opened this subject but noone felt responsible. I hope I'm not too impatient to get a response here about the current status, don't I? Thanks, achim

MZMcBride

8:27 p.m.

New subject: Maintaining (and thus editing) SVGs' text like wiki text-pages

Achim Flammenkamp wrote:

...

It is now quiet silent, since 19. June, after I opened this topic about on 6th june on wikipedia. The latest discussion is stored at URL http://commons.wikimedia.org/wiki/Commons:Village_pump/Archive/2012/06#Main… ning_.28and_thus_editing.29_SVGs.27_text_like_wiki_articles I wonder what has happened. This was also the 3rd different try/community on wikimedia where I opened this subject but noone felt responsible. I hope I'm not too impatient to get a response here about the current status, don't I?

Hi. I looked into this for you. It's not a very complicated situation. <https://bugzilla.wikimedia.org/show_bug.cgi?id=5899> is a bug titled "Allow on-wiki editing of SVG images". This bug was marked resolved/fixed by Brion in 2010 because the original bug was about having the _ability_ for such a feature (editing SVGS on-wiki) while using the MediaWiki software. This was implemented in the SVGEdit extension (<https://www.mediawiki.org/wiki/Extension:SVGEdit>; cf. Brion's comment here: <https://bugzilla.wikimedia.org/show_bug.cgi?id=5899#c24>. You can also read the bug's full history (except comments) here: <https://bugzilla.wikimedia.org/show_activity.cgi?id=5899>. Where this got off the tracks is that you don't want to re-open bug 5899. That was a mistake. I marked bug 5899 resolved/fixed again; it should stay in that state. I filed a separate bug about reviewing and deploying the SVGEdit extension to Wikimedia wikis here: <https://bugzilla.wikimedia.org/show_bug.cgi?id=38271>. CAVEAT: Getting an extension deployed to Wikimedia wikis is usually an enormous pain in the ass, especially if it's not a priority for the Wikimedia Foundation. You'll likely need to either commit to fixing the code yourself or providing the necessary resources to fix the code, assuming you can get it reviewed by the appropriate person (there are few people in a position to do this). It's often a very arduous and frustrating process. Just a fair warning before you get too invested in the idea. MZMcBride

Achim Flammenkamp

10 Jul 10 Jul

6:04 a.m.

New subject: Maintaining (and thus editing) SVGs' text like wiki text-pages

...

I looked into this for you. It's not a very complicated situation.

I agree -- but I get really desperate now, because *** It is NOT Bug 5899 (editing SVGs on-wiki or similar)! *** :-( In contrast, it is in principle a simple to solve issue, because everything already exists: /* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */ /* */ /* SVG-files should be treated like article-, template-, */ /* user-, category-, talk- ... pages on wikimedia/pedia! */ /* */ /* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */ Thus means version-control tools are usable for SVG-file/SVG-text and administration of these *svg is like the just listed, NOT like other (bitmap-/binary-)graphic-files, because SVGs are effectivly human-readable language-text in strict (XML-) syntax! WHY do mostly people missunderstand this subject? ;-/ (The thread on wikimedia is so long, because in 80% *I* had to emphazise, that this is no SVG-editor feature!) Thanks for giving my posting a thought, even if sadly (once more) a miss- understanding resulted. :-/ Do I get a new try of someone(somefews) here? Achim

Chris Steipp

10:24 a.m.

New subject: Maintaining (and thus editing) SVGs' text like wiki text-pages

...

> I looked into this for you. It's not a very complicated situation.

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. 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, 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 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)?

Achim Flammenkamp

11:56 a.m.

New subject: Maintaining (and thus editing) SVGs' text like wiki text-pages

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. ;)

...

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

Chris Steipp

12:35 p.m.

New subject: Maintaining (and thus editing) SVGs' text like wiki text-pages

On Tue, Jul 10, 2012 at 8:56 AM, Achim Flammenkamp <achim(a)uni-bielefeld.de> 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. ;)

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.

Achim Flammenkamp

1:03 p.m.

New subject: Maintaining (and thus editing) SVGs' text like wiki-text pages

On Tue, Jul 10, 2012 at 09:35:04AM -0700, Chris Steipp wrote:

...

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.

I don't know what you mean by "go to" and "article-like rendering of the xml" I meant: If you call the URL http://commons.wikimedia.org/SVG:myPic.svg you will see (assuming it exists and everthing works correctly) nearly the same as you see now for such an URL (with File inplace of SVG). Only the "lead in"/ introdcution of the displayed page is different. It only contains ONE or NONE rendered bitmap if this SVG-file (and maybe a warning/error(?)). Then followed by all the description stuff which is also displayed currently for SVG-files.

...

You can then edit the xml like a normal article. Whenever the "article" is saved, if it contains

Yes! You can edit this myPic.svg -page like any article (talk/user/template/...) page (and this is supported also by this version-control stuff, etc)!

...

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.

Yes, this maybe done behind the scene technically. But even if the image is 9x87654321 no error is thrown and you can edit it again or let it be displayed (given an empty image and a standard warning) followed by possible description.

...

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.

??? It is called for display as it is called for display NOW! :) No change IMHO URL http://en.wikipedia.org/wiki/SVG:myPic.svg like now URL http://en.wikipedia.org/wiki/File:myPic.svg (because it has its own categoary like articles, like talk-pages, like user-pages, like template-pages) You can call it from anywhere inside wikimedia/wikipedia with [[SVG:myPic.svg]] as it is currently called with [[File:myPic.svg]] .

...

If that's the case, then that addresses the security issues of having javascript / external references in the picture. However, that then

I don't see you security problem/point. If this exists, then it exists already currently for File:myPic.svg. And if it is solved (with filtering or what ever check done with SVG-uploaded files), do the same checks/filter for SVG-pages when uploaded/changed. Which xml-code is now allowed in SVG-uploaded (and displayed/used) files? Take the same rules (if you don't take the time to improve them :) ). Sorry, I still don't recognize the (new inserted by my proposal) security problem. :-/ Achim

Derric Atzrott

1:22 p.m.

New subject: Maintaining (and thus editing) SVGs' text like wiki-text pages

...

??? It is called for display as it is called for display NOW! :) No change

IMHO

...

URL http://en.wikipedia.org/wiki/SVG:myPic.svg like now URL http://en.wikipedia.org/wiki/File:myPic.svg (because it has its own categoary like articles, like talk-pages, like

user-pages, like template-pages) Not to nitpick, but those are Namespaces not categories. Categories do get their own Namespace though (Category:). I think that this is a great idea. And I agree with Achim in that if we have a filter in place for uploaded SVG files, why don't we just apply that when the page is saved? Thank you, Derric Atzrott

Chris Steipp

3:13 p.m.

New subject: Maintaining (and thus editing) SVGs' text like wiki-text pages

...

Not to nitpick, but those are Namespaces not categories. Categories do get their own Namespace though (Category:). I think that this is a great idea. And I agree with Achim in that if we have a filter in place for uploaded SVG files, why don't we just apply that when the page is saved?

So that is the change that will take some work-- right now there's code to process uploading files, and code to save articles... the file upload code is not run on article text to be saved.

Derric Atzrott

3:28 p.m.

New subject: Maintaining (and thus editing) SVGs' text like wiki-text pages

...

So that is the change that will take some work-- right now there's code to process uploading files, and code to save articles... the file upload code is not run on article text to

be saved. A quick skim through the UploadBase.php file shows that the code for checking SVG files is in UploadBase:: detectScriptInSvg( $filename ). This method creates a new XmlTypeCheck() with a callback to UploadBase ::checkSvgScriptCallback() which in turn checks each element and attribute to make sure they are not blacklisted. Why not make UploadBase:: detectScriptInSvg( $filename ) et al. a static method, and replace the few references to $this that are found in UploadBase ::checkSvgScriptCallback() with static or self. This was just a quick looking through, but it /at first glance/ does not appear that it will require tremendous amounts of effect to make the code for processing uploaded files work for saved pages. The rest of the modifications that would be needed (creating new namespace, modifying how pages are displayed, etc.) I can't begin to guess at the difficulty of, but that one at least looks fairly straight forward. Thank you, Derric Atzrott

Achim Flammenkamp

3:53 p.m.

New subject: Maintaining (and thus editing) SVGs' text like wiki-text pages

On Tue, Jul 10, 2012 at 03:28:55PM -0400, Derric Atzrott wrote:

...

A quick skim through the UploadBase.php file shows that the code for checking SVG files is in UploadBase:: detectScriptInSvg( $filename ). This

.....

...

The rest of the modifications that would be needed (creating new namespace, modifying how pages are displayed, etc.) I can't begin to guess at the difficulty of, but that one at least looks fairly straight forward.

It seems to be best, if I shut my mouth now and not offer further design ideas. ;) Best wishes, Achim

MZMcBride

5:58 p.m.

New subject: Maintaining (and thus editing) SVGs' text like wiki-text pages

Achim Flammenkamp wrote:

...

On Tue, Jul 10, 2012 at 03:28:55PM -0400, Derric Atzrott wrote:

A quick skim through the UploadBase.php file shows that the code for checking SVG files is in UploadBase:: detectScriptInSvg( $filename ). This

.....

It seems to be best, if I shut my mouth now and not offer further design ideas. ;)

Right... I think you're being a bit obstinate in this thread. You have a specific implementation idea, which is fine, but I think it sucks. An SVG namespace with XML in the textarea is frankly just a terrible idea. XML is a complete pain in the ass to edit by hand. Does anyone edit SVGs this way unless forced to? Did you look at <https://www.mediawiki.org/wiki/Extension:SVGEdit> and the demo at <https://toolserver.org/~brion/svg-edit/svg-editor.html>? It's open source, maintained, it has good browser support, and Brion has already done some of the heavy lifting moving it into a MediaWiki extension. It's a visual editor (which covers over 99% of users), but it also includes the ability to view and modify the raw underlying SVG code. In my estimation, I would say that SVGEdit is about 1000 times more likely to be deployed to Wikimedia wikis than your proposal of creating an SVG namespace and simply dumping XML into pages. Resources are painfully finite and your proposed solution just seems painful. That said, if this idea from Daniel Kinzler ever comes to fruition, it sounds remarkably similar to what you want to do: <http://lists.wikimedia.org/pipermail/wikitech-l/2012-March/059358.html>. Perhaps some mixture of your idea and a visual frontend could be implemented. Your past posts on this subject make it seem like you're completely focused on _only_ raw SVG code editing, though. I don't think pursuing that path forward (alone) is a good idea. MZMcBride

Achim Flammenkamp

6:33 p.m.

New subject: Maintaining (and thus editing) SVGs' text like wiki-text pages

On Tue, Jul 10, 2012 at 05:58:30PM -0400, MZMcBride wrote:

...

Achim Flammenkamp wrote:

On Tue, Jul 10, 2012 at 03:28:55PM -0400, Derric Atzrott wrote:

A quick skim through the UploadBase.php file shows that the code for checking SVG files is in UploadBase:: detectScriptInSvg( $filename ). This

.....

It seems to be best, if I shut my mouth now and not offer further design ideas. ;)

Yes, me. It is fine to edit -- no problems with it. YOU seem to have a seriously personal problem/prejudgment of this kind of text. Did you every wonder why XML/SVG should be human readable? Besides, I don't like your sucking ****-wording. :-( Regards Achim

MZMcBride

9:27 p.m.

New subject: Maintaining (and thus editing) SVGs' text like wiki-text pages

Achim Flammenkamp wrote:

...

Yes, me. It is fine to edit -- no problems with it. YOU seem to have a seriously personal problem/prejudgment of this kind of text. Did you every wonder why XML/SVG should be human readable?

Well, I look at eleven years of forcing people to edit wikitext and, yes, it provides some guidance that if you want something scalable and sane, having people manually edit code (in this case, XML) is probably a step in the opposite direction. The Wikimedia Foundation finally has its eye on the right ball and is on its way (God-willing) to creating a decent visual editor. Given that SVG editors are already as far along as they are, I think stepping forward in the direction of SVGEdit is dramatically smarter than encouraging people to dump XML into wiki pages. Volunteers are obviously free to work on and contribute whatever code they'd like, of course. I'm looking at this from the perspective of getting something like this enabled on Wikimedia wikis. From your previous posts, that seems to be your focus as well. You don't seem to be looking at the generic ability to do this, you seem focused on Wikimedia Commons in particular. In that case, there are finite resources and, to me, they seem far better spent on working toward solutions that cover most users, not users who like manually editing XML (bless their cotton socks). (And I think it's worth reiterating that the demo editor at <https://toolserver.org/~brion/svg-edit/svg-editor.html> _has_ the ability to edit the underlying SVG code. If it didn't, I'd have an easier time understanding your point of view.)

...

Besides, I don't like your sucking ****-wording. :-(

I'm not quite sure what you intended here (the bowdlerization is awkward), but yes, it helps to look past the tone and focus on the substance. In any case, I only stepped into this thread because you sounded so desperate and frustrated, but you've clearly got your own views about how this should be implemented and I wish you all the luck in the world in trying to get there. I've outlined why I think you won't get very far (and this comes after studying the Wikimedia beast for a fair number of years), but if you prove me wrong, I'm okay with that. :-) Maybe one day we'll all be editing XML in an SVG namespace on Commons using an HTML textarea, but God I hope not. MZMcBride

Achim Flammenkamp

11 Jul 11 Jul

5:52 a.m.

New subject: Maintaining (and thus editing) SVGs' text like wiki-text pages

Hi On Tue, Jul 10, 2012 at 09:27:16PM -0400, MZMcBride wrote:

...

Achim Flammenkamp wrote:

Yes, me. It is fine to edit -- no problems with it. YOU seem to have a seriously personal problem/prejudgment of this kind of text. Did you every wonder why XML/SVG should be human readable?

Well, I look at eleven years of forcing people to edit wikitext and, yes, it provides some guidance that if you want something scalable and sane, having

... Sorry, I'm not in the mood to support your subjective/psychologic talk. As you are unwilling or unable to give objective reasons which could maybe convince me why not to edit SVG-text, I will not reply to your lengthy monolog -- I'm also a volunteer (with different expierience than you), but not use this fact to change my behaviour and try as always to keep a scientific attitude when "acting".

...

Besides, I don't like your sucking ****-wording. :-(

I'm not quite sure what you intended here (the bowdlerization is awkward),

I was told 'bad language' is the correct/official/common wording for

...

> > XML is a complete pain in the ass to edit by hand.

Thanks for telling us your opinion, Achim

Denny Vrandečić

6:32 a.m.

New subject: Maintaining (and thus editing) SVGs' text like wiki-text pages

Achim, MZ was trying to be helpful and constructive. The two of you, and many others here, have the same goal: providing more and more people with more and more possibilites to collaboratively work at more and more artefacts and type of artefacts that will be useful to a bigger and bigger audience. You have started this thread with the complaint that you did not get enough response to your idea, in several places. MZ offered that the suggestion of providing the Wikimedia community with the possibility to edit SVG as XML in a plain text-editor does not excite too many people. He offered you an alternative, an actual SVG editor. You dismissed that. He wished you good luck with pursuing your goal. I fully agree with his assessment of the situation and of the chances of getting a critical mass of people excited for your approach -- which is what you need in the end to see your plan to come to fruition. The way and tone of your answers to the criticism offered could give some hints towards an explanation of why there is an apparent lack of response to your ideas. So, in the same way: Good luck with achieving your project! I am looking forward to the day where as many people as possible are enabled to collaborate on vector graphics. Cheers, Denny 2012/7/11 Achim Flammenkamp <achim(a)uni-bielefeld.de>de>:

...

Hi On Tue, Jul 10, 2012 at 09:27:16PM -0400, MZMcBride wrote:

Achim Flammenkamp wrote:

Yes, me. It is fine to edit -- no problems with it. YOU seem to have a seriously personal problem/prejudgment of this kind of text. Did you every wonder why XML/SVG should be human readable?

Well, I look at eleven years of forcing people to edit wikitext and, yes, it provides some guidance that if you want something scalable and sane, having

Besides, I don't like your sucking ****-wording. :-(

I'm not quite sure what you intended here (the bowdlerization is awkward),

I was told 'bad language' is the correct/official/common wording for

> > XML is a complete pain in the ass to edit by hand.

Thanks for telling us your opinion, Achim _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

-- Project director Wikidata Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. +49-30-219 158 26-0 | http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

Achim Flammenkamp

6:55 a.m.

New subject: Maintaining (and thus editing) SVGs' text like wiki-text pages

On Wed, Jul 11, 2012 at 06:32:21AM -0400, Denny Vrande??i?? wrote:

...

Achim, MZ was trying to be helpful and constructive. The two of you, and many

... Sorry, you were too fast -- or were I too slow? ;) Cheers, Achim

Achim Flammenkamp

6:51 a.m.

New subject: Maintaining (and thus editing) SVGs' text like wiki-text pages

Hi I think I should give your, MZMcBride's, word's a 2nd chance not only to cancel-down your (probably meant with good faith) comments, I excuse therefore. My aim is the have on wikimedia/wikipedia (/wiki-whatever sounds apropriate) 1) a version-control environment (as we have for artcile-, talk-, user-, category-, template- ... etc (text-)namespace), because it is IMHO apropriate for each (huamn-readable) textual namespace. SVG has a (I guess historcial) exception, because it was new and was sorted in like (bitmap-) graphics (JPEG/PNG or what ever exists only on wikipedia) (badly classified IMHO). 2) any textual namespace edit freely and completely for the user (thats not the case vor SVGs) To realize this in the kind and manner I suggest, keeps things very simple and consistant! If you prefer a technical complicated different solution with many specialities and exceptions, but which gives for the user the attributes 1) and 2) I will not protest, as long as you act and realize this. SVGedit (or whatever you like to call an editor for the special SVG-syntax) is a total different point and indepent(!) of my wish/idea/proposal. With your view, you could also deny to edit arcticle-, user-, ... etc namespaces online on wikimedia/wikipeda because of its akward <math>, ''', :-indent, <ref>, etc syntax. :-/ My just formulated words are intended to keep people down to a more objective point of view --- should I mention my far longer expierence of programming than yours, MZMcBride? I believe not -- but in the case anyone is interested he should have a look on my user-page in my home-wikipedia on en-wikipedia. :-/

...

something like this enabled on Wikimedia wikis. From your previous posts, that seems to be your focus as well. You don't seem to be looking at the generic ability to do this, you seem focused on Wikimedia Commons in particular. In that case, there are finite resources and, to me, they seem

Yes, because I was told this is a topic focusing mainly on wikimedia commons. :-/

...

In any case, I only stepped into this thread because you sounded so desperate and frustrated,

Yes I was indeed and still I am if I see that people can not distinguish between an SVGeditor (which may be fine) but which is a total different point than mine. :-( Regards, Achim

Marcin Cieslak

15 Jul 15 Jul

6:36 a.m.

New subject: Maintaining (and thus editing) SVGs' text like wiki-text pages

...

Achim Flammenkamp <achim(a)uni-bielefeld.de> wrote:

My aim is the have on wikimedia/wikipedia (/wiki-whatever sounds apropriate) 1) a version-control environment (as we have for artcile-, talk-, user-, category-, template- ... etc (text-)namespace), because it is IMHO apropriate for each (huamn-readable) textual namespace. SVG has a (I guess historcial) exception, because it was new and was sorted in like (bitmap-) graphics (JPEG/PNG or what ever exists only on wikipedia) (badly classified IMHO).

I don't think that version control we offer with article revisions is a proper one for any kind of XML, including SVGs. For git fanbois: yes, git does not solve that, either. The problem is that you have to think in terms of nodes, their attributes and contents and not their textual form. I pretty often add/remove spaces and newlines when editing XML by hand for clarity; that should not be versioned as this does not change the substance. I am editing SVG files by hand pretty often (using vi for simple things and XMLmind's xxe for more complex stuff) to fix various problems related by users, like missing namespaces, wrong CSS, etc. But I wouldn't really want to do that within some textarea interface within MediaWiki. Maybe, for the purpose of educating users, there should be some way to pretty print XML source of the SVG file - but unless there is a decent XML node editor I don't think we this is something we need right now. //Saper

Achim Flammenkamp

10 a.m.

New subject: Maintaining (and thus editing) SVGs' text like wiki-text pages

Hi I seriously was thinking whether better to desubscribe from this list, because until now, no helpful comment came. But, Yes, one (or more?) people wrote, "great idea I like it", (and even looked up what might be done), but as soon as MZBridge gave "helpful" :-> (not my judgement!) comments, this topic was down. Thus I would judge his remark was effectively the opposite of a help what he triggered -- besides I asked for apples, he ignored this totaly but told me I should wait to use later tomatos. :( On Sun, Jul 15, 2012 at 10:36:57AM +0000, Marcin Cieslak wrote:

...

Achim Flammenkamp <achim(a)uni-bielefeld.de> wrote:

I don't think that version control we offer with article revisions is a proper one for any kind of XML, including SVGs. For git fanbois: yes, git does not solve that, either.

Sorry, but "For git fanbois: yes, git does not solve that, either." sounds like Chinese language for me. :-/ I have a feeling what git is, but see no connection. Maybe I think of the wrong git version control system.

...

The problem is that you have to think in terms of nodes, their attributes

Have I? Or do you think I should? And if you mean SVG-nodes, this you also must with article (as I wrote) with <math>, <ref>, ''', === section === , ...

...

and contents and not their textual form. I pretty often add/remove spaces and newlines when editing XML by hand for clarity; that should not be versioned as this does not change the substance.

? It should IMHO -- you are right typically this kind (whitespace) is only for human-readbale. But should I download for each such white-space change a new complete file on the other hand? Inserting whitespaces for readablity I also do for articles/talks/categorys/... and thus it is in version-control, too. And what if you like to change "red" to "#ff2000" or "2.0" in "-2.01" in a certain statement? It would GREAT to have (like in any article) version-control/diff-stuff! I want to see exactly what has changed -- like in any text-editing. What is your point to not like to support this idea, I wonder?

...

I am editing SVG files by hand pretty often (using vi for simple things and XMLmind's xxe for more complex stuff) to fix various problems related by users, like missing namespaces, wrong CSS, etc.

I too, using vim -- but I do much more logical content-work in SVG-coding.

...

But I wouldn't really want to do that within some textarea interface within MediaWiki. Maybe, for the purpose of educating

It is nearly irrelavant (for me) whether I'm editing an article or a SVG-code inside a textarea on wikimedia. On the other hand it is like I'm always forced to download a part of an article to edit it locally and then uplaod the new version like it is now for SVG! :-( This is the important (in my opinion not justified by a useful or only mentioned reason here et al) point. :-/ The syntax-SVG changing of VIM (supported by colors) is to bad for my typical hand made errors to be significant helpful -- maybe I simple doesn't make such cheap errors often. E.g. I sometimes close a <g ... with /g> in the same line wrongly and only get later the error when displaying at </g>. No syntax- color help for this kind which would help a little bit. So syntax-check for editing is a total different issue -- then support to easily recognize textual differences/changes in versions. And with this missing you even trigger people NOT to change/correct the old version but more (if they finally like) make a full new version totaly independ of the old version. :-( Remove version-control-diff-stuff from articles, force all people to change articles only offline and uploaded again for new versions then you will/might get a feeling what would be done magnificantly by adding the version-control- diff-stuff to all SVG-text.

...

users, there should be some way to pretty print XML source of the SVG file - but unless there is a decent XML node editor I don't think we this is something we need right now.

I again wonder why people are obvouisly unable/unwilling to distinguish or only to imagine, that SVG-editing (or editing of human readable text in general) is totally (logical) independent of version-control-diff-stuff of such content. :-( Unbelievable. :-( Thanks for your thoughts (even if a lot are off the point), Achim

Mark A. Hershberger

7:36 p.m.

New subject: Maintaining (and thus editing) SVGs' text like wiki-text pages

On 7/15/2012 10:00 AM, Achim Flammenkamp wrote:

...

I seriously was thinking whether better to desubscribe from this list, because until now, no helpful comment came.

You should stick around, but you should also understand that your request isn't something that Wikimedia is likely to deploy since it doesn't meet the needs of a significant part of the Wiki*-using community. Instead, since this is a tool *you* want, you should look at creating a tool that meets your needs. Since a few other people have expressed interest, maybe they would be interested in helping you. None of this requires the help of anyone at Wikimedia (or even on this list). For example, suppose you wanted to use Emacs key-bindings for editing articles (yes, some of us do want to do that). Before mediawiki.el was written (see http://launchpad.net/mediawiki-el), you would have to cut-n-paste the article into Emacs and then paste it back into the text area. That is similar to your current circumstance with SVG. You have to download the file, edit in your editor, and then re-upload it. Using the API (http://www.mediawiki.org/wiki/API:Upload), you could make it possible to use any editor you wish to edit the source of the SVG and have the result seamlessly uploaded to the wiki. You've gotten a lot of helpful suggestions here. You are asking for a feature that a very small number of people would benefit from. Even the things that *might* happen, like the SVGEdit extension, you don't seem ready to embrace it. If you think editing SVGs should be simpler, then I suggest that the best way to approach this is to find a way to work with those people like you who have similar goals. You've been told that your current idea probably isn't going to fly. Figure out a new way to get what you want. -- What is normal? Normal is yesterday and last week and last month taken together. -- Snuff, Terry Pratchett

Jon Robson

16 Jul 16 Jul

6:13 p.m.

New subject: Maintaining (and thus editing) SVGs' text like wiki-text pages

FWIW (possibly off topic) but editing the text of svgs is an idea that is very interesting. I could imagine this being extremely useful for reuse. Take the example of a map of New York on the New York wiki page. Imagine having an svg asset which is a map of the USA and an asset which is a marker. It would be great in wiki text to be able to create a new svg which transcludes these two assets to give a map of the USA with a marker positioned on top. This sort of thing would be very powerful if it could be pulled off and editing wiki text would be much more convenient in this situation in comparison to svg creation and uploading. In this particular case you could also improve the marker style once and all maps using it would instantly get the style update. Powerful stuff. On Jul 15, 2012 3:37 AM, "Marcin Cieslak" <saper(a)saper.info> wrote:

...

Achim Flammenkamp <achim(a)uni-bielefeld.de> wrote:

My aim is the have on wikimedia/wikipedia (/wiki-whatever sounds

apropriate)

1) a version-control environment (as we have for artcile-, talk-, user-, category-, template- ... etc (text-)namespace), because it is IMHO

apropriate

for each (huamn-readable) textual namespace. SVG has a (I guess historcial) exception, because it was new and was

sorted in

like (bitmap-) graphics (JPEG/PNG or what ever exists only on wikipedia) (badly classified IMHO).

Max Semenik

6:23 p.m.

New subject: Maintaining (and thus editing) SVGs' text like wiki-text pages

On 17.07.2012, 2:13 Jon wrote:

...

FWIW (possibly off topic) but editing the text of svgs is an idea that is very interesting. I could imagine this being extremely useful for reuse.

...

Take the example of a map of New York on the New York wiki page.

...

Imagine having an svg asset which is a map of the USA and an asset which is a marker. It would be great in wiki text to be able to create a new svg which transcludes these two assets to give a map of the USA with a marker positioned on top.

...

This sort of thing would be very powerful if it could be pulled off and editing wiki text would be much more convenient in this situation in comparison to svg creation and uploading. In this particular case you could also improve the marker style once and all maps using it would instantly get the style update. Powerful stuff.

Cough cough one div on top of another, position: relative. -- Best regards, Max Semenik ([[User:MaxSem]])

Achim Flammenkamp

17 Jul 17 Jul

5:56 a.m.

New subject: Maintaining (and thus editing) SVGs' text like wiki-text pages

Hi I only want to grap a chance to point you (the community meant) but explicitly (from a currently stated reply) to your (plural your) subjective view:

...

> > But I wouldn't really want to do that within some textarea > interface within MediaWiki. Maybe, for the purpose of educating > users, there should be some way to pretty print XML source > of the SVG file - but unless there is a decent XML node editor

This is your concret personal opinion for your feeling of your private situation. But if we would hace realized my identical administration to text-namespace of SVG-namespace then you still can download any (old) version to whatever and howevery you can and like edited/change locally and after this completely upload the data as a new version (ignoring simply all additional features). On the other hand, as long as we have not realized my aim, I can't work as I like do to! So your subject feeling is supported in either of the two cases, but mine not. :-/ You argue here like my aim would destroy current possibilities, but in reality the current one denys many possibilities/options. This is a far more objective over-all-estimate. And the price/effort for realization is ridiculous low, IMHO. Regards achim

Nikola Smolenski

11 Jul 11 Jul

3 a.m.

New subject: Maintaining (and thus editing) SVGs' text like wiki-text pages

On 10/07/12 23:58, MZMcBride wrote:

...

namespace with XML in the textarea is frankly just a terrible idea. XML is a complete pain in the ass to edit by hand. Does anyone edit SVGs this way unless forced to?

I do.

Achim Flammenkamp

10 Jul 10 Jul

3:47 p.m.

New subject: Maintaining (and thus editing) SVGs' text like wiki-text pages

...

> Not to nitpick, but those are Namespaces not categories. Categories do get > their own Namespace though (Category:).

Yeah.

...

So that is the change that will take some work-- right now there's code to process uploading files, and code to save articles... the file upload code is not run on article text to be saved.

A note which I made a few weeks ago on wikimedia regarding this "work". I cite: "I think to realize such a feature an expert Wiki-programmer should only need at most a few hours to create the necessary context -- correct interpretation and display of this kind of SVG-file." Am I wrong? (with "this kind of SVG-file", I meant the raw SVG-code followed by further text intended to be its description which make up the whole SVG-page) For technical implementation, one should start with the article/text-context as new SVG-namespace/context. Then make this bisection into SVG-code and remainder text of any created/changed SVG-page and make further checking/operations of/for the SVG-code like on/of uploaded SVG-files currently (and checking of the reaminder text section, like currently occurs on text-pages ;) ). Later when displaying a SVG-page this bisection works like displaying a current SVG-file, except that the description is already (the 2nd) part of the SVG-page. When calling internally for displaying the SVG-content, via [[SVG:myPic.svg|thumb|...]] this 2nd part is completely ignored and only the 1st part (SVG-code) is displayed as a (transformed) bitmap image. IMHO Most difficult seems to me to efficiently make this bisection recognization. But this is like parsing an SVG-file until its final </svg>-token and memorize this position. Storing and maintaining is trivial (a further length parameter to the SVG-page does the job). Thanks anyway for your thoughts and support, Achim

Achim Flammenkamp

7:55 a.m.

New subject: Maintaining (and thus editing) SVGs' text like wiki text-pages

What is expected to do next from me regarding this topic? [ I think it would have been a bit more helpful for all other interested developpers, if we haven't communicated personaly, but publicly, Merlin. ] Achim

4339

days inactive

4347

days old

wikitech-l@lists.wikimedia.org

Manage subscription

27 comments

11 participants

tags (0)

participants (11)

Achim Flammenkamp
Chris Steipp
Denny Vrandečić
Derric Atzrott
Jon Robson
Marcin Cieslak
Mark A. Hershberger
Max Semenik
MZMcBride
Nikola Smolenski
Sumana Harihareswara