Comments for Tavmjong Bah's Blog

Comment on SVG Working Group Editor’s Meeting Report — London — 2016 by Tamás Pétery

Tamás Pétery — Wed, 11 May 2016 21:05:27 +0000

Oh and sorry for the messed up links. :C

Comment on SVG Working Group Editor’s Meeting Report — London — 2016 by Tamás Pétery

Tamás Pétery — Wed, 11 May 2016 21:03:47 +0000

Hello there, Sorry for commenting under the wrong post but saw that you used a (on heat maps) for achieving the result. Haven't tried that myself yet. I for one would like to suggest gradient mapping to the svg working group. It is possible to some extent to do the same by various flood fills, adjusting component transfers and mad chaining in the filter editor, like in . My guess is the whole thing could be hard coded into a single filter, which could then take existing gradient definitions as an input. Then at each step of the mapped gradient a flood fill would be added with fading described by component transfers, similarly to the mentioned filter. With gradient mapping gradient meshes could be tweaked easily, not just node by node. All the best! Lazur

Comment on SVG Working Group Meeting Report — Sydney — 2016 by Emanuele Sabetta

Emanuele Sabetta — Sun, 06 Mar 2016 20:00:31 +0000

The SVG format should not be too much dependent on web standards like CSS.
As you may already know, the SVG format is now used widely in mobile applications both on Android and on iOS. Due to the device independent quality of SVG, and to the unnumerable varieties of screen dpi, ratios and resolutions in mobile devices, developers are now sistematically dropping bitmaps assets and replacing them with SVG assets.
It is now clear that SVG is going to become the de facto standard for vector graphics interchange in a variety of fields: mobile apps UI (are all migrating to vector graphics now, dropping PNG for vector drawables), videogames (2D games on both portable and home consoles are almost all made with vector graphics this days and often originally created in the SVG format and converted to an internal format), cartoons and youtube animations ( a lot of video applications for animations editing used by popular youtube channels import SVG now for both backgrounds and animation frames), professional cartoon animations studios (there are many professional software art tools for creating animations but they have an hard time when it cames to exchange data and files. SVG is now increasingly used as an universal export format for vector graphics and a bridge between all those tools). SVG should not be limited to the web and the browser. To make SVG an independent and self sufficient vector file format it should not rely on external javascript libraries or applications specifications.
For example it should provide it’s own animation markup language, and this is what it already did with the absolutely excellent SMIL (the best timesynched animation format ever, able to be perfectly reproduced everywhere without loosing neither animation and audio syncronization).
Why on earth is SMIL going to be dropped? This is the most stupid choice ever for the WG. Especially now that, with tools like Adobe Animate CC and plugins like Flash2svg ( https://github.com/TomByrne/Flash2Svg ) you can export almost all animations + sound as a single SVG file, like this one amazing cartoon episode:
http://www.tbyrne.org/portfolio/smil/LoveDota.svg
SMIL would be paramount in the future for mobile app coponents animations. On iOS and Android, buttons and UI components are already made with animated SVG.
Even crossplatform frameworks like Xamarin are now using SVG. Read this article for example:

http://blog.twintechs.com/explorations-in-cross-platform-assets-xamarin-forms

As you can see they cannot use the CSS border size attribute to scale the svg like on the web. SVG should provide 9-slice scaling in the format itself, not pretending to use CSS like a browser was present.

There is a world outside the browser that uses SVG. Please tell the WG to consider it when working on the next specs. Thank you!

Comment on SVG Working Group Meeting Report — Sydney — 2016 by Andrew Ulrich

Andrew Ulrich — Thu, 25 Feb 2016 02:04:20 +0000

Thanks for attending and for the report! I’m glad to know about the deprecation of presentation attributes, and am looking forward to seeing the different line join types in action.

Comment on SVG Working Group Meeting Report — Sydney — 2016 by Ross Reedstrom

Ross Reedstrom — Thu, 18 Feb 2016 16:12:46 +0000

Just wanted to say thank you, both for your work in Inkscape, and taking on the problem of making standards both sane and useful. If you’ve ever wondered if anyone reads theses blog posts full of committee meeting discussion, I’m here to say at least one person does!

On technical matters, CSS everywhere seems to be all the rage. We’ve recently been writing some code that uses CSS3 to specify book-level “styling” changes (using move-to, copy-to and pending ), that historically I’d have considered the domain of XSLT. Seems the new trend.

Comment on SVG Mesh Gradients, Heat Maps, and a Plea by Petr Certik

Petr Certik — Tue, 26 Jan 2016 23:33:56 +0000

Thanks for all your great work!

Comment on Font Features Land in Inkscape Trunk by Tavmjong Bah

Tavmjong Bah — Thu, 25 Jun 2015 19:41:03 +0000

I’ve checked in code that greys out unsupported features. This code may not be perfect as there may be different versions of the same table for different scripts and languages. A feature is grayed out only if the corresponding table doesn’t appear anywhere in the font.

Even if a table is present it may not do what you want. For example the ‘frac’ table may only support converting 1/4, 1/2, and 3/4 to ¼, ½, and ¾ respectively (as these three values have actual Unicode points) and not the generic conversion of arbitrary fractions like 7/8.

It would be nice to know which glyphs have stylistic alternatives but this information is buried deep inside the OpenType tables (often spread out among many tables) and there appears to be no way to access this information through Pango.

Comment on Font Features Land in Inkscape Trunk by Mark V

Mark V — Thu, 25 Jun 2015 06:22:34 +0000

Thanks for the replies. Looks like I should get my feet wet with standard ligatures (which are on by default in stable Inkscape), then branch out to fancier features with bleeding-edge Inkscape/Pango when I run into a lettering problem that ligatures can’t handle.

From poking around at the Linux Biolinum TTFs in FontForge, the relevant bits appear to be in Element->Font Info->Lookups->GSUB->”liga”->Edit Data

Comment on Font Features Land in Inkscape Trunk by AnonOps

AnonOps — Wed, 24 Jun 2015 09:29:08 +0000

You don’t need to create a UFO. fontTools has the TTX xml format which represents a binary font, in human-readable form.

Secondly, FontForge fully supports OpenType features.

Comment on Font Features Land in Inkscape Trunk by Tavmjong Bah

Tavmjong Bah — Wed, 24 Jun 2015 07:28:36 +0000

This might be a good place to start: http://ilovetypography.com/OpenType/opentype-features.html