googlefonts/roboto-flex

roboto-flex's Issues

Proofs 2019-07-12

docs > Proofs > RobotoExtremo_pdfs_2019-07-12

Design Space ASCII-showing of 27 instances in the range of the design space
Regular WGL-comparisons of current default WGL with the original
Light ASCII-comparison of Light VF instance with the original

Glyph lists and groups

Roboto-Extremo/docs/Extremo Video proofing/

Folder contains two rtfs explaining themselves.
These are the latest edited versions.
For use at http://videoproof.typenetwork.com

Please leave comments here.
Thanks,

RobotoExtremo-opszmax-wghtmin-wdthmin

The extreme extremo above is complete with ascii drawn and on the repo.

I am going to review the current build but

1. I'm giving you the go-ahead to rebuild in this corner into a final build for this version.
2. Then I will be able to look at that var, check all of the glyphs of ascii, per spec.
3. then I need to find the intermediate instances for correction of the contrast.
4. get those made.
5. Then I have to correct those, and
6. return them to you for a "final" ascii build with those intermediates.

Delivery now Probable monday or tuesday next week.

Clear?

Thanks.

List of initial designspace caps

Santiago, or CJ now that it’s monday,

Capping instances. The ‘From’ is copied and ’becomes named’, which is then added to the Designspace.
From: Becomes named:
opsz 144 wdth 100 wght 100 — Opsz 144 wdth 100 wght 100 GRAD mIn

Which fixes the whole wght min incl. eg...

opsz 144 wdth 100 wght 900 — opsz 144 wdth 100 wght 900 GRAD max
opsz 144 wdth 75 wght 400 — opsz 144 wdth 75 wght 400 XTRA min

opsz 144 wdth 75 wght 900 — opsz 144 wdth 75 wght 900 XTRA min

Some instances illustrated, check other issues for ongoing additions. will be needing to translate to design space and sources, then into a narrative and illustrated doc with examples, values in sheets and truevalues.

But building soon documenting shortly after, so we can make sure the three registered axes and grad are all “safe” instances.

And we need to do this before trimming, capping or tailoring other axes.

ASCII MONDAY Build

Santiago,
ASCII is done for three new Extremo axes.

Please add:
GRAD min and max
YTAS min and max
YTDE min and max
to design space.

Give them each their parametric values from DELTA axes values.

And build, thanks.

Opsz rap order

The current rap order in not in opsz numerical order.

Can we start the rap at 8 pt, run the rap of That opsz, end at the opsz 8 default
interpolate to 14 pt, run the rap of That opsz, end at the opsz 14 default
Interpolate to 144 pt run the rap of That opsz, end at the opsz 144 default
interpolate to 14 pt
End?

Repo clean up

I'm sad to see that there's an "olds" folder in https://github.com/TypeNetwork/Roboto-Extremo/tree/master/fonts yet the old stuff is still lying around there... I would like to request that someone take a good fresh look at the repo and sort it out so it is clean and intelligible to a reasonably competent type person

If there's old files lying around with a reason, I'd like to see them in 'old' folders, with a README.md that explains why we are keeping them around for future reference, etc

Glyph Extension Monetary

Have normalized all for 14 pt.
Smoke proofs below. Top is before, bottom is after.
Please review, and reply,

thanks.

Process notes for ascii protoype

The next step was going to be to adjust the individual members of the XO, YO and XT axes, back, into one axes, XOPQ, YOPQ and XTRA, leaving both the merged and unmerged axes in the design space, unmerged, XO?? E.g witH hidden flags.

This now has to be done after the caps are put on grad, and before the XOPQ, YOPQ and XTRA can be trimmed and tailored for a safe ascii space. That trimming and tailoring, and any bug fixes that emerge, are now the goal of today.

We are pursuing a safe design space for ascii with the registered axes, grade, XOPQ, YOPQ, XTRA and parametric y axes.

I am cruising the space for bugs outstanding inthe font and apps until then.

Extremo activity report text v1.0

Roboto ExTREMO sept 13.
Notes on what’s next at bottom of issue.

Notes on what’s done and in wkend progress.
With Jill’s help, i got 1, 2, and 3 done. Did 4 in videoproof. Generated the opsz masters and rebuilt w/Santiago. Took three days on 5. Just starting 6-9.
Current font here: github.com/TypeNetwork/Roboto-Extremo/blob/master/fonts/RobotoExtremo-VF.ttf

