djrrb / bungee Goto Github PK

(Posting this on behalf of Dwayne from MS, who very helpfully sent a couple issues my way. @RoelN may be interested.)

Sbix glyphs need originOffset to be accurate. Currently the table says that the bottom left of the bitmap is the horizontal origin, but the horizontal origin is actually to the left of the PNG.

This isn’t an issue for most sbix fonts because most sbix fonts are emoji, where the leftmost pixel of the PNG is usually the horizontal origin anyway, but it matters for text fonts because the sbix glyphs don’t align with other formats.

From DJR: For some reason, BungeeColor alignments seem okay in textedit.

The SVG artwork contained in the OpenType-SVG font has these headers,
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE svg PUBLIC '-//W3C//DTD SVG 1.1//EN' 'http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd'>.
They can be removed.

Make it so that apps don't default to Bungee-Hairline.

Just a reminder to figure out what i need to do on djr.com to get the backend site working.

The recently rebuilt fonts seem to have changed how block shapes and ss01 text align. Using the same CSS as before, alignment is no longer as good.

1. in horizontal mode, the block shapes now space correctly with no extra tracking. But in vertical mode, the shapes mush together and require 128% spacing to line up. Previously we tracked all backgrounds and foregrounds out equally at 128%.
2. in horizontal mode, the ss01 text layers no longer align in the middle of the shapes. This used to work without any extra CSS positioning:
   

I noticed a small shift in spacing when switching between the regular and alternate ’ in vertical rotated mode with block shapes. It seems the small alternate takes up less space and causes the letters below it to shift up slightly.

It doesn't do anything good, so I'm going to lose it next time I build the fonts.

I'm wondering if there is a better descriptive name for Bungee's ss02, which is currently "Round Forms".

https://github.com/djrrb/Bungee/blob/master/documentation/images/design-alternates-round-forms.png

It's more that it's a collection of diagonals that become vertical (with round tops and bottoms), and that's why, in my mind, the AMNWXY are connected, while the Round E is its own thing (ss03).

"Simplified Forms"? "Retro Forms"? Really I'm okay with "Round Forms", just thought I'd put it out there in case there was a better option.

Firefox displays vertical text sideways.

I think the shade offset is maybe a little too much.

I'm not sure how you're calculating it, but my estimate is that it should be about a third of the width of the shadow (which occupies 12% of the em). That means an offset that's 4% of the font size.

If that forces the shade to stick out on the left side, then maybe the letter size needs to get scaled down to 90%.

Here are the tools I believe the Google Fonts API uses to convert TTFs to web font formats:

The technique you use to layer chromatic fonts relies on ::before, which screen readers now recognize (and speak). As a result, when I visit https://djr.com/bungee/ (as an example), my screen reader will announce any layered text twice (three times if you use both ::before and ::after).

That is a technique I championed for a while, but I just recently developed a technique to retain what you want to achieve, make it easy for authors (who use a WYSIWYG, for example) to use, and retains accessibility without being verbose for screen readers.

I am happy to contribute some code, but first I thought you might want to review the technique and see if it is a fit for you: http://adrianroselli.com/2016/05/chromatic-web-fonts-redux.html

If not, then just consider this a bug report.

Happens in both Chrome and Firefox.

Make a release with a custom zip file of the fonts folder.

https://help.github.com/articles/creating-releases/

We want end users to be able to specify simple HTML classes to activate all the various possible shapes, e.g.

<div class='bungee vertical banner begin-flat end-arrow'>EAT</div>

Once #25 is done I'll write the Javascript to implement this.

In vertical writing-mode, the banner endcaps don't rotate with the rest of the font.

(The text alignment is my own problem.)

https://github.com/djrrb/Bungee/blob/master/documentation/3-vertical-text.md says,

The proper way to implement vertical text is via the CSS writing-mode and text-orientation selector, as well as implementing.

'as well as implementing' confuses me - could this be rephrased? :)

Currently there is no way to get monospaced vertical text with BungeeLayersRotated (besides using forced line breaks). Maybe try adding GPOS commands to {ss01} so that this is a little easier to use?

