No named instances, no STAT axis value tables about decovar

[dberlow]

I think that's a yes, DJR, it's okay to wait.

…

On Mon, Jun 26, 2017 at 1:43 PM, Peter Constable ***@***.***> wrote: Rob McKaughan has drafted fonttools changes to add support for the STAT extension adding a format 4 axis value table, but he's waiting until OT1.8.2 has been published before submitting a PR. (Btw, now that I'm back from vacation, publishing 1.8.2 is front-burner for me; Rob's on vacation for the next couple of weeks.) In the meantime, we crafted a rev of Decovar with a STAT table using format 4 AVTs so that we could validate our DWrite implementation. I'll be happy to follow up with you folk once I get caught up. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB3ajlH_NzR-C3b61jasl-wQUV9qDDpZks5sH-2tgaJpZM4L7nxt> .

[PeterConstable]

Rob McKaughan has drafted fonttools changes to add support for the STAT extension adding a format 4 axis value table, but he's waiting until OT1.8.2 has been published before submitting a PR. (Btw, now that I'm back from vacation, publishing 1.8.2 is front-burner for me; Rob's on vacation for the next couple of weeks.) In the meantime, we crafted a rev of Decovar with a STAT table using format 4 AVTs so that we could validate our DWrite implementation. I'll be happy to follow up with you folk once I get caught up.

[davelab6]

he's waiting until OT1.8.2 has been published before submitting a PR

That PR has been made and was merged yesterday, fonttools/fonttools#1015

[djrrb]

Thanks for your comments @PeterCon!

I just added 18 named instances to the designspace and rebuilt the font, so we can get an idea of what that would be like (9a03a0f).

I'm leaving this issue open, since the axis values are still missing from the STAT table. @PeterCon, is there a STAT table writer that you've released or would be willing to contribute? Up until now I've been writing them by hand, but with Decovar's complexity it is probably better to pursue an automated approach.

[PeterCon]

Interesting names! I’m assuming each of those represents some combination of values across all of the axes, not 18 names for points along just one axis? Assuming that’s the case… I don’t know of a STAT table generator that generates entries from other tables, and I’m not sure how that would work in this case. We haven’t considered such a tool, but have considered the possibility of tools that work in the opposite direction: starting with name ID 16 (preferred family) plus a STAT table and generating named instances plus name table entries for family and sub-family name IDs other than name ID 16. The approach you have to naming in this font reflects a different way of thinking of how names and axes relate than what all the platform implementers involved in developing the spec were thinking: that values along axes can be given names, and that the name for an instance at the intersection of some combination of axis values is a combination of the names for those axis values. E.g., “Condensed Bold” combining “Condensed” and “Bold”. So, if this approach to naming is something that will be common, we may need to give some thought to how best to support it. The main intent of the STAT table is to provide a bridge to older software that doesn’t allow for a font family being comprised on arbitrary values on an arbitrary set of axes, but rather is assuming some limited set of axes and perhaps a limited number of values on those axes — the most extreme being software that assumes that a family can be comprised of at most Regular, Bold, Italic and Bold Italic members. (Let’s call that the RBIZ family model.) So, for example, consider a font like “Kepler Light Condensed Display”: In the RBIZ family model, light weight, condensed width and display optical size all fall outside of what is supported within a family. In comparison, in the weight/slant/style model used by CSS, light weight and condensed width are supported within that model, while optical size is not. So, if the STAT table has entries associating “Light” with a particular weight value, “Condensed” with a particular width value, and “Display” with a particular range of sizes, then platforms can re-interpret the name to accommodate different family models. Preferred / typographic family model: Family = Kepler Sub-family = Light Condensed Display WSS family model: Family = Kepler Display Sub-family = Light Condensed RBIZ family model: Family = Kepler Light Condensed Display Sub-family = Regular Obviously, these machinations aren’t desirable, but they are unfortunately necessary given the large installed base of software with these family-model limitations. So, how might “Decovar Checkered Reverse” be handled in relation to these different family models? There’s really only one option: Preferred / typographic family model: Family = Decovar Sub-family = Checkered Reverse WSS family model: Family = Decovar Checkered Reverse Sub-family = Regular RBIZ family model: Family = Decovar Checkered Reverse Sub-family = Regular And STAT axis value tables wouldn’t really help since the sub-family name in this case is not comprised of a combination of tokens that represent values on independent axes. So, something for us and other platform implementers to think on. Thanks, btw, for adding the named instances. 😊 Peter