1. Discovered and repaired contour direction, composite and contour reversal bugs found by hand.
2. Specified and had written a series of scripts the find and report these kinds of errors, no other software was aware of.
3. Repaired shapes pointed out by DC in last meet, and searched all design space for any similar or other kinds of visual inconsistencies.
4. Contextually Proofed design space for glyph spacing of ascii, repaired a small number of spacing issues.
5. Added 18, 24, and 36 point masters to opsz axis, in the process, redistributing the variation of weight and width into inverse pyramid, with more style choices as size increases.
6. Surveyed and sketched the design space for likely ranges of tabular figure widths. Then determined where tabular ranges were possible and checked, edited and instanced all the required intermediates. All figure <14pt are tabular, most figures from 14>36 are tabular until OS/2 700wght, and above 96, few of the figures beyond 500 are tabular, and at the wght min and max there is little opportunity for tabular figures.
   Made introduction to issue pdf attached right below.
   Tabular with variations.pdf
   Made movie of final result: drive.google.com/a/fontbureau.com/file/d/1o2KYYTjOdhh1ZmUwRs7yuwyIMY8Q4Xiq/view?usp=drivesdk
   Made charts. -PDF attached below
7. Added experimental instance to control “e” middle stems in preparation for fixing a,e,s and ø over wght at opsz>36.
8. Proofed opsz 8-14 with composed/small format, Discovering bug only in wdth 125’s word space values. See png below.
9. Made comparison compositions to Jason P. and Donny T. ‘s expert web typography.
10. Evaluated kern pairs of Roboto regular for Extremo default’s kerning.JP

Gathering links

New opsz max

Client has requested less condensed opsz max.

The proposal illustrated above is to replace the opsz144wdth100wght400 (H1 above), with a wider, heavier version as pictured (H2 above).

Should we do and redistribute?

Feb. 1 delivery

Discussions with client led to need to deliver a test candidate of RobotoExtremo
ASCII is required only
wght, wdth & opsz only (and corners)
Feb. 1 delivery

All the required glyphs of this space need to be drawn except:

The upper and lowercases of :
RobotoExtremo-opszmax-wgthmax-wdthmax
RobotoExtremo-opszmax-wgthmax-wdthmin
and,
RobotoExtremo-opszmax-wghtmin-wdthmax
RobotoExtremo-opszmax-wghtmin-wdthmin

Have been drawn to completion.

Looking for help on the rest of ASCII.

extremo axes detail

Below is a guide to the current masters of Extremo and how those are intended to flow into the product.

The registered axes, grade and the Latin extenders are all unchanged in this process and ready for use.

The parametric axes have been divided into three constituent axes, for uppercase, lowercase, and figures, with most of the rest of the ascii glyphs varying along with one of the three groups. The two reasons for doing this are; that use of parametric axes on glyph groups, by end-users, has been suggested and is here the option is demonstrated.

The main benefit we hope to receive from this trisection is to use different values to adjust the design space and make it safe with use for all the axes, and experience has shown that these adjustments are more controllable, yielding more useful results, on character groups rather than the whole character set.

These trisected axes, once employed to make the design space safe, can then be merged into single parametric axes and used as they have been previously.

Registered axes
OPSZ
WGTH
WDTH

Renewed master:
GRAD min max

Renewed Y trans masters:
YTDE min max descenders
YTAS min max ascenders

New Y-trans Trisected masters, will remain in product?
YTUC min max Uppercase Ht.
YTFI min max Figure ht.
YTLC min max lowercase ht.

New X-trans Trisected masters. Will be combined in product
XTUC min max Uppercase x-transparent
XTFI min max Figures x-transparent
XTLC min max lowercase x-transparent

New Y-opaque Trisected masters, will be combined in product
YOUC min max Uppercase Y-opaque
YOFI min max Figures Y-opaque
YOLC min max lowercase Y-opaque

New X-opaque Trisected masters, will be combined in product
XOUC min max Uppercase X-opaque
XOFI min max Figures X-opaque
XOLC min max lowercase X-opaque

Please comment, thanks

Bad FeatureTableSubstitution version 0x00010001, only 0x0001000 exists in spec

https://github.com/TypeNetwork/Roboto-Extremo/blob/master/fonts/RobotoExtremo-VF.ttf fails to process with tools like the FontTools instancer. This appear to be because it has FeatureTableSubstitution.Version 0x00010001. The spec appears to only define version 1.0 (0x00010000): https://docs.microsoft.com/en-us/typography/opentype/spec/chapter2#featuretablesubstitution-table.

If you ttx it and correct that version then it works fine.

Investigation courtesy of @anthrotype

Marked kerning proofs

Kerning proofs have been posted in this folder:
https://github.com/TypeNetwork/Roboto-Extremo/tree/master/Marked%20Kerning

David, can your clarify the meaning of the red, yellow and green highlights?

