[Introduction] 'Making the Raisins in the Bun'

[Kalapi Gajjar-Bordawekar]

Hello everyone,

I'm Kalapi, a Typeface Designer and Font Engineer from India. 

I'm a part of a small team of external developers working in collaboration with the Google Fonts team to improve the quality and general usability of the fonts on the directory.

This thread will act as a log describing my day-to-day work effort and help me keep up to date with my schedule and milestones. My total time on this project will be divided 75/25 between font production and design updates respectively.

The font production part will include the following:  

(1) Planning a systematic development workflow 

(2) Configuring character sets (as already mentioned by Alexei)

(3) Porting all FontLab, FontForge, RoboFont, FontCreator, Fontographer, etc. sources to Glyphs 2.3

(4) Creating GitHub repositories for projects not already on the platform yet

(5) Checking all projects for coverage against said character sets and expanding ones that don't offer full support

(6) Supporting other team members with technical issues and design reviews. 

(7) Quality Assurance Engineering

(8) And last but not the least, testing, testing, and more testing! :)

The design updates will include working with typefaces which we're referring to as 'The Raisins' (ping Jacques for the origin story). These are families from within the library which we view as having a high potential of being successful by applying strategic design updates. These updates will deal with things like increased language and typographic support, spacing and kerning, technically superior outlines, design changes (where necessary), and expanding weights and styles (where required).

Please feel free to share your suggestions, opinions, and complaints when and where you feel the need to. I look forward to learning from and contributing to this community!

See you around!

Kalapi

P.S.: The log will start after this message. 

[Kalapi Gajjar-Bordawekar]

28 June 2016. Bangalore, India.

1. Admin

a. First Google Hangouts meeting after NYC summit:

This was a planning meeting. Dave asked us to create a deck for our first scheduled Raisin project which he will present to Google managers on Thursday. The deck should include a brief look at how we intend to update the font.

2. Production  

a. Character Sets:

Alexei translated all the character set data from the Google Sheets file we worked on during the summit in New York into '.nam' files as well as Glyphs Filter list files. He then uploaded these files to a newly created repository on GitHub. I reviewed these files and opened an issue to list the changes I found (Note: because the original repository has now been deleted, you can find the issues listed in this PDF).

3. Design Updates:

a. The Raisin Project:

The first Raisin project I have chosen to work on is Alfa Slab One designed by my good friend and DaltonMaag colleague José M Solé. It is in the top 20% of fonts with the highest views. It is based on William Thorowgood's 6-Line Pica Egyptian cut in the early 19th century in England and used primarily as a display typeface.

I sent José an email seeking his permission to work on updating and extending the typeface. I also asked him to send me the latest sources. Within an hour I received his permission followed by the sources later in the day in the form of a GitHub repo. The sources are a quick and dirty conversion from FontLab Studio using the 'Glyphs Export' FontLab script provided by Georg Seifert which you can find here.

4. Next Steps

a. Iron out all problems/inconsistencies in the 'GF2016-Glyph-Sets' repo.

b. Create deck for Alfa Slab One.

That's all!

Kalapi

[Kalapi Gajjar-Bordawekar]

29 June 2016. Bangalore, India.

1. Production  

a. Character Sets:

It was determined that the best way to go about organising the '.nam' and filter lists files was to add them directly under 'google/fonts/tools/encodings' instead of using a separate repo. Alexei migrated the files after merging my changes from yesterday and added them in the aforementioned location. You can find them here.

I reviewed the files further and opened an issue requesting changes in the formatting and content of the 'README.md' file.

2. Design Updates:

a. The Raisin Project:

I completed the Alfa Slab One deck. You can access it here. If you have anything to add, please leave a comment. Thanks!

3. Next Steps

a. [Production] Determine how many glyphs in every set need to be 'drawn' and how many can be made from components.

Thats all for today!

Kalapi

On Thursday, 30 June 2016 08:38:34 UTC+5:30, Kalapi Gajjar-Bordawekar wrote:

[Kalapi Gajjar-Bordawekar]

30 June 2016. Bangalore, India.

1. Admin

a. We had a 2-hour hangout today where we discussed everyone's 'Raisin' decks and production workflows.

2. Production  

a. Character Sets:

I worked on determining how many characters/glyphs in the entire character set are either 'drawn', 'composites', or 'either' (depending on the context, these could be either outlines or composites). I created a 'README.md' file containing a brief summary of the data I collected which Dave incorporated directly into the readme file for the 'GF 2016 Glyph Sets' sub-directory (found here).

3. Next Steps

a. Trail run of a one-day expansion project. More refinements in the character sets.

Cheers,

Kalapi

[Kalapi Gajjar-Bordawekar]

1 July 2016. Bangalore, India.

1. Admin

a. We had a 2-hour hangout today where we discussed the one-day font development/expansion sprint with regards to our workflow.

2. Production  

a. Design/Production Sprint:

I was assigned to expand Anton (GitHub repo) from it's basic 227 glyphs to the Plus character-set. I wasn't able to complete the full production since I had too little time (which was one of the tests of the sprint).

3. Next Steps

a. Complete the Anton expansion/production and push to repo. Next week is 'expansion week' which means three more expansion sprints!

Cheers,

Kalapi

On Sunday, 3 July 2016 10:06:00 UTC+5:30, Kalapi Gajjar-Bordawekar wrote:

30 June 2016. Bangalore, India.

1. Admin

a. We had a 2-hour hangout today where we discussed everyone's 'Raisin' decks and production workflows.

2. Production  

a. Character Sets:

I worked on determining how many characters/glyphs in the entire character set are either 'drawn', 'composites', or 'either' (depending on the context, these could be either outlines or composites). I created a 'README.md' file containing a brief summary of the data I collected which Dave incorporated directly into the readme file for the 'GF 2016 Glyph Sets' sub-directory (found here <https://github.com/google/fonts/blob/master/tools/encodings/GF%202016%20Glyph%20Sets/README.md>).

[Kalapi Gajjar-Bordawekar]

4 July 2016. Bangalore, India.

1. Expansions 

a. I completed the 'Anton' font expansion and pushed the updates to my fork of the project. I've marked the Vietnamese glyphs purple to help Nhung identify access them quicker. In this case I drew the 'hookcomb' and the 'horncomb' but i'm sure Nhung will update them :) 

2. Next Steps

a. Start the next sprint to expanding Vernon Adams' 'Bevan' typeface.

b. Ask Dave about hosting Vernon's projects on 'https://github.com/googlefonts'

c. Some questions for the team with regards to the character set.

* Should we add 0x02BC (apostrophemod) to the Plus set since it's used in 'napostrophe'. We have included it the Pro set.

* Not all fonts require '.case' alternates of the below marks (dotbelowcomb.case, dieresisbelowcomb.case, commaaccentcomb.case, cedillacomb.case, ogonekcomb.case, brevebelowcomb.case, macronbelowcomb.case). Maybe we make them optional but keep them in the Plus set and make a note somwhere of it.

* Similarly not all fonts require 'zero.zero' (slashed zero). While this may be obvious I think we should document it somewhere (maybe in the Wiki feature on GitHub?).

Cheers,

Kalapi

[Kalapi Gajjar-Bordawekar]

5 July 2016. Bangalore, India.

1. Admin

a. We were on a Hangout today to discuss project progress and discuss general workflow related questions. Also, all questions from yesterday's log were resolved. Anton and Bevan are now on the GoogleFonts 'organisation' account.

1. Expansions 

a. I completed the 'Bevan' font expansion and pushed the updates to my GitHub account. 

2. Next Steps

a. Send an update to Nhung informing her that Anton and Bevan are ready for her to take over.

