Last modified: 2014-11-17 11:45:01 UTC
WikiEditor toolbar icons are low-resolution raster images, and appear visibly pixelated on a high-resolution display such as iPad third-gen or when zoomed in. Recommend using SVG images with PNG fallbacks. Note that currently many of these images are sprited and may need to be re-separated and re-drawn.
Created attachment 10281 [details] screenshot of editing on en.wikipedia.org on iPad 3
Change 97454 had a related patch set uploaded by M4tx: Add SVG versions of toolbar icons https://gerrit.wikimedia.org/r/97454
Created attachment 13895 [details] Screenshot of WikiEditor after the patch
Pau / Brandon: Could you review the patch (8 lines of CSS and a bunch of new SVG files), or do you have an idea who could?
Done and commented.
Created attachment 15051 [details] screenshot safari 7 I notice a few small problems the shadow of the chars seems a tad excessive, the red traffic sign around the W is a bit shifted for me (likely Mac Safari specific issues).
DJ, looks "good enough for now" I'd like for us to clean this up, and switch to a smaller set of icons that use the new wikifont icons when we can https://www.mediawiki.org/wiki/Design/Wikicons
Change 97454 merged by jenkins-bot: Add SVG versions of toolbar icons https://gerrit.wikimedia.org/r/97454
Comment on https://gerrit.wikimedia.org/r/97454: FIXME: The "B" button looks broken. > This change changed the B button to have 3D depth > whereas all the others remain flat (the book icon > also some depth to it, but not beyond a simple surface, > which looks fine). The depth is sufficiently odd that > I suspect this was not done on purpose. > > Screenshot: http://i.imgur.com/mBZm28W.png > (bottom row shows the new SVG versions) > > It looks like the outline that is making it look > 3D is actually just the regular outline, and the > black filling for some reason only covers half > of the width.
I also left a request for assistence in the commons graphics lab. https://commons.wikimedia.org/wiki/Commons:Graphics_village_pump#SVG_improvements_for_MediaWiki_toolbar
Re: request for assistance in the Commons Graphics village pump: It might help if the SVG code in question were available somewhere as an ordinary SVG file, and not only as embedded in some kind of generalized source code patch management database system that not everybody may feel like trying to come to terms with...
Good point, i'll upload them on commons.wm.org
Anything that is already part of wikifont doens't need to be redrawn https://github.com/munmay/WikiFont/blob/master/Screenshot-current.png
I thought there is an Wikimedia icon initiative? I'm interesting to do this like simple in the Tango/GNOME style!? [[File:Gnome-format-text-bold.svg]]
Eh, this is just about the old style icons, we are not talking about replacing them...
@DJ, the proposed SVG icons were significantly different (bevels, embossing, gradients) which definitely diverge from what we had, I was just saying, if we're diverging from what we had, I'd like to diverge in the right direction, not in the direction of greater ornamentation.
Created attachment 15431 [details] Zip of icon files
Created attachment 15465 [details] Letter B fixed Font to pfad converted , remove all transform attributes.
Created attachment 15466 [details] Screenshot - vector-bar completely disordered It appears also if I logged out. Win 7 Chrome 34. Firefox is normal.
Comment on attachment 15465 [details] Letter B fixed font type to path
Comment on attachment 15466 [details] Screenshot - vector-bar completely disordered Now everything is ok again, I've nothing changed.
Created attachment 15497 [details] button-sprite.svg fixed I've optimized the button-sprite and also converted all text to path. Check it out.
Comment on attachment 15497 [details] button-sprite.svg fixed All GaussianBlur filter are still present although this is very unusual for small icons. I would make a version without GaussianBlur. (File size before 152.841 Bytes after my optimation = 34.961, SVGZ compression = 10.918 Bytes)
Thank you PRO, i'll get on this in the next week.
@PRO, btw we don't need it to be SVGZ compressed, because that already happens on the fly. I concur that the gaussian blur is somewhat unusual, and I'm not a big fan of it myself.
Is anyone working on merging PRO's corrected button sprite into code? I'm also seeing what Krinkle reported before (positioning issues of the shadow of all letters) which is fixed with attachment 15497 [details]. This should be a high priority since it looks pretty broken right now!
@PRO, i'm also seeing what you see in your: "Screenshot - vector-bar completely disordered" I'm mostly seeing it if I zoom the page out a bit. Probably has to do with scaling and rounding... ?
@Derk-Jan Hartman, yes me too, it is the browser zoom level, but only in Chrome and only sporadically. (If I reset the zoom level, the effect is gone immediately.) I can't say it is an SVG bug, instead of a Chrome bug with CSS sprite sheets (maybe only with SVG).
But for sure, I would upload tomorrow another fixed version, with all group transform attributes removed (W3C valid uncompressed and xml well formed).
Change 151203 had a related patch set uploaded by Paladox: Update WikiEditor https://gerrit.wikimedia.org/r/151203
Change 151611 had a related patch set uploaded by Paladox: WikiEditor: Fix issue with SVG https://gerrit.wikimedia.org/r/151611
Change 151203 abandoned by Paladox: Update WikiEditor Reason: Ok. Please see Ic0c261f66ee882efeb07ab77ee2a3a5533093c4f for the fix for svg images. and I2a223e202aa488f0e83e663e490ee009da686687 for converting .css to .less. https://gerrit.wikimedia.org/r/151203
Comment on attachment 15497 [details] button-sprite.svg fixed Hi there is a problem with this image I uploaded to gerrit and this is what user krinkle said. format-B is now missing a doctype. And the sprite completely changed. It should probably only have the bold part replaced. I mean xml header, not doctype.
Hi I have fixed the problem I also removed the shadow from the rest of the svg icons.
This bug seems to be tracking at least two or maybe three completely distinct issues, one of which has just been reported as bug 70679. Can anybody summarize what is going on and what's up with all the various patches and attachments? Derk, you're marked as assignee – are you still working on it?
(In reply to Bartosz Dziewoński from comment #36) > > Can anybody summarize what is going on and what's up with all the various > patches and attachments? . . . > I'll second that! When it comes to such matters involving images/icons on a toolbar, it seems [to me] the best way to whittle down the issues is to actually have them render in semi-real world instances and have folks report back their findings. Can't we merge .... https://gerrit.wikimedia.org/r/151611 and https://gerrit.wikimedia.org/r/151616 ... so that they at least come up live & working on test2.wikipedia.org in the immediate near future (i.e. today)? That should get us a decent pool of user responses before next week's scheduled core update to see if those patches resolve anything (or not) bug-wise and still give us enough of a buffer to further refine or revert as needed before that scheduled update rolls-out as well. The way things stand now, with half a dozen patch sets awaiting attention or implementation for weeks if not months already, we sure don't seem to be resolving much.
Hi I have already done a patch that does that. https://gerrit.wikimedia.org/r/#/c/151203/ Someone commit and said to split them into two patches.
Change 151203 restored by Paladox: Update WikiEditor https://gerrit.wikimedia.org/r/151203
Change 151203 had a related patch set uploaded by Paladox: WikiEditor: Convert .css to .less and also fixes svg issues. https://gerrit.wikimedia.org/r/151203
Hi I have now re opended the patch but it says Merge Failed. This change was unable to be automatically merged with the current state of the repository. Please rebase your change and upload a new patchset.
Change 160421 had a related patch set uploaded by Paladox: WikiEditor: Convert .css to .less and also fixes svg issues. https://gerrit.wikimedia.org/r/160421
Change 160421 abandoned by Paladox: WikiEditor: Convert .css to .less and also fixes svg issues. https://gerrit.wikimedia.org/r/160421
(In reply to paladox2015 from comment #42) > Merge Failed. > This change was unable to be automatically merged with the current state of > the repository. Please rebase your change and upload a new patchset. So please fix that? :)
Hi I have fixed it.
Hi I have now fix it.
I can't seem to get a clear, concise and accurate description from the patch submitters on these problems. Problems also remain in the latest versions of the submitted patches with strange offset problems in the sprite when the user zooms in or out. Since there are clearly problems in the original patch that was converting the toolbar resources to SVG, and since it seems that the patch submitters cannot get them corrected, I think that there is only one solution left. Revert the original SVG patch and wait till someone with SVG skills AND gerrit experience pays attention to this problem.
Hi i have got it right i have added the images that were here to the patch and also added a note on who created the image i also followed fomafix instructions and so the patch should be correct now.
Change 168821 had a related patch set uploaded by TheDJ: Revert "Add SVG versions of toolbar icons" https://gerrit.wikimedia.org/r/168821
(In reply to paladox2015 from comment #50) > Hi i have got it right i have added the images that were here to the patch > and also added a note on who created the image i also followed fomafix > instructions and so the patch should be correct now. https://gerrit.wikimedia.org/r/151203 ... followed by ... https://gerrit.wikimedia.org/r/151611 ... followed by ... https://gerrit.wikimedia.org/r/151616 ... is the way I thought this was all going to play out too.
Paladox, I'm not sure how I need to explain this to you and it hope it doesn't come across as rude, because it's not intended to be that way, but this whole stuff is simply not reviewable right now. If I go trough a patchset, read the commit message and the diff, test it in my browsers and NOT have all my questions answered. It cannot be merged. Things I should not have to do are: 1: Go trough 50 patchset rebases 2: Go trough 15 comments interspersed with these rebases, for finding answers that should be in the commit message, if they affect the review. 3: Pick and choose between 3 patchsets, for one change. This Bug ticket is about converting the Original PNGs to SVG. 1: M4tx did some nice work 2: This work was not pixel perfect with the original PNGs, but that was fine 3: I approved the SVG change on that basis 4: It turned out that there were problems with the SVGs in production. This should have been cause for reverting the change. 5: Instead of reverting I gave people a chance to fix it, Pro, you etc. 6: You currently are the one making those proposals for changes. 7: You can't answer the questions in a way that gives enough people confidence to approve the changes. (either by lack of experience, by lack of your mastery of the language, of not actually being able to prove it all works as expected etc.) 8: This means the patches cannot be merged, and that means that it's about time to bite the bullet, and I need to admit that I should have reversed the original commit back then when it became clear there were some problems with the original change to SVG.
Ok I have tested all the patches on my site. here is link to show how it is working. http://en.random-wikisaur.tk
"is the way I thought this was all going to play out too." There are no dependencies on the tickets, there are no comments on the commit message that indicate this. That first link already mixes three issues in a way that I'm not confident anymore that something unexpected is mixed into it as well. Separation of concerns (in bugzilla tickets, commit messages etc), be explicit about what depends on what, proof that stuff works (as intended) and you will convince a core reviewer to merge the code. That has not happened so far.
I have created 3 commits one has all of it in it and 2nd patch has .less in it and third patch has the fixes for svg.
Created attachment 16901 [details] Alignment trouble Well I should be able to see that it works in all situation, not just in yours, and as this screenshot of a zoomed Chrome shows, it simply still doesn't work... unfortunately.
(In reply to Derk-Jan Hartman from comment #55) > "is the way I thought this was all going to play out too." There are no > dependencies on the tickets, there are no comments on the commit message > that indicate this. > Granted - and you are absolutely correct to take that position imo as well. I merely had the small benefit of following this exercise 20+ revisions ago is all. Don't read into it any further than that. (In reply to Derk-Jan Hartman from comment #53) > 4: It turned out that there were problems with the SVGs in production. This > should have been cause for reverting the change. Bingo. Regression seems to be a dirty word around here however.
That site also includes .less.
This one only includes the fixes for svg http://simple-random-wikisaur.tk/index.php?title=Main_Page&action=edit
Okay, this is getting ridiculous. M4tx made a commit that added SVG files (a low priority enhancement). The commit accidentally mutilated the "B" icon (visible regression) and was merged by TheDJ. See https://gerrit.wikimedia.org/r/#/c/97454/ http://i.imgur.com/mBZm28W.png I don't know what everyone is doing, but please just fix the icon. All this other stuff is unrelated to this bug. If there's no simple commit that fixes the icon soon I'll recommend reverting the SVGs for the time being and re-submitting that change as a draft blocked on restoring the B icon.
Hi I have one of the images that were fixed by a user here and fixed the other ones to. the patch is at https://gerrit.wikimedia.org/r/#/c/151611/
Change 168821 merged by jenkins-bot: Revert "Add SVG versions of toolbar icons" https://gerrit.wikimedia.org/r/168821
part of me is still wondering why we aren't using the icons that are in use in VisualEditor currently, any rational?
Using the OOUI icons means using OOUI. Porting the wikitext editor to OOUI is a big piece of work.
No, i just mean the same SVG assets. for bold, italic, image, link, etc. Not the code behind an OOUI control
(In reply to Jared Zimmerman (WMF) from comment #66) > No, i just mean the same SVG assets. for bold, italic, image, link, etc. Not > the code behind an OOUI control That's fundamentally incompatible with how MediaWiki is built. Reaching in to the code base to pull out assets will immediately fail basic code review.
Based on talking to James and Trevor, we can provide the icons that will improve consistency dramatically, we're targeting end of day tomorrow Nov 5 to have all the assets ready to integrate. Thanks for a moment of patience.
Change 151611 had a related patch set uploaded by Paladox: WikiEditor: Re add SVG https://gerrit.wikimedia.org/r/151611