A no-cap, no trim, no tailor instance

I have already specified;
opsz 144 wdth 100 wght 900
To be caped at;
opsz 144 wdth 100 wght 900 GRAD max
And
opsz 144 wdth 100 wght 900 XTRA min

...meaning that the GRAD and XTRA axes have no safe room to move To add weight via GRAD, or narrow any further with XTRA.

This is also true at:
opsz 144 wdth 100 wght 900, YTUC min,
opsz 144 wdth 100 wght 900,YTLC min,
opsz 144 wdth 100 wght 900, YTFI min
opsz 144 wdth 100 wght 900, YOPQ mIn

Likely too,
opsz 144 wdth 100 wght 900, YTDE min,
opsz 144 wdth 100 wght 900, YTAS min,

By “Min” I mean - shorter - ascenders or descenders, than the defaults.

Grades/ Iijl issues

Roboto Extremo grades, Iijl issues

Grades are required for RobotoExtremo, a san serif with broad opsz, wght and wdth axes, Google “Latin plus” repertoire, and no serifs on I,i,j or l.

Grade range is limited in sans if these glyphs are no-serif designs, without serif alternates. The x direction structure of these glyphs without serifs contain no interior white space, aka counters, and so the inter-character spacing of these glyphs is effected by changes in the grade axes to the detriment to consistent letter spacing.

If a typeface family only has non-serif versions of Iijl, the grade range for every instance in the design space depends on whether there is enough/too much space in the side bearings of these glyphs as the weight shrinks and grows on a given width, to produce grades. Closer to the default is less difficult, the farther down wdth min, the narrower the grade range. The farther up wght max is similar and combinations of wdth min and wght max have narrowed grade ranges.

The options with no serifs:

A movie has been made to help illustrate some of these issues.
https://drive.google.com/file/d/1gOZiXdTnvK0h3Mg8eU5R2vZB11JD_LWA/view?usp=sharing

A. obey Strict limitation of widths all over the grades of the design space, based on the where the spacing on Iijl fail.

B. Maintain the widths until spacing is untenable, and then “relax” the width restriction for Iijl and allow more grade range on them and the rest of the space. This relaxation goes in both directions, lighter grades of these characters will get narrower widths and bolder grades will get wider widths to protect the spacing over strict grades for Iijl.

The options with alternates, I.e adding Iijl with at least 1 serif each, basically means adding a separate set of widths for those glyphs, and then only if the glyphs are all turned on at once via OT features, the entire design space needs two separate solutions for the grade axis’ limitations:

A. Make stylistic alt that used Use only serif versions of Iijl, (in which case the option is open to use these < e.g. 14 pt in opsz for legibity via gsub and rvrn). Grade ranges expand over the whole space when these alts are turned on by user.

B. Gsub serif versions of Iijl in appropriate grade axes locations to expand the grade range. For the most part, this would expand the lighter range of the grades, e.g. the lighter grades of wide instance, the serif UC I could “grow” serifs to better occupy the additional space opening up in the glyph. If the stylist alts are not turned on, the user would have control only by limiting their grade selection themselves, to where the serifs remain hidden along opsz.

C. A other issues can open up over options.

Note: There are other characters In the repertoire that are affected by this and can't be ignored entirely by some combination of frequency of use, like “|” (vertical bar), and impossible-to-restructure-for-sans-grades-glyphs like “!”.

Prototype Proof deliveries

In order to better review and critique Extremo the client would like to print it.
this is a job for the delivery of the prototype FB has agree for TN to provide.

I would therefore like to request to have 27 PDFs made and delivered to the clients that have been tested and can be printed.

There is an Illustrator template in Docs for use as model.
https://github.com/TypeNetwork/RobotoExtremo/tree/master/docs/Extremo%20AI%20proofs

ExtremoLegalasciiTemplate.ai
ExtremoLegalasciiTemplate.pdf

This template is designed so all the glyphs of any style in the design space fit on the page at the type size specified. this shouldn't need to change, just the font.

The styles and spec are pasted below:

1. The latest Extremo build does not work in Illustrator, (failures are illustrated in /Docs)
   a. font should be remade to work in illustrator
   b. 27 pdf made by hand or otherwise. and/or
2. rePaginate in Pagebot
   a. font should still be fixed
   b. make pdfs with pagebot.

Extremo prototype production
Proofing extremes, ascii.
Delivered as pdfs asap.

Page size: US legal/portrait

Template: Text and composition 100% to template on repo above.

make 27 one-page pdfs, One page of each style listed below