b. Prepare 'Anaheim' for expansion.

c. Formalise the workflow checklist and upload it to the spreadsheet.

Cheers,

Kalapi

[Alexei Vanyashin]

2. Next Steps

a. Start the next sprint to expanding Vernon Adams' 'Bevan' typeface.

b. Ask Dave about hosting Vernon's projects on 'https://github.com/googlefonts'

c. Some questions for the team with regards to the character set.

* Should we add 0x02BC (apostrophemod) to the Plus set since it's used in 'napostrophe'. We have included it the Pro set.

* Not all fonts require '.case' alternates of the below marks (dotbelowcomb.case, dieresisbelowcomb.case, commaaccentcomb.case, cedillacomb.case, ogonekcomb.case, brevebelowcomb.case, macronbelowcomb.case). Maybe we make them optional but keep them in the Plus set and make a note somwhere of it.

* Similarly not all fonts require 'zero.zero' (slashed zero). While this may be obvious I think we should document it somewhere (maybe in the Wiki feature on GitHub?).

Nice suggestion, Kalapi. I have implemented this in the latest fix. [ Browse files link ]

[Kalapi Gajjar-Bordawekar]

6 July 2016. Bangalore, India.

1. Production

a. I started working on the 'cleanup production workflow' document in parallel with expanding Anaheim to accurately record steps and times. I'm trying to figure out whether to add this as an additional sheet in a spreadsheet document or host it within the 'googlefonts/gf-docs' repo.

2. Expansions

a. I completed updating 'Anaheim' to the Plus character set (except Vietnamese, but that is obvious!). The fork on my repo is now updated and Nhung can start working on it.

3. Next Steps

a. Expand another font family (don't know which one yet)

b. Complete the cleanup workflow doc

4. Questions

a. @Team - Would it be helpful to start a separate master thread 'GoogleFonts Update 2016' where the core team and community can ask and answer workflow/tools/design related questions?

b. @Alexei - I realised that since we've included the Unicode fractions ¼ (0x00BC) and ¾ (0x00BE) in the Plus set, it would be useful to include the 'foursuperior' character (0x2074) which is already included in most fonts because it is used as a component in the fractions. :|

c. @Dave - Have you assigned other fonts for me to work on for Thursday and Friday?

Cheers,

Kalapi

[Alexei Vanyashin]

b. @Alexei - I realised that since we've included the Unicode fractions ¼ (0x00BC) and ¾ (0x00BE) in the Plus set, it would be useful to include the 'foursuperior' character (0x2074) which is already included in most fonts because it is used as a component in the fractions. :|

Good point, Kalapi. I will add this.

[Jacques Le Bailly]

Yesterday I did some bugfixing on VT323.

Today I will continue working on the expansion SigmarOne fron Vernon Adams. 

Dave, are you OK if I expand it to GF Plus ?

Tomorrow I will finish SigmarOne

[Dave Crossland]

On 7 July 2016 at 03:28, Jacques Le Bailly <fonth...@gmail.com> wrote:

Dave, are you OK if I expand it to GF Plus ?

Yes, Plus is good :) 

[Kalapi Gajjar-Bordawekar]

7 July 2016. Bangalore, India.

1. Production

a. I made a local copy of the remote branch 'GF2016-fix' (which has since been deleted) on the google/fonts repo and tried to fix the merge conflicts in pull request #302.

2. Design Updates

a. The Raisin project

Since I hadn't been assigned another 'expansion' class family, I continued working on the refinements of Alfa Slab One. Today's day was spent largely figuring out what fell inside the scope of the changes mentioned in the deck.

3. Next Steps

a. Expand another font family. If nothing is assigned, continue work on Alfa Slab One.

Cheers,

Kalapi

[Kalapi Gajjar-Bordawekar]

8 July 2016. Bangalore, India.

1. Admin

a. I was in the weekly review call today where we discussed my cleanup check-list. We also discussed the problems Jacques was facing with regards to clipping and vertical metrics in Sigmar One and I was assigned with the task to work on a vertical metrics recommendation. 

1. Design Updates

a. The Raisin project

I continued working on Alfa Slab One today. I'm still working on refining the specifics of the scope but started working on fixing the lowercase (i'll start posting images from next week as per Dave's recommendation). 

2. Next Steps

a. Publish the cleaup cheklist on the spreadsheet.

b. Start researching vertical metrics requirements.

Cheers,

Kalapi

[Kalapi Gajjar-Bordawekar]

11 July 2016. Baroda, India.

1. Admin

a. I wrote the two overdue log entries for 7th & 8th July and caught up with all the comments/issues on GitHub and here on the discussion group. I also had a brief chat with Dave about how I would approach testing the vertical metrics.

2. Production

a. I did not publish the cleanup checklist today. I need to organize it a bit better before I upload it tomorrow.

b. I started experimenting with the vertical metrics on files from Nhung's fork of Libre Franklin. I'll share more details on Wednesday when i'm done testing in all environments. Here is a litle sneak peek of the testing: 

I 'redacted' Libre Franklin and exagerrated the 'y' extremas to test clipping. The tallest outline here (third 'letter') is 2012 units tall and -1300 units deep (tested on Google Chrome 51.0.2704.103 (64-bit) running on OSX 10.9).

2. Next Steps

a. Publish the cleaup cheklist on the spreadsheet.

b. Vertical metrics: tests, test, test!

Cheers,

Kalapi

[Dave Crossland]

Thanks Kalapi. I recommend using a sharp spike rather than a rectangle so that even a few pax of clipping is easily visible.

[Kalapi Gajjar-Bordawekar]

19 July 2016. Bangalore, India.

Preface:

Apologies for not being able to post updates after 11 July. The logic board on my MacBook Pro failed me and since I wasn't in Bangalore diagnostics by the authorised service centre took well over a day. Once I knew that the board could not be fixed, I went to the store to buy a new one and the one I wanted wasn't in stock. I ordered it anyway and got it delivered next evening (14 July) after which I spent two full days on system re-configuration, migration, and deployment. 

The following updates are for 18/7 and 19/7:

1. Admin

a. Caught up with everyone's project updates on the discussions group. 

b. Had a chat with Dave re. operations status

2. Production

a. Cleanup Checklist

I've now uploaded the checklist to the 'Fonts mini-workshop[...]' sheet under 'Kalapi's Cleanup Checklist'. I don't think this is public access yet but here's a screenshot. Please add any recommendations you may have:

b. Vertical Metrics

