Introducing OpenType Variable Fonts
medium.com
medium.com
Color me very, very impressed.
Will it work with font-weight and font-stretch?
e.g.: Will this use the font variations instead of letting the browser do the interpolation?
font-weight: 100;
font-stretch: condensed;> Together with other browser makers, we’re already working on a proposal to extend CSS fonts with variations. Once everyone agrees on the format, we’ll support it in Google Chrome.
[1] http://opensource.googleblog.com/2016/09/introducing-opentyp...
This is more akin to the old Adobe MultiMaster fonts, where the user installed one font that could then be dynamically tuned in various ways - weight, descenders, etc.
But it seems that it ended up being used for a much more narrow purpose in the actual TeX stack that people use.
I hate the conservative, everything is old and has been done view; however, it is easy to look at some of the original large projects that people chose to ignore and be amazed at what they were already doing. It isn't in XML, but METAPOST/METAFONT are two really really cool projects.
yeah, well, same true for Multiple Master fonts. It ended up that Adobe gave the font metrics to the TeX[0] community. The complexity of the fonts was obviously too much for the "graphic designer".
My first year of college was the first year my school shifted most departments' document recommendations to MS Word from TeX, so I never really used it for authoring. Spending a day playing trying to make something useful with it has been on my someday-list for... a depressingly long time.
The book Computer Modern has a fun section at the end where it goes through several poems showing different parameters for the font for each section.
Is there anywhere we can play with creating variable fonts? Guessing it'll be awhile before it hits FontForge...
I used to like fontforge, it's a fine application, but the move to ufo has made it easier to apply older svg-based tools to editing splines and saving out as ufos. here's a free application, it looks promising! https://github.com/trufont/trufont .
finally it's worth looking at https://github.com/LettError/MutatorMath which has lots of the tools for interpolating masters. There are actually loads more resources and, if you are short on time or attention, my guess is that the tightest workflow will be coming to Robofont (which hovered around 500 euro for a while).
Still, it's all very accessible to you even outside of fontforge and all the libraries for modifying ufo-style paths are freely available. take a look, it seems very fractured, but i think it's a nice distributed workflow all things considered given the final output.
In the obvious way that when A and B are similar enough (as font variations are) a delta between A and B is substantially smaller than bundling A AND B.
>A delta does not intrinsically require less information than an absolute value.
In the abstract, no, but in 99% of the cases where it's used in computing, e.g. it software updates, rsync, etc, it does, and that's exactly why it's used.
Why would font variations, which intuitively are more alike than different, would have diffs larger than the "absolute value"?
I thought this was the definitive reason why git tracks full files, and not diffs. Turns out, that is just a better way to do things in most cases.
In graphics, delta might be better, since the glyph is offset anyway on the canvas, so when drawing, the renderer can use the diff information as-is when the last point is known to reduce the number of operations to a simple addition with smaller length numbers as opposed to absolute positioning.
It might also keep the extracted memory footprint low since you might be able to get away with less bits per encoded change in a typed array data structure.
Still wonder if Mapbox ever did some size and speed benchmarking of general purpose compressed raw signed integers vs. their zig-zag and delta encoded vector tile geometries. https://github.com/mapbox/vector-tile-spec/issues/35#issue-1...
That description is already a (excellent) compression: A bitmap for the 1000px x 1000px "O" for your poster would be 1MB.
Whereas before fonts only had rules to change with size changes, this standard defines weight as another dimension.
It's quite similar to how jpeg, mpeg, and mp3 are better compression methods for their respective domains than WinZip could ever be by incorporating knowledge about data being encoded.
Additionally, since building the fonts from the source isn't time consuming anymore, you could just focus on compressing the representations that say "circle with center blah". (Which, again, takes this back into METAFONT territory. Not a bad place to be, just bemusing.)
Are they similar? I would expect that between a bold glyph and a normal weight glyph, exactly zero points would be the same.
>In the abstract, no, but in 99% of the cases where it's used in computing, e.g. it software updates, rsync, etc, it does, and that's exactly why it's used.
You're comparing vector deltas (which are presumably floating point) to deltas between binaries, where you can take a line-by-line or byte-by-byte diff. This is apples and oranges.