Page MenuHomePhabricator

Sameboat
User

Projects

User does not belong to any projects.

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Saturday

  • Clear sailing ahead.

User Details

User Since
Jul 19 2015, 11:19 AM (229 w, 3 d)
Availability
Available
LDAP User
Unknown
MediaWiki User
Sameboat [ Global Accounts ]

Recent Activity

Jun 1 2016

Sameboat added a comment to T134410: Evaluate SVG rendering compatibility in browsers.

Comparison image for illustrating the text handling of different SVG libraries:
https://commons.wikimedia.org/wiki/File:Comparison_raw_text_converted_path.svg

Jun 1 2016, 4:47 AM · Commons, Multimedia, MediaWiki-File-management, Wikimedia-SVG-rendering

May 31 2016

Sameboat added a comment to T134410: Evaluate SVG rendering compatibility in browsers.

@brion Packed text passage could be solved in SVG 2.0 with the new text properties "inline-size" https://www.w3.org/TR/SVG2/text.html#InlineSize and "shape-inside" https://www.w3.org/TR/SVG2/text.html#TextShapeInside, if SVG 2 is implemented into librsvg but I am very pessimistic with that. Anyway it's true that localization usually requires the active vector artist (usually the original author) to rework the image for minimal collision of elements after the image is translated by another contributor with little knowledge of SVG.

May 31 2016, 4:14 PM · Commons, Multimedia, MediaWiki-File-management, Wikimedia-SVG-rendering
Sameboat added a comment to T134410: Evaluate SVG rendering compatibility in browsers.

@brion High quality SVG images by User:Kelvinsong made from scratch. He usually duplicates all texts to the higher layer and set it to opacity=0 then path-izes the visible text. I respect him, but I can sincerely say there is absolutely no reason to do that except that Wikimedia and many readers do not have his type of preference, Neue Frutiger, installed which isn't legally free to my knowledge.

May 31 2016, 3:22 PM · Commons, Multimedia, MediaWiki-File-management, Wikimedia-SVG-rendering
Sameboat added a comment to T134410: Evaluate SVG rendering compatibility in browsers.

The problem I can foresee is that this would further discourage our vector artists from NOT converting text to path because you can't require our readers to have the same typefaces installed on their OS as those specified in the SVG file. Even if they do have the required typefaces, different SVG renderers have different interpretations of kerning (glyph horizontal spacing). I want consistency of text appearance while still maintaining text to be selectable and searchable, and funny though this is what PDF format is capable of while keeping the general file size smaller than the same SVG image which has all its text converted to path, because most vector editors like Inkscape and Adobe Illustrator do not share path object of same glyph of same font during conversion. I use the free RSVG-Convert tool (http://opensourcepack.blogspot.hk/2012/06/rsvg-convert-svg-image-conversion-tool.html) to create PDF version of my SVG. The resultant PDF while is not completely but reasonably consistent to my SVG source.

May 31 2016, 2:21 PM · Commons, Multimedia, MediaWiki-File-management, Wikimedia-SVG-rendering
Sameboat added a comment to T40010: Re-evaluate librsvg as SVG renderer on Wikimedia wikis.

@Aklapper No. As a complete outsider, the only things I actually know about are that Mozilla's staffers are involved in the SVG 2.0 draft and the fact that Firefox has implemented the SVG 2.0 only paint-order property (can be enabled in the stable release, not just nightly). Nonetheless browsers render SVG in real-time, rasterization is a different story.

May 31 2016, 9:57 AM · TechCom-RFC, MediaWiki-File-management, Commons, Multimedia, Wikimedia-SVG-rendering

May 30 2016

Sameboat added a comment to T40010: Re-evaluate librsvg as SVG renderer on Wikimedia wikis.

@Isarra Of course I understand. I just want to bump this topic up once again. Mozilla keeps updating its SVG renderer and is even preparing for 2.0. I just want to show my great concern that SVG in Wikimedia is dragging behind due to the inactive/passive update of RSVG. If the Foundation has good funding to use then SVG is one thing deserves the investment. My expectation is very simple: Fix the major bugs/glitches and prep for 2.0.

May 30 2016, 11:31 PM · TechCom-RFC, MediaWiki-File-management, Commons, Multimedia, Wikimedia-SVG-rendering
Sameboat added a comment to T106263: Add larger sizes to $wgImageLimits on commons.

@Gilles I wonder if the software is able to detect if the specific size is actually being used in any wiki page instead of being called merely "for personal use" so the system will remove the thumbnail of the latter case to free up some space.

May 30 2016, 7:59 AM · Performance Issue, Wikimedia-Site-requests, Commons

May 29 2016

Sameboat added a comment to T40010: Re-evaluate librsvg as SVG renderer on Wikimedia wikis.

The bad support of text of RSVG is having a very bad influence to our vector graphic contributors. Font issue aside which has very little to do with RSVG, many SVG contributors prefer to convert text to path due to lack of supports of textPath, writing-mode and really poor scaling and rotating result of text. Even if you scale the SVG image by integral multiplier (e.g. 2, 4, 8), text kerning still looks misinterpreted. If you rotate the text, it just looks bumpy on a rocky road.

May 29 2016, 11:10 PM · TechCom-RFC, MediaWiki-File-management, Commons, Multimedia, Wikimedia-SVG-rendering

Jul 19 2015

Sameboat added a comment to T106263: Add larger sizes to $wgImageLimits on commons.

There should already be a link to the nominal size if its sane.

There is never a PNG render link of the nominal size unless the SVG native size is coincidentally the same as one of the presets.

Jul 19 2015, 11:53 AM · Performance Issue, Wikimedia-Site-requests, Commons
Sameboat added a comment to T106263: Add larger sizes to $wgImageLimits on commons.

Fixed width isn't helpful. It is better to provide the PNG link of the same native/nominal size as the source SVG. Also there should be a width entry box for reader to generate the link of specific size on demand instead of providing bunch of presets.

Jul 19 2015, 11:24 AM · Performance Issue, Wikimedia-Site-requests, Commons