After through testing I found that none of the latest apps clip outlines.  The only exception to this is Windows-based apps (which use the DirectWrite API e.g. Mozilla's FireFox) which depend on the OS/2 winMetrics correctly configured to match the y-dimensions of the tallest and the deepest black bits in the font, which if not set correctly will result in clipping (the following image shows Libre Franklin Vietnamese with the original metrics on top and the new metrics on the bottom; Microsoft Word 2016 on Windows 8.1 VM running on Parallels Desktop 11).

Thus I propose the following scheme for vertical metrics:

OS/2 sTypoAscender: highest extent of capital 'H' or lowercase ascender 'h', whichever is taller

OS/2 sTypoDescender: Font UPM - sTypoAscender

OS/2 usWinAscent: == yMax (head table)

OS/2 usWinDescent: == yMin (head table)

hhea typoAscender: == usWinAscent (for cross platform compatibility)

hhea typoDescender: == usWinDescent (for cross platform compatibility)

In the following screenshots you can see the comparison between the original approach (i.e. all metrics == OS/2 typo metrics) and the new approach (original on top; new below).

- OSX 10.11 (El Capitan)

Google Chrome

Mozilla FireFox

Apple Safari

- Microsoft Windows 8.1

Google Chrome

Mozilla FireFox

Microsoft Internet Explorer

3. Next steps

a. Create a MarkDown document for explaining the new VM scheme

b. Start work on an expansion project (don't know which one yet).

4. Questions

a. What do all of you think about the new approach for vertical metrics?  b. Is there anything obvious i'm overlooking/missing/breaking?

[Khaled Hosny]

On Tue, Jul 19, 2016 at 09:55:49PM -0700, Kalapi Gajjar-Bordawekar wrote:
> hhea typoAscender: == usWinAscent (for cross platform compatibility)
> hhea typoDescender: == usWinDescent (for cross platform compatibility)

‘hhea’ metrics should match ‘OS/2’ typo metrics as they are often used
for line spacing (on MacOS and in FreeType).

Regards,
Khaled

[Kalapi Gajjar-Bordawekar]

Hi Khaled, 

Nice to meet you and thanks for the reply! :)

Because we can only sort-of control how type designers (who submit fonts for the directory) will deal with dimensions/proportions of letterforms, we need to make sure that the default setting isn't too tight. Usually, the Latin capital letters are drawn between 700-800 units high (on 1000 UPM). Now as you said, Mozilla FireFox uses the hhea for line height via FreeType so when I tried your approach on Libre Franklin I got the following result:

1. The original metrics which are 125% of UPM and equal in all tables:

2. The new metrics as I suggested earlier:

3. And, the new metrics plus setting hhea to typo metrics:

In my opinion, the default line-height in the third example is too tight and it might be better to provide more space rather than less since the line-height can be easily adjusted using the CSS property.

What do you think?

Best,

Kalapi

[Alexei Vanyashin]

Hi Kalapi,

Welcome back (to our humble show)!
Number 3 is definitely too tight.

Does Glyphs calculate the metrics as you propose automatically, or is there need to add custom hhea and winAscent parameters to each instance?

--
You received this message because you are subscribed to a topic in the Google Groups "Google Fonts Discussions" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/googlefonts-discuss/W4PHxnLk3JY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to googlefonts-dis...@googlegroups.com.
To post to this group, send email to googlefon...@googlegroups.com.
Visit this group at https://groups.google.com/group/googlefonts-discuss.
To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/f1984957-21d4-4954-a1ff-97ebd0146650%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dave Crossland]

Hi

Thanks Kalapi and Alexei for looking into this :) 

On 20 July 2016 at 12:19, Alexei Vanyashin <a...@cyreal.org> wrote:

Number 3 is definitely too tight.

I agree. Pablo, what do you think about Number 2?

 

Does Glyphs calculate the metrics as you propose automatically, or is there need to add custom hhea and winAscent parameters to each instance?

Curiously https://www.glyphsapp.com/tutorials/vertical-metrics doesn't say what the automatic calculation is. 

One potential option is to stick with Number 1; this will mean on the downside Vietnamese glyphs are clipped in Windows Firefox, but on the upside that there is no shift in position or scale of the existing Latin glyphs, and no clipping on other browsers (AFAIK)

--

Cheers
Dave

[Khaled Hosny]

OK, lets first review what each setting is about:

* OS/2 Win metrics: text clipping, any part of the text outside
the Win metrics will be clipped.
* OS/2 Typo metrics: line spacing, but you need to set also the
“USE_TYPO_METRICS” fsSelection bit to make sure applications will use
it.
* hhea metrics: line spacing as well, some applications will prefer it
over OS/2 Typo metrics (MacOS, FreeType).

So for consistent line spacing OS/2 Typo metrics and hhea metrics must
be identical. To avoid clipping, OS/2 Win metrics should be at least
the font bbox (for some fonts or scripts where glyphs are stacked
vertically, it will need to be even bigger than the bbox).

This is all in ideal world, but the main problem is that some
applications (notably on Windows) will use OS/2 Win metrics for line
spacing, so the convention was to set all the three metrics identically.
My original proposition was to ignore those buggy applications (no Web
browser suffers from this AFAIK) and go with the ideal setting.

Regards,
Khaled

On Tue, Jul 19, 2016 at 11:44:06PM -0700, Kalapi Gajjar-Bordawekar wrote:
> Hi Khaled,
>
> Nice to meet you and thanks for the reply! :)
>
> Because we can only sort-of control how type designers (who submit fonts
> for the directory) will deal with dimensions/proportions of letterforms, we
> need to make sure that the default setting isn't too tight. Usually, the
> Latin capital letters are drawn between 700-800 units high (on 1000 UPM).
> Now as you said, Mozilla FireFox uses the hhea for line height via FreeType
> so when I tried your approach on Libre Franklin I got the following result:
>
> 1. The original metrics which are 125% of UPM and equal in all tables:
>

> <https://lh3.googleusercontent.com/-WK1XBv6gx7U/V48bimnBOMI/AAAAAAAABlA/X8p8v2RcKMIMG26bykhEoGzBOjjmvsqmwCLcB/s1600/Screen%2BShot%2B2016-07-20%2Bat%2B11.55.58%2BAM.png>

> 2. The new metrics as I suggested earlier:
>

> <https://lh3.googleusercontent.com/-zHhQi17e07w/V48b65GpeEI/AAAAAAAABlE/1JMFwvcaPRwYue2K895rIJ3t-TMlZ-aOACLcB/s1600/Screen%2BShot%2B2016-07-20%2Bat%2B11.56.03%2BAM.png>

>
> 3. And, the new metrics plus setting hhea to typo metrics:
>

> <https://lh3.googleusercontent.com/-Gr4rPrEwDHU/V48cG8NA3zI/AAAAAAAABlI/pA8_fJY0JjIqNkAADiXcy8itksDBsdUyACLcB/s1600/Screen%2BShot%2B2016-07-20%2Bat%2B11.56.06%2BAM.png>

[Khaled Hosny]

So my suggestion would be that:

1) Set OS/2 Typo and hhea metrics to the values that gives the desired
line spacing for *non Vietnamese text*.
2) Set OS/2 fSelection “USE_TYPO_METRICS” bit.
3) Set OS/2 Win metrics to big enough value to avoid any clipping.

Then test the font with this setup and see if there are any problems
with any of the major browsers.

The above setup will mean that by default Vietnamese line spacing will
be too tight and users of Vietnamese text will need to explicitly set
CSS line spacing to a better value. This is not ideal, but it is a
better trade-off IMO than scaling down the accents.

Alternatively, if we are fine with looser line spacing by default, then
we can change 1) to give better default line spacing for Vietnamese
text.

Regards,
Khaled

[Dave Crossland]

Hi Khaled

There seem to be missing from your analysis (a) linegap values and (b) this "all ink within 125% of UPM" rule that Pablo and Eben have proposed. 

You make a good point here:

> To avoid clipping, OS/2 Win metrics should be at least
> the font bbox (for some fonts or scripts where glyphs are stacked
> vertically, it will need to be even bigger than the bbox).

 

Is there any yet any program that will calculate the max bbox from stacking? 

I suppose ǹoth̗̦̳̳in̴g ̇ͫ̐ca̢ͬn be done about unicode stacked combining characters....

But perhaps we could account for the combinations specified by OpenType layout?

Cheers
Dave

[Dave Crossland]

On 20 July 2016 at 13:33, Dave Crossland <da...@lab6.com> wrote:

There seem to be missing from your analysis (a) linegap values and (b) this "all ink within 125% of UPM" rule that Pablo and Eben have proposed. 

I chatted with Kalapi about this and perhaps this is implicit in your analysis: the typo and hhea metrics are 125% of the UPM, and linegaps are 0?