Style list
font-variation-settings: "wght" 400, "wdth" 100, "opsz" 288
font-variation-settings: "wght" 100, "wdth" 100, "opsz" 288
font-variation-settings: "wght" 900, "wdth" 100, "opsz" 288
font-variation-settings: "wght" 400, "wdth" 75, "opsz" 288
font-variation-settings: "wght" 400, "wdth" 125, "opsz" 288
font-variation-settings: "wght" 100, "wdth" 75, "opsz" 288
font-variation-settings: "wght" 100, "wdth" 125, "opsz" 288
font-variation-settings: "wght" 900, "wdth" 75, "opsz" 288
font-variation-settings: "wght" 900, "wdth" 125, "opsz" 288
font-variation-settings: "wght" 400, "wdth" 100, "opsz" 12
font-variation-settings: "wght" 100, "wdth" 100, "opsz" 12
font-variation-settings: "wght" 900, "wdth" 100, "opsz" 12
font-variation-settings: "wght" 400, "wdth" 75, "opsz" 12
font-variation-settings: "wght" 400, "wdth" 125, "opsz" 12
font-variation-settings: "wght" 100, "wdth" 75, "opsz" 12
font-variation-settings: "wght" 100, "wdth" 125, "opsz" 12
font-variation-settings: "wght" 900, "wdth" 75, "opsz" 12
font-variation-settings: "wght" 900, "wdth" 125, "opsz" 12
font-variation-settings: "wght" 400, "wdth" 100, "opsz" 8
font-variation-settings: "wght" 100, "wdth" 100, "opsz" 8
font-variation-settings: "wght" 900, "wdth" 100, "opsz" 8
font-variation-settings: "wght" 400, "wdth" 75, "opsz" 8
font-variation-settings: "wght" 400, "wdth" 125, "opsz" 8
font-variation-settings: "wght" 100, "wdth" 75, "opsz" 8
font-variation-settings: "wght" 100, "wdth" 125, "opsz" 8
font-variation-settings: "wght" 900, "wdth" 75, "opsz" 8
font-variation-settings: "wght" 900, "wdth" 125, "opsz" 8

Post on own docs folder by june 22.

let me know, thanks.

Hidden axes in next version?

Hey Chris we’re planning on changing some of the axis and extreme out to be flagged ‘hidden”. If possibl4, these need to NOT show in typetools or videoproof, even in “wait there’s more...” and “show all axes”.

Let me know if this is feasible

Components: Reference to Missing or Duplicate

In the 1-drawing folder

In all styles the /idotless has a duplicate component in the /idblgrave glyph.

The following two styles have a lingering reference to /hornU
RobotoExtremo wghtmin
RobotoExtremo opszmax-wghtmin-wdthmin

Spreadsheets

Jill has pointed out the difficulty of moving bug reports for the proofing to sheets.

I agree that getting bug reports from proofs to somewhere else is not as easy as it could be.

I need you to see this exposes that there is zero difference between the sheet of a font that hasn’t been reviewed and marked, and a font’s sheet that has been reviewed and marked.

The spreadsheet is an attempt to remedy that because, by implication, something that has not been marked is good, to whatever point the review is done.

need instances...

Hey So, can you make a new folder with "instances" and put;
RobotoExtremo-opszmax-wghtmax-wdthmin
&
RobotoExtremo-opszmax-wghtmax-wdthmax

...in it so I can clean-up mañana?

Let me know...Thanks

YTLC + XTLC?

I like to control the xheight of latin fonts. Currently we only have YTLC but this makes letters thinner as they get taller. I believe we need a XTLC to be able to keep lowercase glyphs proportions steady while scaling them up.

XTRA for space?

I wonder if the space characters should have their own xtra axis, like lc/uc/asc/desc do?

Full glyphs drawn, composited and edited

these proofs were made analyzed, corrections marked and made. RobotoExtremoWGL-Regular

Fixing opszmax-wghtmin-wdthmin figures while waiting

Looking for completion of estimated 6-hour design (fix $ ), 4 hour production to make var; since weds.

Working to QA and complete figures of opszmax-wghtmin-wdthmin

in offline ufo into synched to latest work.

Working out ways to proof vars like this, seeing simple instructions to Typetools.
Roboto Extremo opsz> proofs.pdf

Tabular figures movie

Seeking permission to share:

https://drive.google.com/file/d/1o2KYYTjOdhh1ZmUwRs7yuwyIMY8Q4Xiq/view?usp=sharing

Which will be linked to description of Tabular figures in Roboto Extremo.

Some text gathered below:
Variations fonts with tabular figures.

Summary: Roboto Extremo has a range of sizes from 8pt to 144, with intermediate sizes, that allow the weight and width ranges to expand as the pt size increases above the 14 pt default, and for those ranges to reduce as the size elbow 14 pt decreases.