Already did it in the regular style, gotta propagate it to the build

Right now Safari the vertical spacing for the layers is messed up. It works fine in Chrome, Illustrator, and elsewhere.

It seems like Safari is ignoring the shared advance width, and instead uses the same sidebearings for all layers. Maybe the {vpal} table can't be shared across layers, and needs to be generated independently.

I would like to have preliminary versions of Bungee color fonts available with the release.

Theoretically this should be hardly any work. I already have /scripts/breakOutLayerIntoAlternates.py and that should do near or all of the work prepping the font for use with RoboChrome.

Unfortunately I can't get Robochrome to work. I followed up with Jens but we lost touch over the holidays. This is just a reminder for me to follow up with Jens and hopefully get this taken care of.

https://github.com/googlefonts/gf-docs/blob/master/ProjectChecklist.md#vertical-metrics explains the current GF v metrics policy; however, perhaps Bungee needs to be special.

If Bungee-Regular.ttf followed the policy, it would be like this:

$ fontbakery-fix-vertical-metrics.py *tf 
Parameter              Bungee-Regular.ttf    
ymax                   1634                  
hhea.ascent            1634                  
OS/2.sTypoAscender     1634                  
OS/2.usWinAscent       1634                  
ymin                   -914                  
hhea.descent           -914                  
OS/2.sTypoDescender    -914                  
OS/2.usWinDescent      914                   
hhea.lineGap           0                     
OS/2.sTypoLineGap      0                     
hhea total             2548                  
typo total             2548                  
win total              2548                  
UPM:Heights            1000:2548             
UPM:Heights %          254 % 

It would probably be a good idea to rewrite bungee.js to not require jQuery.

Currently the size is passed to the SVG script by the browser, but this can be buggy.

The NAME table has a few things that I would like to request changing before the next build.

• First is what I consider to be improvements that may be good to do for all possible contexts, by removing Regular from all 'family' and 'fullname' name records (both nameID="1" and 4)

eg in fonts/Bungee_TTF/Bungee-Regular.ttf it is Bungee Regular and should be Bungee

(I noticed that in Bungee-Regular.ttf the family name being Bungee Regular meant the windows full name became Bungee Regular Regular, which is a bit odd - all should just be Bungee :)

• Second, is adjusting the "Bungee Singles" fonts to make them fit snugly into the Google Fonts API. There are 5 files:
• fonts/Bungee_TTF/Bungee-Regular.ttf
• fonts/Bungee_TTF/Bungee-Hairline.ttf
• fonts/Bungee_TTF/Bungee-Inline.ttf
• fonts/Bungee_TTF/Bungee-Outline.ttf
• fonts/Bungee_TTF/Bungee-Shade.ttf

The Google Web Fonts API will present these as each a Regular (400 roman) instance for 5 different families, so the filenames should instead be,

• fonts/Bungee_TTF/Bungee-Regular.ttf
• fonts/Bungee_TTF/BungeeHairline-Regular.ttf
• fonts/Bungee_TTF/BungeeInline-Regular.ttf
• fonts/Bungee_TTF/BungeeOutline-Regular.ttf
• fonts/Bungee_TTF/BungeeShade-Regular.ttf
• Modulo the above point about Bungee-Regular.ttf, the nameID="1" values are all correct, but the PS name records (nameID="6") should be the same as the filenames above, and Typographic Family Name records (nameID="16" and 17) should be removed.

Nice work on Bungee! It's a beautiful font and a very elegant implementation of a difficult task.

When a layered version of Bungee is generated, it repeats the same content several times to give the visual effect. For screen readers, this means the content gets read for each time the content appears. If the text is layered 4x to create the visual effect, it'll get read 4x by a screen reader.

To fix this, you can leave the first time the font is displayed as is, but for any additional ones generated, add aria-hidden="true" role="presentation" to the HTML so the screen reader knows to ignore it. Here's an example:

<figure class="bungee regular-ffffff background-2b859d inline-e8e8e7 shade-215966 sign-247082 horizontal regular inline shade background sign" id="preview" data-max-font-size="30vh" style="font-size: 145px;">
    <div>
        <div class="layer background" style="background-color: rgb(43, 133, 157);"></div>
        <div class="layer text regular" style="color: rgb(255, 255, 255);">
            <span>Tester</span>
        </div>
        <div class="layer text inline" style="color: rgb(232, 232, 231);" aria-hidden="true" role="presentation">
            <span>Tester</span>
        </div>
        <div class="layer text shade" style="color: rgb(33, 89, 102);" aria-hidden="true" role="presentation">
            <span>Tester</span>
        </div>
    </div>
</figure>

You can read more about why this works here: http://john.foliot.ca/aria-hidden/

Again, great work! Looking forward to using it sometime :)

Tidy up and add build script

We want end users to be able to specify simple HTML classes to activate all the various possible shapes, e.g.

<div class='bungee vertical banner begin-flat end-arrow'>EAT</div>

We could save ourselves a little trouble and just number them (begin-3, end-4), but it would be a fun exercise to come up with descriptive words for each shape. I'll leave it to DJR which way you want to do it.

Getting a weird issue in Illustrator where the cursor and selection gets way larger than it should.

I checked the vertical metrics and they don't seem too out of whack. Is it a bbox thing? It's odd because it seems just fine in apps like InDesign or TextEdit, and I never noticed it before.

I'm seeing that the vertical banner/block settings seem to be shifted a little to the right in both live fonts and SVG versions. The SVG version also seems to be shifted a little up from center.

This is without the Shade layer on, so that offset shouldn't be a factor here.

The link at the top of the page (project description?) is wrong.

and goes to a 404 error page

Who actually owns the work in the project that will be OFL - I guess Font Bureau?

Will other parts of the project (code, website, etc) not be OFL?

In /fonts, make desktop and web folders, and incorporate Dave's patched TTFs into the final build.

I noticed that the Regular and Shade fonts are missing the following 2 stylistic set name records compared to the Hairline/Inline/Outline, and I just wanted to double check that's correct :)

    <namerecord nameID="266" platformID="1" platEncID="0" langID="0x0" unicode="True">      Block forms
...
    <namerecord nameID="267" platformID="1" platEncID="0" langID="0x0" unicode="True">      Vertical block forms

Right now, the documentation is divided into sections on layers, vertical, alternates, ornaments (banner/block) that explains more of the "what" and less of the "how" of typesetting Bungee on the web.

We might consider adding a separate page for bungee.js that covers its features and use. Chris, let's talk about the best way to write this.

(Posting this on behalf of Dwayne from MS, who very helpfully sent a couple issues my way. @RoelN may be interested.)

COLR fonts require that glyph id 1 is the .null glyph. Currently an Eth (D with slash) is allocated to that position which exhibits some bugginess in certain cases with apps.

https://www.microsoft.com/typography/otspec/colr.htm

Comparison with Segoe UI Emoji.

fsType is 4, must be 0

When block shapes are enabled, the browser completely ignores the font-feature-settings specified on the element.

Trying various combinations of font-kerning and font-feature-settings at different levels of the CSS hierarchy, we saw all kinds of weird behavior. Sometimes stylistic alternates would be applied to some characters in the string and not others.

Expected behavior:

Buggy behavior:

Ultimately I was able to fix this in Chrome by adding text-rendering: optimizeLegibility to the base style. However, Safari is still showing the issue.

Feel free to put them up in your preferred format, and I can edit them if/when it is necessary.

Have you considered using PDFs instead of PNGs in the sbix font?

@behdad spotted a bug in the kerning; note in a TTX of Bungee-Regular.ttf how the coverage has one glyph in it, but ValueCount is zero:

        <SinglePos index="4" Format="2"> 
          <Coverage Format="1"> 
            <Glyph value="block.v"/> 
          </Coverage> 
          <ValueFormat value="0"/> 
          <!-- ValueCount=0 --> 
        </SinglePos> 

Removing the line <Glyph value="block.v"/> heals the font :)