[Khaled Hosny]

On Wed, Jul 20, 2016 at 01:33:41PM -0400, Dave Crossland wrote:
> Hi Khaled
>
> There seem to be missing from your analysis (a) linegap values and (b) this
> "all ink within 125% of UPM" rule that Pablo and Eben have proposed.

I always set line gap to zero and just forget about it, but others might
have different preferences.

> You make a good point here:
>
> > To avoid clipping, OS/2 Win metrics should be at least
> > the font bbox (for some fonts or scripts where glyphs are stacked
> > vertically, it will need to be even bigger than the bbox).
>
> Is there any yet any program that will calculate the max bbox from
> stacking?

I don’t know any.

> But perhaps we could account for the combinations specified by OpenType
> layout?

I was just thinking about a way to automate this the other day (it is a
common issue in Arabic since combining marks are always placed during
layout with no recomposed forms, so the font bbox does not account for
them). I think we can either have some text with common combinations,
pass it though HarfBuzz and calculate the maximum ink box of the text
after layout, or try to generate possible combinations from the layout
tables and do the above.

Regards,
Khaled

[Khaled Hosny]

If 125% UPM give the desired line spacing then yes, and yes 0 line gap.

Regards,
Khaled

[Dave Crossland]

Hi

On 20 July 2016 at 13:45, Khaled Hosny <khale...@eglug.org> wrote:

On Wed, Jul 20, 2016 at 01:33:41PM -0400, Dave Crossland wrote:
> Hi Khaled
>
> There seem to be missing from your analysis (a) linegap values and (b) this
> "all ink within 125% of UPM" rule that Pablo and Eben have proposed.

I always set line gap to zero and just forget about it, but others might
have different preferences.

OK :) So, my take on your recommendation is to set the typo and hhea metrics to 125% or so of the UPM, both linegaps to 0, and set the win metrics to something larger; this avoids repositioning/reflow for fonts using that standard already, and no one sees any clipping, but there is inconsistent rendering between browsers using Apple/freetype and Windows text rendering APIs; ie OSX, iOS, Android, GNU, and Chrome (on-all-platforms) will have 'good' default line spacing and no clipping, and MSIE/Edge/Firefox on Windows will have different line spacing (much taller?

 

And your Arabic fonts in Google Fonts today, are an example of this approach? 

> Is there any yet any program that will calculate the max bbox from
> stacking?

I don’t know any.

> But perhaps we could account for the combinations specified by OpenType
> layout?

I was just thinking about a way to automate this the other day (it is a
common issue in Arabic since combining marks are always placed during
layout with no recomposed forms, so the font bbox does not account for
them). I think we can either have some text with common combinations,
pass it though HarfBuzz and calculate the maximum ink box of the text
after layout, or try to generate possible combinations from the layout
tables and do the above.

That's a good iterative approach :)  

--

Cheers
Dave

[Khaled Hosny]

On Wed, Jul 20, 2016 at 01:48:41PM -0400, Dave Crossland wrote:
> Hi
>
> On 20 July 2016 at 13:45, Khaled Hosny <khale...@eglug.org> wrote:
>
> > On Wed, Jul 20, 2016 at 01:33:41PM -0400, Dave Crossland wrote:
> > > Hi Khaled
> > >
> > > There seem to be missing from your analysis (a) linegap values and (b)
> > this
> > > "all ink within 125% of UPM" rule that Pablo and Eben have proposed.
> >
> > I always set line gap to zero and just forget about it, but others might
> > have different preferences.
>
>
> OK :) So, my take on your recommendation is to set the typo and hhea
> metrics to 125% or so of the UPM, both linegaps to 0, and set the win
> metrics to something larger; this avoids repositioning/reflow for fonts
> using that standard already, and no one sees any clipping, but there is
> inconsistent rendering between browsers using Apple/freetype and Windows
> text rendering APIs; ie OSX, iOS, Android, GNU, and Chrome
> (on-all-platforms) will have 'good' default line spacing and no clipping,
> and MSIE/Edge/Firefox on Windows will have different line spacing (much
> taller?

AFAIK, Firefox on Windows using OS/2 Win metrics only if
USE_TYPO_METRICS is not set, and I vaguely remember that the other
Windows browsers do the same, but we need to double check this again.

> And your Arabic fonts in Google Fonts today, are an example of this
> approach?

Yes.

Regards,
Khaled

[Eben Sorkin]

I just noticed this topic coming up again.

The old rule was 125% of the UPM but at least with *browsers* the last time I did a check this limit was no longer in effect. 2 years prior to that you could rely on clipping occurring on the web - unless it was a single line! @ lines is where you saw the clipping.

So this change was a big deal and a very happy result.

So as a practical matter if you wanted to support Vietnamese on the web and you didn’t want to scale your font down you could actually change to 133% of the UPM in your vertical metrics (or whatever) with no clipping as long as you set hhea, os2 & typo values to the same 133% of UPM with zero linegaps. I could not find an upper limit at the time. So the the upper limit was "what’s practical” or “what makes typographic sense?".

I had been keen on knowing the answer to this for the sake of some Devanagari projects so that I could work out how best to handle stacked letters/signs in a single glyph.

I also did tests with adobe apps and they also seemed to play nice.

There were some windows apps that didn’t like this ( I don’t recall what ) but Office seemed to deal with it well.

I concluded that the limits now had more to do with typographic relationships and what looked reasonable than with the underlying tech.

It may be a good time to re-do the tests since mine were done at least 2 years ago which is ancient history in web time. We have also seen 2 editions of Windows since then etc.

Similarly the assumptions I was working with e.g. that web is #1 and major applications were #2 and the #3 random other apps were not going to drive our choices could be similarly reassessed.

I would be happy to re-test or to provide my test fonts to others to run tests. I am not 100% sure what timeline I can offer.

-e.

> --
> You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-dis...@googlegroups.com.

> To post to this group, send email to googlefon...@googlegroups.com.
> Visit this group at https://groups.google.com/group/googlefonts-discuss.

> To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/20160720175216.GE5021%40macbook.

[Dave Crossland]

On 20 July 2016 at 14:11, Eben Sorkin <eb...@eyebytes.com> wrote:

The old rule was 125% of the UPM but at least with *browsers* the last time I did a check this limit was no longer in effect.

Okay cool :) Thanks for clarifying! :)

I would be happy to re-test or to provide my test fonts to others to run tests. I am not 100% sure what timeline I can offer

Thanks for offering! In my mind there are 2 tests to be done:

Currently, almost all fonts in Google Fonts have all 3 metrics (win, typo, hhea) set to the y-direction ink bounding box ('ink box') and both linegaps set to 0. This policy was set by Raph back in 2011 and documented on the old Google Web Fonts wiki, archived at https://github.com/googlefonts/gf-docs/blob/master/VerticalMetricsRecommendations.md

As we update fonts made for US English to support European languages and Vietnamese, we’re inevitably drawing outside of the existing metrics, which tended to be around 125% of UPM, up or down. 

Therefore we’re looking at possible options for updating the vertical metrics:

1. Do nothing :) Leave the vertical metrics as they are, and draw outside them. We need to test if we still see cropping for Windows Firefox users when the font’s OS/2 fsSelection “USE_TYPO_METRICS” bit is set, or if we see cropping only when it is not. It seems that when we do see such clipping, no amount of CSS line-spacing can stop that, so we're considering other options. 