[davelab6]

The approach you have to naming in this font reflects a different way of thinking of how names and axes relate than what all the platform implementers involved in developing the spec were thinking ... if this approach to naming is something that will be common, we may need to give some thought to how best to support it. ... So, something for us and other platform implementers to think on.

As I say in http://typedrawers.com/discussion/comment/25926/#Comment_25926 I would be very happy to contribute some thoughts to this :)

[djrrb]

Thank you for the further info on the STAT table and the thinking behind it! I'm also very glad to hear that this project is providing some food for thought.

I’m assuming each of those represents some combination of values across all of the axes, not 18 names for points along just one axis?

Yes, that's correct. Most of these named instances are located at the extreme of a single axis, but a handful show different interactions between axes at various values.

In defining these instances, we were trying to come up with a set that would provide users of non-OTVar software with menu items that would be representative of, or at least hint at, the stylistic range of the font. And in future UI implementations, hopefully users could still find them valuable as starting points for exploring the various axes.

In this particular case, I'm not sure if there's a way to record points on individual axes and then list their intersections that would be as effective in doing that. I guess it's about finding a balance between offering enough options without overwhelming the user (especially in WWS/RBIZ situations where each instance would essentially act as its own family.)

Thanks again!

[PeterCon]

Dave: As John responded on that thread, you should talk to Behdad and Sascha on providing input from Google.

[petrvanblokland]

What we see already happening in the other Var-fonts families under development, is that the addition of custom-axes with a specific task and scope, related to groups or even single glyphs, and in combination to some axes while independent from other axes, will be more common rule than exception. The design challenge is to make clusters of axes of not more than 5-6 to prevent exponential large interaction. This amount still can be handled mentally and in tools. These groups should be designed in such a way that they are truly independent. We are development the concept of how the design process of design spaces should look like. What is best practice there.

…

On 14 Feb 2017, at 17:55, Peter Constable ***@***.***> wrote: Dave: As John responded on that thread, you should talk to Behdad and Sascha on providing input from Google. From: Dave Crossland ***@***.*** Sent: Monday, February 13, 2017 11:14 AM To: TypeNetwork/fb-Decovar ***@***.***> Cc: Peter Constable ***@***.***>; Mention ***@***.***> Subject: Re: [TypeNetwork/fb-Decovar] No named instances, no STAT axis value tables (#3) The approach you have to naming in this font reflects a different way of thinking of how names and axes relate than what all the platform implementers involved in developing the spec were thinking ... if this approach to naming is something that will be common, we may need to give some thought to how best to support it. ... So, something for us and other platform implementers to think on. As I say in http://typedrawers.com/discussion/comment/25926/#Comment_25926 I would be very happy to contribute some thoughts to this :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#3 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AMMjFsaY396yyUPJO2kL0rXnRIwr21JGks5rcKtfgaJpZM4L7nxt>. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXBwU4y6r2nZI-0eN_F2IYbZju90nxjks5rcdyXgaJpZM4L7nxt>.

----------------------------------------------- Petr van Blokland | twitter+skype @petrvanblokland Intentionally not on FaceBook. [email protected] | www.petr.com mobile [phone] | buro [phone] ----------------------------------------------- Rietveld 56 2611 LM Delft The Netherlands ----------------------------------------------- Claudia Mens | [email protected] mobile [phone] | buro [phone] -----------------------------------------------

[davelab6]

Dave: As John responded on that thread, you should talk to Behdad and Sascha on providing input from Google.

I've pinged them, of course, but it is impossible for me to provide input into conversations I'm not privvy to; and there is the historical record, and the people who are not such industry insiders as myself (such as those in India) who will also benefit from following the conversations...

[PeterCon]

I took another look at the details of your named instances. Here’s what I see in Decovar’s ‘fvar’ table: [Deleting the details as they did not get interpreted within GitHub in a coherent way.] There are several cases of a name corresponding to a non-default value on some single axis, with all other axis values being defaults. So, perhaps such a name might be used to refer to that value on that axis, regardless of what values are set on other axes. I notice that “Flared Open” has axis 3 (“sklA”) = 1000 plus axis 7 (“trmB”) = 1000, with all other axes set to default values. And I also note that axis 3 = 1000 (with other axes at defaults) is named “Checkered”, and axis 7 = 1000 (with other axes at defaults) is “Flared”. So, that makes me wonder: would it be reasonable if “Flared Open” were renamed as “Checkered Flared”? Similarly, could “Fancy” be renamed “Checkered Flared Contrast”? Just curious.

[davelab6]

I'm sorry Peter to say, Github's inbound email processor has not been able to make sense of your reply via email, and the color (and I assume table) are lost. Please see the issue on the web at #3

[petrvanblokland]

{'sklA': (0.0, 0.0, 1000.0), 'wmx2': (0.0, 0.0, 1000.0), 'bldB': (0.0, 0.0, 1000.0), 'bldA': (0.0, 0.0, 1000.0), 'sklD': (0.0, 0.0, 1000.0), 'trmA': (0.0, 0.0, 1000.0), 'sklB': (0.0, 0.0, 1000.0), 'trmC': (0.0, 0.0, 1000.0), 'trmB': (0.0, 0.0, 1000.0), 'trmE': (0.0, 0.0, 1000.0), 'trmD': (0.0, 0.0, 1000.0), 'trmG': (0.0, 0.0, 1000.0), 'trmF': (0.0, 0.0, 1000.0), 'trmK': (0.0, 0.0, 1000.0), 'trmL': (0.0, 0.0, 1000.0)} Above is the fonttools-Python version of the current Decovar fvar: name, minValue, defaultValue, maxValue) {'srfr': (0.0, 35.0, 95.0), 'xhgt': (890.0, 1000.0, 1200.0), 'wdth': (120.0, 804.0, 804.0), 'prwg': (10.0, 176.0, 1000.0), 'opsz': (10.0, 14.0, 72.0), 'prwd': (84.0, 804.0, 804.0), 'cntr': (8.0, 100.0, 170.0), 'wght': (75.0, 176.0, 500.0), 'grad': (50.0, 176.0, 500.0)} Above is the fonttools-Python version of the current Amstelvar fvar: name, minValue, defaultValue, maxValue)

