Closed josescaglione closed 4 months ago
Overall the region
+ handwriting style
(being the latter either historical, formal or geographic) sounds good and follows what was previously discussed.
However, some considerations would be needed:
fvar
instances in VFscc @davelab6, @chrissimpkins
And possible Guidelines or Dotted for special versions
Would any of the versions require an axis control in the VF? (Refer to the Guideline Opacity axis proposal for context.)
If yes, please be sure to familiarize yourself with the Axis Protocol and submit a new Axis proposal issue to the googlefonts/axisregistry issue tracker to add them to the list of necessary axes introduced by the font.
Overall the
region
+handwriting style
(being the latter either historical, formal or geographic) sounds good and follows what was previously discussed.However, some considerations would be needed:
[ ] Paying attention to nameID 6 length Please clarify what you mean here. What is the limit?
This is our current spec for unsupported styles for static fonts I believe we are ok in this sense.
And our current spec regarding
fvar
instances in VFs You seem to be missing a weight in your table. Our structure is Thin 100 Extralight 200 Light 300 Regular 400
is this ok?
I've just noticed the above quoted text includes some answers to my previous comment.
Please clarify what you mean here. What is the limit?
According to the OT Spec
When translated to ASCII, the name string must be no longer than 63 characters and restricted to the printable ASCII subset, codes 33 to 126, except for the 10 characters '[', ']', '(', ')', '{', '}', '<', '>', '/', '%'.
Ensuring this would be particularly important for the static fonts.
I believe we are ok in this sense.
It seems ok regarding unsupported styles. However, the first tested font is reporting a Fail related to a not allowed underscore.
The common hyphen -
is not allowed also. We should probably need to use AUSNSW
or FRAtraditional
in these cases. I'll need to confirm this.
fvar
instancesYou seem to be missing a weight in your table. Our structure is Thin 100 Extralight 200 Light 300 Regular 400
The current VF (fonts/variable/Playpen-VF.ttf) in the lang-build
branch at commit a164269
is reporting a FB Fail complaining about the current fvar
instances included:
The common hyphen
-
is not allowed also. We should probably need to useAUSNSW
orFRAtraditional
in these cases. I'll need to confirm this.
After revision today, it was decided set the Family Name using only spaces. E.g. Playpen AUS NSW
We took the Australian Education families in the catalog, such as Edu NSW ACT Foundation, as a reference for these types of cases.
Dave created an alternate spreadsheet with the name schema. Please take it into consideration
We updated our fon reference spreadsheet HERE
In the spreadsheet, the 3-letter code for Portugal is defined as PRT
, however, the produced fonts are using POR
.
Should PRT
be used instead? Left a note also in the spreadsheet.
yes, the right code is PRT so there is a typo in the code
Per recent discussions, Tobias confirmed today that we are good to change this project from Playpen
to Playwrite
, to reduce the observed confusion mixing up these fonts with Playpen Sans; the "sans" is still OK in that family as it is unconnected, and makes slight reference to Comic Sans ;)
Tobias also asked if we can assess the children-family names' lengths, and the establish max name length (there's a fontbakery check in the univeral profile iirc), and to use unabbreviated names where possible: Eg, Argentina was proposed in the sheet I started as Playpen ARG
and would now be proposed as Playwrite Argentina
.
Per recent discussions, Tobias confirmed today that we are good to change this project from Playpen to Playwrite, to reduce the observed confusion mixing up these fonts with Playpen Sans;
Happy to hear this!
use unabbreviated names where possible: Eg, Argentina was proposed in the sheet I started as Playpen ARG and would now be proposed as Playwrite Argentina.
Doubtful about this. Even though using coded abbreviations may not be ideal, it is still consistent. The 3-letter code used is descriptive and clear enough to identify the country being referred to. Whereas "where possible" implies that in the cases it is not, it would require leaving some models with the code, and others unabbreviated, which would not be consistent, making it harder to communicate and for users to understand the differences within the system.
I'll use your spreadsheet to better asses this.
Sounds good
Hi all, before switching I would like to mention something I found immediately when writing the name. Autocorrector is trying to switch to PLAYWRIGHT and the search engine says this:
I am not sure this is an issue at all but wanted to make sure you were aware of it.
Autocorrector is trying to switch to PLAYWRIGHT
I agree that will be a little bit annoying for teachers writing documents that specify the family name, but I would hope that they are able to comprehend the pun and add the name-word to their personal spell checker dictionaries; or for readers of such documents to recover from the mistake if the misspelled (correctly spelled ;) name does occur in these docs.
and the search engine says this:
But once we release the family, I think it will still show "did you mean", but our specimen page will be the first result, and all is well
But once we release the family, I think it will still show "did you mean", but our specimen page will be the first result, and all is well
I agree especially with this. And coming to the pun, it is always about the context, so within the education context, Playwrite
makes complete sense :)
Moving ahead with the change. Many thanks!
Following the above, please change the repository name.
The repository name has already been renamed to Playwrite.
Thank you
I believe we can close this issue as well
Since the schema for using abbreviations is still being revised, I will keep it open until we reach a final conclusion.
During our meeting today, we discussed the following:
Ornate UC
is needed. Could it be Ornate Capials
? Instead of "Ornate Upper Case", to keep it as short as possible.PlaywriteAustraliaNSW
We will wait for a final decision then
Regarding the wording for the descriptive variants, @davelab6 already used Ornate Caps
in the spreadsheet. Let's use the highlighted names in that column of the spreadsheet.
No problem. Once you make a final decision we will apply all changes .
Sure!
Hi, just a friendly reminder, we need a decision about this as soon as possible
This is currently under extensive revision. We are running several installations and usage proofs under different environments to test the font performance with different name lengths. We need to finish this tests before reaching a definitive conclusion.
So far only the variants are pending a final definition.
@josescaglione
There is a Playwrite_ZA
folder under the fonts-models
directory, to which country does it belong?
Also, the Switzerland CH
model still needs to be included
@vv-monsalve ZA is for South Africa. (I thought it was a typo but it's not).
@casasin Ah, ok, I see now it replaces the old ZAF
. Thanks
Hi @casasin. Before running a new QA checks round, are the fonts included in 228074e
the most up-to-date? Or do you anticipate there will be another push today?.
Are you keeping the previous 3-char abbreviated fonts for any reason?
@vv-monsalve : 228074e
is the last push with two letter country codes. Three letter abbreviated fonts were removed in 276ab9b
. Weren't they?
Okay, thanks I'll proceed with that commit fonts.
Weren't they?
Nope. They all are still there.
Nope. They all are still there.
I can't see them when listing the "fonts-models" folder. How should I proceed?
@vv-monsalve they show up in the QA branch but not in Lang-build
I can confirm now that there are not longer the 3-char version in the Lang-build branch.
The only remaining open question related to naming would be related to the Guidelines version. However, I'm closing this here and will reopen or open a new issue to discuss when the time comes.
There are two questions still open. Taken from the Handriting Families Name spreadsheet
Original comments
This model serves to Private schols only. We cannot produce a public school one because it is a regular sans serif font and therefore outside our scope. I wonder if we should somehow specify it is for private schools. this is a Modern cursive, The other model is a typeface, closer to a print model. Maybe we should do "Modern"?
Playwrite ES Ornate
to Playwrte ES Deco
to localize the name Let's keep the syntax in sync with the abbreviation (and e.g. the CamelCased usWeightClass in OT) SemiJoined
cc @davelab6
@davelab6, @chrissimpkins, we still need to resolve the above three cases.
After private conversations with Dave, Chris, and José, the above boxes were ticked.
Some other decisions made were:
Traditionnelle
and Tradizionale
.Playwrite Germany Vereinfachte Ausgangsschrift
We updated our fon reference spreadsheet HERE
We are proposing the following family naming scheme for revision and approval
Family names must identify and represent each region or handwriting style, be as consistent as possible, and be within reasonable length limits. One of the issues is that the differences from model to model in a given country can be historical, formal, or geographic. We decided to use local nomenclature for geographic or model naming when possible, and english suffixes for other cases.
So: Playpen + [3-letter country code] + suffix where necessary
Some examples Playpen BRA Playpen AUS NSW Playpen HRV Lefthand Playpen FRA Traditional
Regarding style name the obvious ones are Thin Extralight (or is it ExtraLight) Light Regular Italic where appropriate And possible Guidelines or Dotted for special versions
Please share your comments.
ps. The number of families in the system is now 46