2. Update the vertical metrics using a new policy, where hhead and typo metrics are set to around 125% of UPM and both linegaps are set to zero, which in most cases means no change, but, change win metrics to the new ink box. Also we have a new definition of ink box, which in 2001 was the same as ‘head’ table yMin/yMax, but we should now account for how some glyphs are stacked vertically by unicode or opentype; we may need to write a small program that will calculate the ‘real world’ ink bbox by generating possible combinations from the layout tables to pass through HarfBuzz :) In this case, no-one will see any clipping, but we need to test browser consistency; it seems that most browsers using Apple/freetype (OSX, iOS, Android, GNU, and Chrome on all platforms) will have 'good' default line spacing and no clipping, but those using Windows’ text rendering APIs (MS IE/Edge, Firefox on Windows) will have different line spacing (much taller.)

3. Update the vertical metrics using the existing policy, where they are all the same. No-one will ever see any clipping, and line spacing is consistent across all browsers/platforms, but this will cause repositioning and reflowing for everyone, and most people will need to update their CSS, figuring out they should apply negative CSS line-spacing to get the same paragraph texture as before. The problem with this is that for fonts with a very tall ink box (like Latin-Arabic fonts) the line spacing becomes unusually tall, which is not ideal. 

So, the tests to be done next are about how the OS/2 fsSelection USE_TYPO_METRICS bit can effect use of the OS/2 Win metrics, and if its better to set those win metrics to clip (as in 1) or not (as in 2) or bite the bullet (as in 3.)

Kalapi has retired for today, but I hope he'll be able to test these before tomorrow morning NYC time :) 

 

--

Cheers
Dave

[Richard Fink]

As Eben said:

>I just noticed this topic coming up again.

If this is still an open issue. (And I think it should be, still.) I'd like to add something to this discussion. What has never been discussed, to my knowledge, is the range within which the basic Latin characters should fit within the EM square.

Vernon Adams and I had an exchange a few months before Vernon's terrible scooter accident about how much space out of the em square the basic letters should take up for maximum effect onscreen. (Use either 2048 upm or 1000 upm - it's the percentage (or ratio) that counts)

I was unhappy with the way Oswald was performing in TTFAutohint and I did a little research.

All of the screen fonts we've come to know over the years have their x-heights and cap-heights all fall within certain boundaries.

There is a floor and a ceiling.

Here are the fonts that ship with Windows with their x-heights and cap-heights at 2048 upm:

Arial 1062 1466

Calibri 956 1300

Cambria 956 1365

Candara 950 1302

Consolas 1004 1307

Constantia 927 1400

Corbel 950 1338

Courier New 866 1170

Georgia 986 1419

Impact 1327 1619

Lucida Console 1086 1283

Lucida Sans Unicode 1086 1480

Segoe UI 1024 1434

Tahoma 1117 1489

Times New Roman 916 1356

MS Trebuchet 1071 1465

Verdana 1117 1489

(I'm sure that if I checked the fonts that ship with Macintosh, they would fit within these parameters. Same, I think, if I checked the special order "system" fonts like  Clear Sans, Droid, Fira, Literata, Noto, Roboto, Roboto Slab, Ubuntu, and Ubuntu Mono. I haven't checked these yet, but I will be.)

There is a floor and a ceiling set so that at, say 10 px the text isn't too small, and yet there still seems to be room for all the necessary diacritics needed for expansion. We can call it the Goldilocks Zone where the x-heights and caps heights are not too high, not too low, but, for the particular design of the fonts, just right.  Now, I'm certain there's a reason for this that has to do with screen resolution and, perhaps, having to reconcile the needs of screen readability with the less stringent requirements of hi-res printing. 

 

At the time, I used Oswald to show Vernon the results of my findings. What I did was re-scale Oswald to fit better within the Goldilocks Zone and therefore more in line with the standard system fonts listed above. (John Hudson would be a good fellow to ask about this.)

(Fonts shipped with the Mac will yield similar results, I have no doubt and I'll be checking those also.)

So, what I'm saying is that 125% of something is meaningless unless you've set some kind of boundaries for what that something might be.

Without a Goldilocks Zone defined - without upper and lower boundaries beyond which certain features of the Latin set should not extend, I don't know how this is going to work 

The bottom line is that the fonts look better onscreen and are easier to Autohint if you stay within these limits. There are other virtues, too, but no point going into them here right now. 

If you're going to do this kind of fine-tuning, do it right, I say. And strongly suggesting a minimum x-height and maximum cap-height and re-scaling the font when necessary if it's been made beyond those boundaries, is the way to go 

Today you have 600+ families to contend with.  Don't wait until you have 2000.

I'm going to get out the samples I did for Vernon and our correspondence.  He SAW and acknowledged the superiority of my re-scaled Oswald.

If I can be of further assistance, let me know. I'll share info as I gather it. 

Richard Fink

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/409B54AB-44A2-42C6-A944-77FF8216BAAC%40eyebytes.com.

[Dave Crossland]

Hi kalapi

Since nhung is out this week please could you ensure all the fonts you worked on so far are completed to their appropriate glyphs sets, and test the v metrics as described above,  and then we can sync up in about 11 hours from now :)

If you manage to do all that, and be grateful if you could take a close look at fontbakery and get it running on 1 or more of your completed font projects :)

Cheers
Dave

[Kalapi Gajjar-Bordawekar]

First of all thank you Khaled, Eben, and Richard for your insights. Also, apologies for the long-ish post!

Test #1

After evaluating all the feedback I decided to perform more tests. The first test involved creating two versions of the current Libre Franklin family as follows for testing the effects of the fsSelection bit 7 useTypoMetrics on windows browsers:

1. Version1 (original): OS/2 sTypoMetrics == OS/2 winMetrics == hhea metrics

2. Version2: OS/2 sTypoMetrics and hhea metrics == Version1; OS/2 winMetrics == yMax and yMin respectively; and fsSelection bit 7 useTypoMetrics set

3. Version3: OS/2 sTypoMetrics and hhea metrics == Version1; OS/2 winMetrics == yMax and yMin respectively

Here are the screenshots for Test#1 (Note: tests are performed on Windows 8.1 Professional running on Parallels 11 for Mac. Chrome version: 51.0.2704.103 m; FireFox version: 47.0.1; Internet Explorer version: 11.0.9600.18350)

1. Mozilla FireFox

2. Google Chrome

3. Internet Explorer

Test Result summary:

In an earlier test I found that FireFox (Win) clipped the Version1 font because the ink/font bbox exceeded the OS/2 winMetrics calculations. I observed that Version2 solved this problem and maintained the original vertical flow of text because of the useTypoMetrics flag. Version3 while solving the problem of clipping changed the vertical flow of text because the line-height was calculated using the new winMetrics.

I also made sure to test all three versions on all Windows browser platforms (as seen in the screenshots above) and can confidently say that Version2 is the most consistent while maintaining the original line-heights.

Test #2

Here are the screenshots for Test#2 (Note: tests are performed on OSX 10.11 El Capitan running natively. Chrome version: 51.0.2704.106 (64-bit); FireFox version: 47.0.1; Safari version: Version 9.1.1 (11601.6.17))

1. Mozilla FireFox

2. Google Chrome

3. Safari

Test Result summary:

Similar test on browsers on OSX 10.11 (El Capitan). All versions are consistent.

Test #3

Here are the screenshots for Test#3 (Note: tests are performed on TextEdit (version Version 1.11 (325)) running on OSX 10.11 El Capitan running natively.

Test Result summary:

I performed these tests to check for clipping on OSX since Mac apps use the hhea values and the ink/font bbox exceeded the hhea values in Version1. I found that clipping occurred in the first line of text (closest to the menu on top) as seen in the first three screenshots, but when the hhea values were set to be equal to the winMetrics it solved this problem (screenshot 4). However, if there was an empty line at the very beginning then there was no clipping.