From the current default master, 14pt, to the opszmin of 8pt, with the current wght and width axes, we get tabular figures from 100 to 900 wght, and from 75% to 125% wdth. So a solid block of tabular figures exists for 8-14 pt, all widths and weights.

The other opsz sizes are currently; 18, 24 and 36, which are included to expand the wdth and wght ranges greatly at larger sizes. Tabular figures for 144pt over the entire wght and wdth axes, are not possible, as a function of type design elaborated below.

At 144 pt as the width diminishes and expands dramatically, to less than 30% of the width of default and 150% wider. So, the narrowest style’s tabular figures could become limited to a range from 380 to 420 wght, e.g., but for the designer’s decision to not include them at all. The main problem at size max, width min is that the widths of O and 0, are so close, that small changes to the tabular width can create ambiguous appearance.

Background: We have several specifications to include tabular and proportional figures, so Both are going to reside in the default font, one or the other reached but opentype feature. In a typical font family’s weight range with tabular figures, all of the tabular figures are on the same width, or Occasionally we can find a family where the ultra, or extra bold and bolder are on a greater tabular width than the regular and the other widths, or These bolder weights may abandon tabular figures all together.

Increasing weight causes issues of crowding as 0,9,8,and 6 needing to be on the same width from thin to black. Increasing the tabular width leaves openly spaced figures 1 and 7. Pressures on tabular figures at both extremes of the width axis also exist to make a single tabular figure width across all the weights of any width on the width axis.

Tabular figures have a significant number of “parents”. They must work with the upper and lowercase, and with the pnums, proportional figures of the same style I.e. the proportional and tabular figures can’t look similar enough, and a tabular figure width can’t interfere.

Possibilities above 14 pt.
A. Let loose the requirement for tab figures to match across wght and width above 24 pt. Most uses above that size should be either for a single wght, like One might use to display a digital clock composed large, or switch the use to pnums above some opsz.
B. The weight axes is broken up with a variety tabular width ranges. This is documented and users work around it.
C. Advise use of the GRAD axis above 14 pt.
D. Adding an “informational” XTAB, or x-tabular axis, would be the most useful solution, long-run.

Redefine opsz max

SO,

Please change opsz max from 144 To 288,

Otherwise no changes.

Remake, let me know, and will propagate.

ASCII Delivery

A new version of Roboto Extremo is posted that contains a working prototype of wght, wdth opsz and GRAD axes, and alignment adjustment axes for uppercase, lowercase, ascenders and descenders. There are also,more parametric axes, filling out the full repertoire of major axes included in the final product.

And new versions of TypeTools.typenetwork.com, and Videoproofer.typenetwork.com are also running. Both have additional links to the repositories and issues section, and Videoproofer has many new functions, but is simple to set up and show ASCII glyphs animation through both registered and other axes. Videoproof Readme has also been updated, and live Documentation for both apps is

We will continue on refining the parametric design space for the next 24 hours and then go on to the remainder of the glyph repertoire in the fonts, the more complex layouts and type functions of video proofer and any bugs or enhancements you'd like fixed.

Please inform Dawn, Paula and others as required, as I don’t have their github handles.

FB/TN progress, June 28-July 12 Roboto Extremo

FB/TN progress, June 28-July 12

Font Projects

Roboto Extremo
Extended opsz from 144 to 288,
#9

We are waiting on feedback for this because the need to fix the optical size to the appearance of weight min, Should imply changes to all the rest of design space.

Converted repo to Travis,
https://github.com/TypeNetwork/Roboto-Extremo

Added proofing for 27 styles of Registered Axes space to process
Delivered proofs of ascii to repo,
https://github.com/TypeNetwork/Roboto-Extremo/tree/master/docs/Proofs/RobotoExtremo_pdfs_2019-07-12/Design%20Space%20ASCII%20%20

Received overlay proofs of Regular wgl
https://github.com/TypeNetwork/Roboto-Extremo/tree/master/docs/Proofs/RobotoExtremo_pdfs_2019-07-12/Regular%20WGL

We are looking for approval of the glyphs of extremo default after the expansion to the WGL repertoire.

Discussed documenting grades issue, supplied movie Iijl
Added extremo tnums to discussion of Amstelvar tnums
‘Grades & tnums’ (google slides).

tnum strategy must be decided so tactics can be proposed.

Generated opsz min only axes.
https://github.com/TypeNetwork/Roboto-Extremo/tree/master/fonts

Extremo leveling g