…

On Feb 14, 2017, at 10:30 PM, Peter Constable ***@***.***> wrote: I took another look at the details of your named instances. Here’s what I see in Decovar’s ‘fvar’ table: VariationAxis records axisTag minValue defaultValue maxValue flags nameID name string bldA 0.0 0.0 1000.0 0x0000 256 Blend A bldB 0.0 0.0 1000.0 0x0000 257 Blend B sklA 0.0 0.0 1000.0 0x0000 258 Skeleton A sklB 0.0 0.0 1000.0 0x0000 259 Skeleton B sklD 0.0 0.0 1000.0 0x0000 260 Skeleton D trmA 0.0 0.0 1000.0 0x0000 261 Terminal A trmB 0.0 0.0 1000.0 0x0000 262 Terminal B trmC 0.0 0.0 1000.0 0x0000 263 Terminal C trmD 0.0 0.0 1000.0 0x0000 264 Terminal D trmE 0.0 0.0 1000.0 0x0000 265 Terminal E trmF 0.0 0.0 1000.0 0x0000 266 Terminal F trmG 0.0 0.0 1000.0 0x0000 267 Terminal G trmK 0.0 0.0 1000.0 0x0000 268 Terminal K trmL 0.0 0.0 1000.0 0x0000 269 Terminal L wmx2 0.0 0.0 1000.0 0x0000 270 Weight Max 2 Instance records coordinates nameID name string flags axis 1 axis 2 axis 3 axis 4 axis 5 axis 6 axis 7 axis 8 axis 9 axis 10 axis 11 axis 12 axis 13 axis 14 axis 15 271 Regular 0x0000 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 272 Open 0x0000 1000.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 273 Worm 0x0000 0.0 1000.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 274 Checkered 0x0000 0.0 0.0 1000.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 275 Checkered Reverse 0x0000 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 1000.0 0.0 0.0 276 Striped 0x0000 0.0 0.0 0.0 0.0 500.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 277 Rounded 0x0000 0.0 0.0 0.0 0.0 0.0 1000.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 278 Flared 0x0000 0.0 0.0 0.0 0.0 0.0 0.0 1000.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 279 Flared Open 0x0000 0.0 0.0 1000.0 0.0 0.0 0.0 1000.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 280 Chelt 0x0000 0.0 0.0 0.0 0.0 0.0 0.0 0.0 1000.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 281 Sheared 0x0000 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 1000.0 0.0 0.0 0.0 0.0 0.0 0.0 282 Bifurcated 0x0000 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 1000.0 0.0 0.0 0.0 0.0 0.0 283 Inline 0x0000 0.0 0.0 500.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 500.0 0.0 0.0 0.0 0.0 284 Slab 0x0000 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 1000.0 0.0 0.0 0.0 285 Slab Inline 0x0000 0.0 0.0 500.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 500.0 1000.0 0.0 0.0 0.0 286 Contrast 0x0000 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 1000.0 287 Fancy 0x0000 0.0 0.0 1000.0 0.0 0.0 0.0 1000.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 1000.0 288 Mayhem 0x0000 0.0 1000.0 1000.0 1000.0 0.0 500.0 500.0 750.0 0.0 500.0 250.0 750.0 250.0 250.0 750.0 I’ve marked in red the cases of a name corresponding to a non-default value on some single axis, all other axis values being defaults. I notice that “Flared Open” has axis 3 (“sklA”) = 1000 plus axis 7 (“trmB”) = 1000, with all other axes set to default values. And I also note that axis 3 = 1000 (with other axes at defaults) is named “Checkered”, and axis 7 = 1000 (with other axes at defaults) is “Flared”. So, that makes me wonder: would it be reasonable if “Flared Open” were renamed as “Checkered Flared”? Similarly, could “Fancy” be renamed “Checkered Flared Contrast”? Just curious. Peter From: David Jonathan Ross ***@***.*** Sent: Monday, February 13, 2017 12:14 PM To: TypeNetwork/fb-Decovar ***@***.***> Cc: Peter Constable ***@***.***>; Mention ***@***.***> Subject: Re: [TypeNetwork/fb-Decovar] No named instances, no STAT axis value tables (#3) Thank you for the further info on the STAT table and the thinking behind it! I'm also very glad to hear that this project is providing some food for thought. I’m assuming each of those represents some combination of values across all of the axes, not 18 names for points along just one axis? Yes, that's correct. Most of these named instances are located at the extreme of a single axis, but a handful show different interactions between axes at various values. In defining these instances, we were trying to come up with a set that would provide users of non-OTVar software with menu items that would be representative of, or at least hint at, the stylistic range of the font. And in future UI implementations, hopefully users could still find them valuable as starting points for exploring the various axes. In this particular case, I'm not sure if there's a way to record points on individual axes and then list their intersections that would be as effective in doing that. I guess it's about finding a balance between offering enough options without overwhelming the user (especially in WWS/RBIZ situations where each instance would essentially act as its own family.) Thanks again! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#3 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AMMjFkrVCouAooZR7pPL-uY1gqB0ZPD2ks5rcLmhgaJpZM4L7nxt>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXBwSDt9Xm_8ypoiSEo1_09d2F9LYpMks5rch0NgaJpZM4L7nxt>.

----------------------------------------------- Petr van Blokland | twitter+skype @petrvanblokland Intentionally not on FaceBook. [email protected] | www.petr.com mobile [phone] | buro [phone] ----------------------------------------------- typetr.typenetwork.com ----------------------------------------------- Rietveld 56 2611 LM Delft The Netherlands ----------------------------------------------- Claudia Mens | [email protected] mobile [phone] | buro [phone] -----------------------------------------------

[PeterCon]

OK, I edited the comment in GitHub to make it readable.

[PeterCon]

More thinking about fonts like Decovar: When we designed the Font Variations extensions for OpenType 1.8, including the STAT table, we were primarily thinking about very-commonly-used axes of variations such as weight, etc., that were also prevalent in fonts like Skia and Adobe's Multiple Masters back in the 1990s. Such fonts may be intended for text or display usage scenarios. But a font like Decovar (or, say, Buffalo Gals) is different: it's suitable for display, but not text; and the kinds of parameters that can be manipulated are really geared towards display scenarios.

(Now, perhaps Amstelvar is a different story, but let's stick with Decovar for the moment.)

Certainly in the past, if you were developing type with this approach, you'd only be able to manipulate the parameters in design tools, and then you'd need to export specific instances that your customer wanted. So, in that case, the customer wasn't the one manipulating all the sliders. Today, with OT variable fonts, potentially they could be manipulating the sliders. I'm going to guess that many potential users might not want to manipulate sliders for Decovar: it's so many choices, and the user just wants a quick choice. But those probably wouldn't be the kind of user that a variable Decovar would be primarily marketed to. Rather, you'd be looking at the graphics professional working on a display setting in which they want to use their creative skills to tweak the options the font provides to fit the design goals for the project.

So, maybe the font with a limited set of named instances may be useful for the casual user, but I'm thinking that the real target for such a font is the more specialized designer who will want to access the full variation capabilities of the font. And that person will not want to use the font in legacy apps that can only support selecting certain named instances; rather, they'll want some newer apps that support selection of arbitrary axis values on arbitrary axes defined in variable fonts.

Just thinking out loud --- thoughts that may be relevant when thinking how a STAT table should be set up for a font like this.

[petrvanblokland]

It is tempting to think of the interface in an n-dimensional space as a set of sliders, one for each dimension. That is all we got so far, and it closely fits the linear model of MM and cubes. Interpolation instead of extrapolation from a middle. But when talking with students and colleagues I often make the comparison with directing people to interesting places in a country or building (in this case not even 2 or 3 dimensional, but many more). One would not direct people to these places by saying: "examine at every square meter that you can find" or "drive every road until you find something interesting". In a country or building, most places are not interesting, many are ok and few are really worth the effort of visiting. Some are useful for a certain function (beach or shop) and others are just uninteresting areas, which only exist to fill the space. In a real travel guide, someone already found the exciting stuff and made a catalog of locations. With recipes how to get there. Variation fonts are not different. Instead of offering a list of sliders, designers should offer directions for interesting areas in their design spaces. By pictures, examples, paths and coordinates. Locations can be hot-spots (define the coordinates as names and put them in the STAT for direct retrieval). Or direct users to areas from where they can explore themselves. There are areas that work as headlines, others as shadow background layers, others as text in small sizes, sub-areas that make such text lines fit in a given width. There are areas that work great in diapositive, or in animation or offer decorative additions to core glyphs shapers. The “big standard axes” (width, weight, size) can have virtually infinite axes rolled up inside that define large or subtle flavour differences (rounded corners, “victorian style”, roughness, etc.), once the big choices have been made. (If he/she found the restaurant-district in the city from a location on the map, it is still up to the traveller to find the right kind dish, depending on taste, preference and time of the day. Decovar is merely scratching the surface of what dishes are possible, while the city-architects are still designing the layout of the city. It is the task of the new-type-typedesigners to create hierarchy in the decision making and to visualize possible interfaces to the users. A large part of the selection is probably automated (depending on size of the type, amount of tracking, copy fitting, compensations of background color/contrast, ink-traps, axis-based glyph-substitution, rounded to grid and pixels) and by platform, resolution, usage and function. After that those parameters have filtered out the rest of the options, the UI needs to be designed to show users around. It is yet unknown what will work best there, for different types of situations and users. But it definitely is different from a list of sliders. Parameters that cannot be automated must at least offer hierarchical choices, must show preferences from the design of the type, must show how axes and their values are related and connected. Design spaces must be designed as independent areas, never offering more than 4-5 axis choices at the time, otherwise the amount of choices is too big for any user. That is not different from the hierarchy of choices designers make when creating a layout or any typographic design. Existing applications must implement this new kind of traveller support. This varies from the traditional font menu (fixed locations in STAT), to “interesting areas to explore” and “highlights given a certain function to perform”. If the applications themselves fail to offer that, others will be made as travel guides, as separate tools. Partly using the information that is already in the fonts (e.g. by registered axes and their min/max/default values) and partly by meta-information that is supplied by the designers in extra tables or from sources outside he fonts. In TypeNetwork we are sketching and testing possible UI-solutions that give better access to the n-dimensional landscape, than just offering a list of sliders. Petr

…

On 14 Feb 2017, at 23:19, Peter Constable ***@***.***> wrote: More thinking about fonts like Decovar: When we designed the Font Variations extensions for OpenType 1.8, including the STAT table, we were primarily thinking about very-commonly-used axes of variations such as weight, etc., that were also prevalent in fonts like Skia and Adobe's Multiple Masters back in the 1990s. Such fonts may be intended for text or display usage scenarios. But a font like Decovar (or, say, Buffalo Gals) is different: it's suitable for display, but not text; and the kinds of parameters that can be manipulated are really geared towards display scenarios. (Now, perhaps Amstelvar is a different story, but let's stick with Decovar for the moment.) Certainly in the past, if you were developing type with this approach, you'd only be able to manipulate the parameters in design tools, and then you'd need to export specific instances that your customer wanted. So, in that case, the customer wasn't the one manipulating all the sliders. Today, with OT variable fonts, potentially they could be manipulating the sliders. I'm going to guess that many potential users might not want to manipulate sliders for Decovar: it's so many choices, and the user just wants a quick choice. But those probably wouldn't be the kind of user that a variable Decovar would be primarily marketed to. Rather, you'd be looking at the graphics professional working on a display setting in which they want to use their creative skills to tweak the options the font provides to fit the design goals for the project. So, maybe the font with a limited set of named instances may be useful for the casual user, but I'm thinking that the real target for such a font is the more specialized designer who will want to access the full variation capabilities of the font. And that person will not want to use the font in legacy apps that can only support selecting certain named instances; rather, they'll want some newer apps that support selection of arbitrary axis values on arbitrary axes defined in variable fonts. Just thinking out loud --- thoughts that may be relevant when thinking how a STAT table should be set up for a font like this. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXBwUUO74099B9woCtc6olW4fB3SuD7ks5rcih7gaJpZM4L7nxt>.

----------------------------------------------- Petr van Blokland | twitter+skype @petrvanblokland Intentionally not on FaceBook. [email protected] | www.petr.com mobile [phone] | buro [phone] ----------------------------------------------- Rietveld 56 2611 LM Delft The Netherlands ----------------------------------------------- Claudia Mens | [email protected] mobile [phone] | buro [phone] -----------------------------------------------

[davelab6]

The “big standard axes” (width, weight, size) can have virtually infinite axes rolled up inside that define large or subtle flavour differences (rounded corners, “victorian style”, roughness, etc.), once the big choices have been made. (If he/she found the restaurant-district in the city from a location on the map, it is still up to the traveller to find the right kind dish, depending on taste, preference and time of the day.

It seems to me that sometimes users will just want to drive along the highways, or the paved roads, and other times will want to go on an off-road safari.

Being able to mark which axes are roads and which are not seems, important.

[dberlow]

All included in my next presentation and demonstrations. Talk is cheap but variations are expensive;)

…

On Feb 21, 2017, at 12:03 PM, Dave Crossland ***@***.***> wrote: The “big standard axes” (width, weight, size) can have virtually infinite axes rolled up inside that define large or subtle flavour differences (rounded corners, “victorian style”, roughness, etc.), once the big choices have been made. (If he/she found the restaurant-district in the city from a location on the map, it is still up to the traveller to find the right kind dish, depending on taste, preference and time of the day. It seems to me that sometimes users will just want to drive along the highways, or the paved roads, and other times will want to go on an off-road safari. Being able to mark which axes are roads and which are not seems, important. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[davelab6]

@djrrb is the stat table source in this repo?

[djrrb]

@davelab6 yes, here it is: https://github.com/TypeNetwork/fb-Decovar/blob/master/sources/2-build/stat.ttx

[davelab6]

Thanks! However, where is the name table info that it points to?

[djrrb]

Ah, right. That's not stored separately since it is compiled from the UFO sources, but you can get it by ttxing the variations TTF.

[davelab6]

I'm confused; the UFOs don't have this data either, so is it in the private build system? (In that case, I don't understand why it isn't source file data :)

[djrrb]

The UFOs have fontinfo.plist, which is used as the basis for the name table when the font is compiled (see the build script) and then fontTools varLib to generate the vfont version.

For now, fontTools doesn't build a STAT table, which is why I have to keep a separate copy and stick it in the final font. But the name table is already present in the compiled fonts, so I don't store it separately. Is that helpful?

[davelab6]

FontView shows the axes names from the name table to the left of the sliders:

But in fontinfo.plist files those names aren't present,

https://github.com/TypeNetwork/fb-Decovar/blob/3f3894175129e79494b1c90f6a4e19aa16dcfe01/sources/2-build/Decovar-Regular24WeightMax2.ufo/fontinfo.plist

nor are they anywhere else in the repo :)

https://github.com/TypeNetwork/fb-Decovar/search?q=%22weight+max%22&type=Code&utf8=%E2%9C%93

[djrrb]

Ah, those come from the Decovar.designspace file...forgot about that!

…

On Wed, Mar 15, 2017 at 8:52 AM Dave Crossland ***@***.***> wrote: FontView shows the axes names from the name table to the left of the sliders: [image: screen shot 2017-03-15 at 08 50 29] <https://cloud.githubusercontent.com/assets/261579/23949130/73fea0bc-095c-11e7-8495-2b6046b69d77.png> But in fontinfo.plist files those names aren't present, https://github.com/TypeNetwork/fb-Decovar/blob/3f3894175129e79494b1c90f6a4e19aa16dcfe01/sources/2-build/Decovar-Regular24WeightMax2.ufo/fontinfo.plist nor are they anywhere else in the repo :) https://github.com/TypeNetwork/fb-Decovar/search?q=%22weight+max%22&type=Code&utf8=%E2%9C%93 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGRirTLIZjn_jgXwaaQxwmDjenGak-Wsks5rl98lgaJpZM4L7nxt> .

[djrrb]

Sorry for the incomplete answer...I also had to add unregistered axes to my version of fonttools...will document this as soon as I return from my travels!

…

On Wed, Mar 15, 2017 at 8:56 AM David Ross ***@***.***> wrote: Ah, those come from the Decovar.designspace file...forgot about that! On Wed, Mar 15, 2017 at 8:52 AM Dave Crossland ***@***.***> wrote: FontView shows the axes names from the name table to the left of the sliders: [image: screen shot 2017-03-15 at 08 50 29] <https://cloud.githubusercontent.com/assets/261579/23949130/73fea0bc-095c-11e7-8495-2b6046b69d77.png> But in fontinfo.plist files those names aren't present, https://github.com/TypeNetwork/fb-Decovar/blob/3f3894175129e79494b1c90f6a4e19aa16dcfe01/sources/2-build/Decovar-Regular24WeightMax2.ufo/fontinfo.plist nor are they anywhere else in the repo :) https://github.com/TypeNetwork/fb-Decovar/search?q=%22weight+max%22&type=Code&utf8=%E2%9C%93 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGRirTLIZjn_jgXwaaQxwmDjenGak-Wsks5rl98lgaJpZM4L7nxt> .

[davelab6]

Ah, those come from the Decovar.designspace file...forgot about that!

But I don't see them in https://github.com/TypeNetwork/fb-Decovar/blob/master/sources/2-build/Decovar.designspace :)

Sorry for the incomplete answer...I also had to add unregistered axes to my version of fonttools...will document this as soon as I return from my travels!

Thank you David! :)

[djrrb]

Half-solved, if I'm not mistaken. The STAT table has the axis information but not the named instance information. Between the complexity of the axes in this font and the fact that fontTools doesn't write it, I was waiting to do another pass once the STAT writing tools progress.

…

On Wed, Apr 5, 2017 at 9:30 AM Sam Berlow ***@***.***> wrote: @djr <https://github.com/djr> is this still an issue? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGRirYSfaRZAT25uHgTNPCBlSj7Pv40-ks5rs5d0gaJpZM4L7nxt> .

[sberlow]

@djrrb Are we still waiting on this?

[djrrb]

As far as I know, there is still no tool for writing STAT. Maybe others know differently?

I don't think I have a way to reliably write this table in a font this complex (a single axis I was able to do, at least I think). What is included here in stat.ttx I did by hand with some guesswork and no way to reliably test.

Is it ok to continue to wait?

[djrrb]

In the meantime, we crafted a rev of Decovar with a STAT table using format 4 AVTs so that we could validate our DWrite implementation.

@PeterCon, now that the format 4 PR is merged, are you able to commit your revised Decovar STAT table? Thanks!

[davelab6]

@PeterCon, now that the format 4 PR is merged, are you able to commit your revised Decovar STAT table? Thanks!

@PeterCon would be great to see this :)