Conclusions:

When comparing the above results to the new scheme I proposed two days ago I see a few problems:

Problem 1: The 125% limit is obsolete but present in most fonts, creating a legacy vertical re-flow problem if new scheme is adapted.

Problem 2: If we add the useTypoMetrics flag requirement to the proposed scheme, the nature of the OS/2 sTypoMetrics calculations will ensure that the text in all environments is 'set-solid' (i.e. without sufficient line-height).

Therefore there are two possible routes we could take:

1) We continue using the original 125% OS/2 sTypoMetrics calculations and update only the winMetrics and the useTypoMetrics flag (as tested in Test#1 font Version2 and seen in screenshots in the same section) since this maintains line-heights and eliminates clipping on all browsers. However, it also keeps the obsolete 125% legacy.

2) We allow some shift in the vertical flow of text and use the following calculations:

OS/2 sTypoAscender: highest extent of capital 'H' or lowercase ascender 'h', whichever is taller

OS/2 sTypoDescender: Font UPM - OS/2 sTypoAscender

OS/2 sTypoLineGap: 250 (to compensate for the 125% legacy)

OS/2 usWinAscent: == yMax (head table)

OS/2 usWinDescent: == yMin (head table)

hhea ascent: == OS/2 sTypoAscender

hhea descent: == OS/2 sTypoDescender

hhea linegap: == OS/2 sTypoLineGap

Here are the screenshots for route 2 (Note: tests are performed on Windows 8.1 Professional running on Parallels 11 for Mac. Chrome version: 51.0.2704.103 m; FireFox version: 47.0.1; Internet Explorer version: 11.0.9600.18350; tests are performed on OSX 10.11 El Capitan running natively. Chrome version: 51.0.2704.106 (64-bit); FireFox version: 47.0.1; Safari version: Version 9.1.1 (11601.6.17))

1. Mozilla FireFox Win

2. Google Chrome Win

3. Internet Explorer

1. Mozilla FireFox Mac

2. Google Chrome Mac

1. Safari

Phew! Apologies again for the length of this email! Please let me know what you guys think!

Best regards,

Kalapi

[Kalapi Gajjar-Bordawekar]

20 July 2016. Bangalore, India.

1. Admin

a. Followed up on the discussions group with vertical metrics discussions.

b. Started writing a report on further experiments with v metrics.

2. Production

a. Tested the feasbility of using the 'useTypoMetrics' flag for equalising vertical metrics on all platforms.

3. Next Steps

a. Continue working on the report as in 1.b.

Cheers,

Kalapi

[Kalapi Gajjar-Bordawekar]

21 July 2016. Bangalore, India.

1. Admin

a. 1 1/2 hour hangout with Dave, Lasse, Marc, and Feliepe.

b. Completed report with conclusions on fSelection bit 7 tests/experiments.

2. Expansions

a. Continued work on Anton's Vietnamese set in Nhung's absence. 

These accents are too large! I need to compress horizontally.

3. Next Steps

a. Continue expanding Vietnamese for 'Bevan' and 'Anaheim'. Deadline Monday.

4. Questions

a. Comments/suggestions about new vertical metrics post please :)

Cheers,

Kalapi

[Kalapi Gajjar-Bordawekar]

22 July 2016. Bangalore, India.

1. Expansions

a. Continued extending Anton, Bevan, and Anaheim to Vietnamese so that Mark, Lasse, and Felipe can perform tests on Monday. 

2. Next Steps

a. Review FontBakery for the families mentioned above.

3. Questions

a. None ATM.

Cheers,

Kalapi

[Dave Crossland]

Hi

(Replying back on list)

On Jul 25, 2016 3:00 AM, "Kalapi Gajjar-Bordawekar" <kalapi...@gmail.com> wrote:
>
>> What are the benefits of this approach?
>
> It's futureproof.

Please could you unpack this?

> It means that we do not have to calculate 125% for new fonts and we follow a method that's more in line with the spec.

My concern is that we end up herding the collection towards 2 different v metric configurations, which increases complexity of the overall Google Fonts product... So this approach would be a kid of local maximum, and while its better for individual new families, to make the whole collection better, the global maximum (accounting for positioning stability, and simplicity for text environments without linespacing control which are legion) is to use Khaled's approach for everything.

But I spoke to Omer about this and he said that we should herd the collection towards what is most correct and future-proof (whatever that means in the details) but we should also minimize disruption for users, so we should use Khaled's approach when updating fonts already published by today, but use Kalapi's approach for each new family going forwards. 

We will need to update the checklist at https://github.com/googlefonts/gf-docs/blob/master/ProjectChecklist.md with this at some point; I made a quick edit with contextual info but didn't fill in the technical descriptions of the 2 methods. 

BTW there is another thread on this topic in http://typedrawers.com/discussion/1705/webfont-vertical-metrics-strategies

Cheers

Dave

[Kalapi Gajjar-Bordawekar]

Hi Dave, 

By futureproof I simply mean that the strategy follows the OTSpec in its definitions of these values and sticking to these will ensure that vertical dimensions will be consistent in current and future applications.

I agree with your conclusion.

Best,

Kalapi

[Dave Crossland]

On 26 July 2016 at 00:26, Dave Crossland <da...@lab6.com> wrote:

BTW there is another thread on this topic in http://typedrawers.com/discussion/1705/webfont-vertical-metrics-strategies

John Hudson has some good secondary points at http://typedrawers.com/discussion/comment/21982/#Comment_21982 :)

[Dave Crossland]

On 26 July 2016 at 00:43, Kalapi Gajjar-Bordawekar <kalapi...@gmail.com> wrote:

By futureproof I simply mean that the strategy follows the OTSpec in its definitions of these values and sticking to these will ensure that vertical dimensions will be consistent in current and future applications.

Okay cool :)

 

I agree with your conclusion.

Great!

--

Cheers
Dave

[Dave Crossland]

Hi Kalapi

Please could you post some before/after images of your work on Alfa Slab One the past few days? :) 

Cheers
Dave

[Kalapi Gajjar-Bordawekar]

1 August 2016. Bangalore, India.

Sorry for the lack of updates for the whole of last week. My newly started studio required some urgent admin work. Between that and restoring my computer to 100% functionality, there wasn't a lot of time left for updates on Alfa Slab.

1. Design Updates

a. The Raisin Project:

I continued refining the Alfa Slab project today. Here are a few images of the update. I'll post more images of expanded language support and macro refinements in the next two days.

2. Next Steps

a. Continue working on Alfa Slab

3. Questions

a. This one is for Jacques. Is it a good idea to have to versions of the 'J' in a font as follows:

Cheers,

Kalapi

[Jacques Le Bailly]

3. Questions

a. This one is for Jacques. Is it a good idea to have to versions of the 'J' in a font as follows:

Hi Kalapi.

You could to use a shorter I for the alternate IJ. The J would have to be a little wider.

[Kalapi Gajjar-Bordawekar]

2 August 2016. Bangalore, India.

1. Admin

a. Produced visuals for an internal presentation to show progress of Round 1.

2. Design Updates

a. The Raisin Project:

Continued work on expanding Alfa Slab's character-set to Pro.

Had some fun with the Dutch 'IJ'.

3. Next Steps

a. Continue working on Alfa Slab

4. Questions

None.

[Marc Foley]

Hey Kalapi and Khaled,

Thank you both so much for explaining your schemes in such detail. 

Since I am preparing a lot of repos and QAing. I thought I'd write the logic up as some scripts. At the moment the scripts can only be run in Glyphsapp. I will port them to FontTools soon. Please bare in mind these are incredibly draft. However, the logic is there and the readability is not too bad.