I’ve done sketches of some proposed changes of axis levels on 5 sizes of the opsz axes at wght min and max axis, to bring more of the display attributes down to smaller sizes. This redistribution of the variation is intended to smooth out the changes with a series of intermediates.
https://docs.google.com/presentation/d/1EA6QPUPUKPEZqGykYx1pIKKK6egs4BJNDaRaWPMLWlc
The current instances are only I,14 and 144.

Contains 4 slides illustrating sample leveling

1. Slide shows what has already been done to change the default weight and width over the size range from 14 to 144. Left is the current default at 5 sizes. Right is the default at all 5 sizes.
2. Left Shows H2 H3, of the five sizes masters of wght min, heavy. This could be lightened by a larger optical size but I’m happy with its proportions so I used -GRAD.
3. Left shows that all sizes below 144 need some beef, and right adds the beef to all but 144.
4. Shows one possible weight range over sizes after leveling.

Width axis range

The width axis range is current 75% to 125% of regular; but this may be true of the opsz-def, but it is not true of the opsz-max, which gets much wider and much much narrower than those percentages.

Therefore I recommend we range the MSFT wdth axis to the opsz-max proportions, so that the user's sense of what the range of the typeface is - extreme-o - is surfaced

Fresh proofs today

CJ or SO,

CSS proofing advances a space, but is not ready now.
(See: FontBureau/videoproof#12 for details)

We WILL need pdf proofs of 27 styles of extremo added as a separate folder from the last versions of the proofs, and the client should be notified via repo.

The registered axes, ascii, is complete for the default 27 styles of the prev. proofs.

Pretty urgent today,

Let me know, thanks.

Small opsz-max wght-max wdth-min bug

fonts/RobotoExtremo-VF.ttf introducted 4 days ago (d7095e2) has an issue in the very end of the opsz-max, wght-max, wdth-min:

The "laughing e" is not laughing, but there is still something funny going on in this region :)

Need 2 instances

opszmax
wght min
wdth max & wdth min

opszmax, wght min, wdth max
&
opszmax, wght min, wdth min

Let me know thanks!

Latest build acscii Contour bugs

Ascii tilde & Grave contours out of order FIXED

Lowercase extender trimming

Trims:
opsz 144 wdth 100 wght 900 YTAS 706 to opsz 144 wdth 100 wght 900 YTAS min
opsz 144 wdth 100 wght 900 YTDE -167 to opsz 144 wdth 100 wght 900 YTDE min

Fix: figure 2, opsz 144 wdth 100 wght 100 GRAD 0.91

Regular (default) and scaled kerning

Review and fix kerning for RobotoExtremo-Regular.ufo. Use the common pairs shared by Classic Roboto Regular as a starting point.

Use DB's example of XTRA for a VF kerning solution for propagating kerns through the design space.

Proofing in AI

Illustrator 23.0.6

Not yet able.

Extremo ASCII delivery notes

Dave,

Based on a tentative "yes" the the breadth of the RobotoExtremo design space, a prototype was requested for delivery to Material Design for testing.

That font is now in the "fonts" folder.

In the proofs folder are the first set of proofs for this Roboto Extremo variable font

This proof is big enough to contain all the glyphs of more than 30 styles on one page for zooming and marking, glyphs, styles and axes with comments, or just to see them together.

Further proofs as required for future deliveries will be added as software is developed to generated such proofs.

The font currently contains 3 axes;

1. wdth
2. wght
3. opsz

The Glyph repertoire contains ASCI glyphs throughout
the space

There is an exception of a few of the lower useage glyphs
in the boldest and most condensed of the largest optical size,
These are only as bold as a previous version.

The font is recommended for use with browsers, more than
with applications like illustrator.

Unregistered axes UI values

Dave, Friday I showed, and remaining in the current built, a GRAD axis with UI values at -1,0,1. This started a discussion of the “real” I.e. parametric values, and confirmation of the existing limitation of the implementation,on the issue of axes values.

Until,parametric values are accurately display via truevalues, they can only be used accurately by,programs. So, in consideration of,the current schedule and target audience, i’d Like to try relative values -1,0,1, on the parametric axes that are relative, I.e. not the y-transparencies.

This also will have the UI advantage of an explicit default, 0, that currently neither the existing values, or the true value.js has. Once a user slides off the default... what was the default?

Let us know, thanks.

Parametric range versus instance volume

Summary: we spoke of this in the spring; that if avar2 did not come along, we would have to make a choice between a. narrow some parametric axes with a few intermediates or b. Leave some broad parametric axes with many instances, (capping off and tailoring), to control the many double deltas in our far-flung designspace.