Kalapi's Scheme

Should typo_Descender really be Typo Descender  == to UPM - Typo Asc'. This will return a positive integer. Do you mean the neg of this so 250 should be -250?

Khaled's Scheme

I just realised I missed out the typo metrics flag on my script.

I would love to hear any comments you two have or suggestions if I've made errors.

Cheers,

Marc

[Dave Crossland]

One of the descenders has a positive actual value 👀

[Kalapi Gajjar-Bordawekar]

3 August 2016. Bangalore, India.

1. Design Updates

a. The Raisin Project:

I continued working on AlfaSlab today. Work included fine tuning the Vietnamese characters, fixing spacing/kerning, and other general fixes.

2. Next Steps

a. Ship Alfa Slab

b. Start work on Montserrat.

4. Questions

None.

</div

[Kalapi Gajjar-Bordawekar]

Hi Marc, 

Yes, the OS/2 sTypoDescender value would be a negative integer. I should've added something like "value is negative" in brackets as an addendum, sorry about that.

so, −(UPM − sTypoAscender) :)

And with regards to Dave's comment, usWinDescent has a positive value.

Cheers,

Kalapi

[Nhung Nguyen]

Hi Kalapi!

I just reviewed Vietnamese in Alfa slab one and I think you did a very good job! Although there're just some really small problems need to be fixed:

- Uhorn: I think you should erase the serif which is overlapping the horn here.

- Acute and grave in uppercase single diacritic glyphs: I think you over-slanted them. Maybe set the angle a little bit more straight? like this:

[Nhung Nguyen]

Hi Kalapi!

I added case diacritics for Anton and it's ready for you to review here: https://github.com/crystaltype/AntonFont

Thank you!

[Kalapi Gajjar-Bordawekar]

Thanks Nhung!

Will check this tomorrow!

Best, 

Kalapi

[Kalapi Gajjar-Bordawekar]

8 August 2016. Bangalore, India.

1. Admin

a. I spent most of the morning inspecting Nhung's Vietnamese extension for Montserrat.

2. Expansions

a. I continued working on the Montserrat expansion. The font has a lot of alternate glyphs, so some glyphs look interesting! ;)

fig: Schwa, Schwa.ss01, schwa, schwa.ss01

3. Next Steps

a. Continue working on Montserrat

Cheers,

Kalapi

</div

[Dave Crossland]

On 8 August 2016 at 18:18, Kalapi Gajjar-Bordawekar <kalapi...@gmail.com> wrote:

a. I spent most of the morning inspecting Nhung's Vietnamese extension for Montserrat.

Great! any specific comments/feedback :)

[Kalapi Gajjar-Bordawekar]

9 August 2016, Bangalore, India.

1. Admin

a. Produced text and images for a new Montserrat-only thread.

2. Expansion Projects (Montserrat)

a. Continued working on Latin Extended-A, Latin Extended-B, and Vietnamese glyphs.

3. Next Steps

a. Continue working on Montserrat

4. Questions

a. None

Thanks, 

Kalapi

[Kalapi Gajjar-Bordawekar]

Hi Dave, 

I've shared some observations on the Montserrat-specific thread just now (sorry for the delay on this!).

Cheers,

Kalapi

[Kalapi Gajjar-Bordawekar]

10 August 2016, Bangalore, India.

1. Expansion Projects (Montserrat)

a. Continued working on Latin expansion and fixing anchor/mark issues in the Vietnamese.

2. Next Steps

a. Make deck for Rokkit.

b. Complete Montserrat expansion.

Thanks, 

Kalapi

a. I completed updating 'Anaheim' to the Plus character set (except Vietnamese, but that is obvious!). The fork on my <a href="https://github.com/kalapi/ana

[Dave Crossland]

On 10 August 2016 at 18:33, Kalapi Gajjar-Bordawekar <kalapi...@gmail.com> wrote:

I've shared some observations on the Montserrat-specific thread just now (sorry for the delay on this!).

Perfect!

[Dave Crossland]

On 8 August 2016 at 11:15, Nhung Nguyen <vns.won...@gmail.com> wrote:

I added case diacritics for Anton and it's ready for you to review here: https://github.com/crystaltype/AntonFont

When you're done with Montserrat and before you start on the deck, please let us know about this :)

[Nhung Nguyen]

Hi Kalapi!

I wanted to ask you about Bevan. I saw that it already has kerning but the glyphs file in your repo lacks kerning. How did you import kerning into glyphs?

Thanks!

[Kalapi Gajjar-Bordawekar]

Hi Nhung, 

I'll check this out today along with Anton.

Thanks, 

K

[Kalapi Gajjar-Bordawekar]

11 August 2016, Bangalore, India.

1. Expansion Projects (Montserrat)

a. Update is complete. Latest source here -> https://github.com/kalapi/Montserrat.

b. Haven't fixed the 'VendorID' issue since I don't know what it would be.

c. Haven't added 'TRADEMARKS.md' because I don't have the relevant trademark information.

2. Next Steps

a. Check Anton.

b. Check kerning in Bevan.

c. Work on deck for Rokkit.

Thanks, 

Kalapi

[Kalapi Gajjar-Bordawekar]

19 August 2016. Bangalore, India.

1. Admin

a. Had an hour long meeting with the team on project updates.

2. Expansion Projects:

a. Rokkitt: Completed more work on the extreme masters. Basic sets are now done.

b. Oswald: Started working on evluating and drawing characters from the Plus set.

3. Next Steps:

a. Continue working on Oswald & Rokkitt. 

Cheers,

Kalapi

a. I made a local copy of the remote branch 'GF2016-fix' (which has since been deleted) on the google/fonts repo and tried to fix the merge conflicts in pull request <a href="https://github.com/google/fonts/pull/302" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fgoogle%2Ffonts%2Fpull%2F302\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFsRbIqrcpz9YFbFpGTpnwUMrBCEw';return true;" onclick="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fgi

[Kalapi Gajjar-Bordawekar]

22 August 2016. Bangalore, India.

1. Admin

a. Completed contractual formalities related to the projects.

2. Expansion Projects

a. Continued working on Oswald today. (Commits: https://github.com/kalapi/OswaldFont/commits/updates-20160822) 

3. Next steps:

a. Finish Oswald tomorrow and continue working on Rokkitt. 

Cheers,

Kalapi

[Kalapi Gajjar-Bordawekar]

23 August 2016. Bangalore, India.

1. Expansion Projects

a. Completed expanding Oswald to plus today (https://github.com/kalapi/OswaldFont).

Before:

After:

Vietnamese:

Currency:

Other than glyph expansions, I also updated some outlines in existing glyphs

Before:

After:

3. Next steps:

a. Start working on dancing script tomorrow. 

4. Questions:

a. @Dave: the current release of Oswald uses a vertical metrics approach where all metrics are 5% +/- yMax and yMin applied to all entries. The new package uses Khaled's approach and there are expected line-height changes. How would you like me to proceed?

Old:

new:

Cheers,

Kalapi

[Dave Crossland]

On 24 August 2016 at 09:33, Kalapi Gajjar-Bordawekar <kalapi...@gmail.com> wrote:

a. @Dave: the current release of Oswald uses a vertical metrics approach where all metrics are 5% +/- yMax and yMin applied to all entries. The new package uses Khaled's approach and there are expected line-height changes. How would you like me to proceed?

I want to avoid line-height changes.

[Kalapi Gajjar-Bordawekar]

Ok, i'll try to figure this out since the original numbers are arbitrary and based on 2048 UPM while the new project is 1000 UPM. 

[Kalapi Gajjar-Bordawekar]

24 August 2016. Bangalore, India.

1. Expansion Projects

a. Started working on Pablo's 'Dancing Script' today.

2. Next steps:

a. Continue working on 'Dancing Script' tomorrow.

Cheers,

Kalapi

[Dave Crossland]

On 24 August 2016 at 14:44, Kalapi Gajjar-Bordawekar <kalapi...@gmail.com> wrote:

Ok, i'll try to figure this out since the original numbers are arbitrary and based on 2048 UPM while the new project is 1000 UPM. 

A few px is not a problem :) 

[Pablo Impallari]

Hi Kalapi,

About Dancing Script: Are you able to generate font files from the Glyphs source?

Please, before extending projects, always test the glyph's migration against the original files to see if the migration was successful or not.

--
You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-discuss+unsub...@googlegroups.com.
To post to this group, send email to googlefonts-discuss@googlegroups.com.
Visit this group at https://groups.google.com/group/googlefonts-discuss.
To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/CAEozd0wJZAyv_eh%2BfVse2RsPo_jq1iy0fSKcEv2vcFA6FMS08w%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Un Abrazo
Pablo Impallari

[Kalapi Gajjar-Bordawekar]

Hi Pablo, 

What components in the source or binary are you referring to with regards to migration? Outlines, metrics (vert. & horiz.), kerning, anchors?

I usually check these things before I begin, however, in a lot of projects I have worked on, the sources are either the exact same or a few versions ahead. In the case of the latter, usually all if not most of the above components have been changed/updated before I even begin working.

With regards to Dancing Script, I noticed there was some amount of horizontal shift. On further examination, I found that there was a one point difference in the right side-bearing between the binary in the 'google/fonts' repo and the binaries generated from Glyphs. I could reproduce this issue when I tried exporting the original VFB from FontLab using the Glyphs 'Export' script.

E.g.:

Lowercase 'm' (old)- LSB: -35; RSB: -31

Lowercase 'm' (new)- LSB: -35; RSB: -30

Is this the kind of difference you're talking about? I'd mitigate this problem by exporting the original .AFM files from the VFB and importing it into Glyphs.

Best, 

Kalapi

On Thursday, 25 August 2016 13:45:55 UTC+5:30, Pablo Impallari wrote:

Hi Kalapi,

About Dancing Script: Are you able to generate font files from the Glyphs source?

Please, before extending projects, always test the glyph's migration against the original files to see if the migration was successful or not.

2016-08-24 15:51 GMT-03:00 Dave Crossland <da...@lab6.com>:

On 24 August 2016 at 14:44, Kalapi Gajjar-Bordawekar <kalapi...@gmail.com> wrote:

Ok, i'll try to figure this out since the original numbers are arbitrary and based on 2048 UPM while the new project is 1000 UPM. 

A few px is not a problem :) 

--
You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-discuss+unsub...@googlegroups.com.

To post to this group, send email to googlefon...@googlegroups.com.

Visit this group at https://groups.google.com/group/googlefonts-discuss.

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/CAEozd0wJZAyv_eh%2BfVse2RsPo_jq1iy0fSKcEv2vcFA6FMS08w%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Jacques Le Bailly]

If you need inspiration on Polish accents:

http://www.twardoch.com/download/polishhowto/stroke.html


YAK

Op woensdag 24 augustus 2016 20:51:53 UTC+2 schreef Dave Crossland:

[Kalapi Gajjar-Bordawekar]

Thanks man :)

[Pablo Impallari]

Hi Kalapi, 

I was talking about something even simpler.

In the latest online files in your repository, the source glyphs file won't export/generate OTF since the masters/instances metadata is not correctly defined. Maybe you fixed it already it (I don't know since you seem to be working locally, please commit your changes).

If I fix the instances metadata in my local copy and generate OTF files, they seem to be OK and match the original ones well.

[Kalapi Gajjar-Bordawekar]

Hi Pablo, 

My commits are on a branch and not merged into master yet (https://github.com/kalapi/DancingScript/tree/updates-20160824). I did fix the masters/instances metadata before I got them to work. 

Thanks, 

Kalapi

[Pablo Impallari]

Ups.. I missed the branch! Sorry.

--

You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-discuss+unsub...@googlegroups.com.

To post to this group, send email to googlefonts-discuss@googlegroups.com.

Visit this group at https://groups.google.com/group/googlefonts-discuss.

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/9d630cad-2853-4f14-9bef-a1657dc5e281%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Kalapi Gajjar-Bordawekar]

25 August 2016. Bangalore, India.

1. Expansion Projects (Dancing Script)

a. I continued working on Dancing Script today. Added more drawn letters (Ŋ, ŋ, ẞ, Ə, and ə), some maths operators and symbols.

2. Next Steps

a. Continue working on Dancing Script.

Cheers,

Kalapi

[Kalapi Gajjar-Bordawekar]

26 August 2016. Bangalore, India.

1. Admin

a. Had a group Hangout with team today.

2. Expansion Projects (Dancing Script)

a. Completed all drawn letters in both weights. Also started work on the Vietnamese block.

3. Next Steps

a. Continue working on Dancing Script.

Cheers,

Kalapi

<a href="https://lh3.googleusercontent.com/-hZVzMoO4M0s/V48DXEU3rQI/AAAAAAAABj0/YhyC6NM9jGMJwpPdgCD5V89y1YXr494EwCLcB/

[Kalapi Gajjar-Bordawekar]

2 September 2016. Bangalore, India.

1. Admin

a. I was on holiday for the last three days, and thus there weren't any updates.

1. Expansion Projects (Aref Ruqaa)

a. Today I will work on re-spacing the Latin bits (EMS Euler) of Aref.  

Cheers,

Kalapi

<a href="https://lh3.googleusercontent.com/-Y6-P0_SKuYE/V48DUcun4cI/AAAAAAAABjw/OKOgtjBqs-kj9WrI0WrKba_v2T7NBP1nwCLcB/s1600/Sheet_1.png" style="margin-left:1em;margin-right:1em" rel="nofollow" target="_blank" onmousedown="this.href='https://lh3.googleusercontent.co

[Kalapi Gajjar-Bordawekar]

5 September 2016. Bangalore, India.

1. Expansion Projects (Cabin)

a. I started working on Cabin today. Will post pictures soon!  

Cheers,

Kalapi

[Pablo Impallari]

Hi Kalapi,

Are you forking Cabin from https://github.com/crystaltype/Cabin or from somewhere else?

--

You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-discuss+unsub...@googlegroups.com.
To post to this group, send email to googlefonts-discuss@googlegroups.com.
Visit this group at https://groups.google.com/group/googlefonts-discuss.

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/3b4fc429-36d2-4b87-ba80-c43480190fd9%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Kalapi Gajjar-Bordawekar]

Hi Pablo, 

I started off by forking Marc's fork and then updated by local repo with Nhung's updates before starting the expansion work. 

I hope that makes sense?

Cheers,

Kalapi

To post to this group, send email to googlefon...@googlegroups.com.

Visit this group at https://groups.google.com/group/googlefonts-discuss.

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/3b4fc429-36d2-4b87-ba80-c43480190fd9%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Kalapi Gajjar-Bordawekar]

20 September 2016. Bangalore, India.

1. Update

I've been working on Pablo's Cabin for the past couple of weeks and just posted an update in a dedicated thread. 

2. Expansion Projects

a. Completed expanding and working on Cabin upright and condensed. Italics underway.

3. Tomorrow

a. I'll continue working on Cabin's Italic master. 

Cheers,

Kalapi