Looking at the current build’s axes of concern, (xtra yopq and xopq), I’ve been reviewing the parametric effects on this design space of Roboto extreme ascii and would like to make a decision this morning. If (a) above, There will be broad xtra, yopq and xopq axes, and around 60 additional instances to control them. And option (b) above, Narrower parametric axes will require 16 to 20 additional instances.

Process here is: to tailor each parametric axis for the optical size axis, and then for the extremes of weight and width for each optical size. The broader the parametric range, the more the change flings out beyond these basic instances and into the combinations of these axes, and that requires more control instances.

Are they ever going to do avar2?

User and developer guides

“User’s Guide
An evolving illustrated text, that is authored with font users as a primary audience, that explains how to understand and use the Deliverables, similar to a traditional typeface “specimen” guidebook.”

1. Having the fonts complete is a prerequisite for completing this. We are currently waiting for two weeks for input on tabular figure solutions, and final optical size intermediates.
2. While waiting, a specimen guidebook has been sketched, and mocked up to a point where coding can begin based on the complete state of the default font, the complete ascii of the registered axes, and the need to know how much existing code will work, before design of specimen pages is required.
3. Version 1, in the evolving illustrated text, can then be released for extremo when 1 and 2 are done.
4. Version 1 would include 3 sections, 14-16 pages as posted in pdf on repo.

“Developer’s Guide
An evolving illustrated text, that is authored with type designers as a primary audience, that explains the design process, design space, glyph designs, and other details of the Deliverables, similar to a traditional typeface “proof” document.”

1. The initial description of this (relying on sketch, illustrator and PostScript), has been superceded by development of css that makes a moderately difficult collation become easy to augment and simple for distribution via web. The evolving guide is contained currently in the working files on the repo, and there is enough code and type covering the whole process, to begin collation.
2. FB/TN have developed css code to show the progress of a variable font with the following:
   a. Glyphs development guide proceeds in an order defined independent of variables. This order is captured in a google sheet, and can be displayed for any font by the display of the order for the default. A Google sheet with the complete extremo glyph repertoire exists, and can be marked for the ideal order of glyph development, from control characters, to the last nested composite.
   b. A Design space development guide , i.e. the order that styles are planned and varied, and order each of those styles is finalized, is being illustrated based on a common format used at variablefonts.typenetwork.com/topics/styles/variations, to be shared with the user guide and the developer guide. In isometric view, where multiple sizes need to shown, or in single rectangular slices of the design space, this is the template and it will be used to show each stage, from the default font’s design, through each axis, to the last “cap” of the last parametric axis,
3. Additional stages of the process,
   a. including grade development, Kerning, parametric trimming, and capping, e.g. can be illustrated and documented as of now.
   B. opsz intermediates, tabular figures and features, defined instances and final values systems for parametric axes are all waiting on the client for feedback to continue completion of extremo and documentation of those processes involved.

Continuous Integration

I'd like to see this project building the binaries using Travis Continuous Integration, and posting them to the gh-pages branch.

Happy to provide more details/context if this doesn't make sense.

"New" Folder in "1-drawings"

The New Folder in the 1-drawings fold contains three extensions to the width axis, opszmax-widthmin wghtmin, opszmax widthmin and opszmax wdthmin wghtmax.

A-Z and a-z only for client's approval.

Measure xtra to determine proper os/2 wdth values by % of default.

Include both the existing width and these extension as defined instance in var.

let me know if ?

Thanks.

The key frames are now playing along in bold red

...which is really cool!

Vietnamese diacritics

Vietnamese diacritics are an interesting challenge in a vf with broad opsz, wght and wdth.

Vietanh Nguyen Has kindly reviewed the Roboto (classic), and also advised us on issues with Amstelvar we’ve been working on.

Here is my summary of some of that advice:
KERNING HORNS, a. The horn and diacritics should be close to the same amount of visual impact on the reader, not a horn more prominent than diacritics above, and b. That horns should attach close to, or at the square height, (H or x), not lower where they interfere with adjacent following glyphs.
PAIRING HORNS, shows that horns of glyphs within each case should top-align commonly. I also see that Plex uses one form for both upper and lowercase, and has wider and narrower versions.

SIZE & WEIGHT, are I fact a large challenge in themselves, so in a design space with optical sizes, widths and weights I am expecting Roboto Extremo to set a good example.

The glyph architecture of extremo intended so far to provide flexibility for different cases, and for being stacked, and we need to proof that.

But the requirement for horns in a broad design space, to both top align and connect well aesthetically to round and square-topped glyphs, as it relates e.g. to design space at opsz-max, wght-min, implies horns that are glyph-specific.

We can get all this right in the default of Roboto extreme out before we do any further work to make sure that every composite and glyph gets a correct architecture and variation to allow for correctly positioned, weight and widthed diacritics for each language, Including Vietnamese.

Roboto Extremo proofing notes

There is a natural affinity between the frame-based nature of video and the need to present the styles in the design space of variable fonts. CSS-based Variable Font animation is widespread and the font software support exists for use of CSS and variable fonts with all modern browsers.
https://variationsguide.typenetwork.com/proposal/images/animation-xtra.gif

Simple Variable fonts can be made that require the same, or only slightly more proofing than traditional instances of typeface families. A font with six weights needs a few hundred pages composed, different combinations of glyphs that need to be seen to be tested during a font family’s design iteration, eventually leading to specimens of what the font is designed to do best, to make people want to use it for that or whatever they see in the font family.

But complex variable fonts can also be made that overwhelm traditional proofing, and proofing any variable font expressly made for animation, by definition requires animated proofing. So, this paper explores how to provide a proofing platform for variable fonts using CSS and video to compact and offer presentation of proofs and specimens of fonts, how such proofs could be used, and what the benefits are to be able to present as compact and portable a “view” as possible, of one variable font.

That is not to say that this development could not be applied by Authoring in some other environment that outputs CSS, Nor is it limited to a single variable font if multiple variable fonts need to be proofed together, or if variable and non-variable fonts need to be proofed together.

This paper also is content to demonstrate the issues for Black and white Latin typefaces intended for all sizes and languages, which is not to say that this development could not be applied to fonts of other colors, scripts or for more specialized typeface designs.

I. How to provide a proofing platform for variable fonts using CSS.
  A. Assets
    1. Variable font

      a. Glyphs
        i. Local character set, i.e. user’s input repertoire
        ii. Glyph repertoire, of the font
          ii1.glyph group space
          ii2.glyph space
           ii2a.subglyph space

      b. Style roster   
        i. Registered axes & and stored instances
             Opsz, 1/72 inch
             Wght, os/2 100-900
             Wdth, os/2 25%-200%
             Slnt, degrees
             Ital, feature-like
        ii. Custom axes & stored instances
              Parametric (figurable), a value Per em definition & range
              A stored instance      
              Visualometric (fishable), values appearance
      
       c. Feature roster

       d. Design space, is the total stylistic range of the variable font implied by the axes.

     2. Composition modules 
      a. Text formats, per style
        i. Glyph, Glyph group, Glyph Repertoire
        ii. Glyph(s) in context, nnpnonopoo
        iii. Style in use. The quick brown fox
        vi. Style(s) in context, in use among the family
      b. Text “runtons”, code modules for layout of text runs.
        i. Run maker, 
           i.padder, Takes a glyph list and adds glyphs/spaces beside each glyph
           ii.Uses predefined runs
           iii. Synthesizes runs to fit for language, size, and length.
        ii. Size munch, determines text size, 
           i. absolutely, input in points/pixels
           ii. Relative, to page ht, body in ems
        iii. Linespacer, formulates linespacing by linelength
        iv. Letterspacer, line or ppg fit to width, tracks and kerns proportionally, manages word space.
        v. Tabulator, uses tabular width glyphs to compose test tables.
        vi. Hyphenator, collects hyphenation dicts of supported lang., sets per language hyphenation rules
        vii. Backgrounder, adjusts style for particular color/rendering cases
        viii. Script stalker, adjusts style for inter-script interactions.
        is. Style walker, directs proofs through Vars with more than one style of a given wght, wdth, opsz.
        x. Effects speccer, applies ranges of text effects to runs of a style, e.g. dropshadow, confetti
        xi. custom, feature or other style-specific run composition.

There are the Interesting possibilities

The video, and the portal displaying the video to the user are not dependent.

A css variable font movie is searchable and presentable for the usual things like glyphs, words and,phrases, as well as axes, instances

controls to examine individual frames go forward backwards speed up and slow down not frame dependent.

Outlines: Quadratic Path Directions

In these styles the clockwise path direction of the /degree is different from the default Regular.
RobotoExtremo wdthmax
RobotoExtremo opsz18-wghtmin-wdthmin
RobotoExtremo wdthmin
RobotoExtremo opsz18wght700wdthmin
RobotoExtremo wghtmax

In this one style the contour and path direction of /ordmasculine differs from the other masters.
RobotoExtremo wghtmax

Build with opsz-default to opsz-min only

Since the fonttools instancer doesn't yet support clipping axis ranges, I'd like to request a build that only builds the design space from opsz-default to opsz-min. This will be helpful to show that 'non corner master' design spaces can be useful, with minimal filesize, with OT 1.8 :)

Ideally this will be part of the CI build process, so that its continually available as the glyph set and other axes are built out.