Using strikes, you can adapt your design to its intended size. If you’ve ever made a responsive website using css breakpoints, the concept is very similar. For instance if your strikes are at 20ppm, 128ppm and 512ppm (“pixels per em”), the operating system should show the 20ppm image up till 20px, the 128ppm image from 21px to 128px, and the 512ppm image from 129px to infinity. Between each strike size, the font will scale down the next largest bitmap to fit. Each size-specific bitmap is called a strike. This way one image doesn’t have to stretch to cover every size. The system can tell the font what size it is set at, allowing the designer to optimize a PNG for specific range of pixels. To me, the coolest thing about the Google and Apple tables is you can specify multiple images per emoji, one each for a range of sizes. How do they get around having scaled up or scaled down pixellated emoji PNGs? But still, the emoji font they are contained in can be used like any other vector font-scaled to any size.
But it allowed for the glossy, high-resolution, gradient- and drop shadow-rich skeumorphic design (😄) that Apple wanted in their emoji (which matched their iOS interface design up until iOS 7 📱). The ability for fonts, which have been vector files since the first PostScript fonts in the mid 80’s, to employ full-color bitmap PNGs is a little strange at first. “Sbix” stands for (I think) “Scalar Bitmaps”, which will make sense in a moment. It’s currently also the only table here that is proprietary-while Apple freely publishes its details, all the other tables are a part of the OpenType specification and sbix is not. Sbix is currently only implemented on OS X and iOS, and only in applications that use the system’s font renderer, like TextEdit and Safari. The tables are currently implemented in FreeType, which forms the basis for text rendering in many environments, such as Android, many Linux platforms, and some versions of the Firefox browser.Īpple’s sbix table is very similar, but it does all this in one table. The CBDT holds the bitmaps, the CBLC contains instructions on when to use them. Together the two tables allow PNG images to be used in place of letters in a font. The tables build off of a set of tables that were made for black-and-white and grayscale bitmaps, a hold over from the early days of TrueType. Their 4-letter table names translate to “Color Bitmap Data Table” and “Color Bitmap LoCation”, respectively. The Google/FreeType CBDT and CBLC tables get first mention here because they are the most simple. Let’s talk about the advantages and disadvantages each one. We left off last time with an overview of the four table “formats” of emoji: Google/FreeType’s CBDT/CBLC, Apple’s sbix, Microsoft’s COLR/CPAL and Adobe/Firefox’s SVG.
0 kommentar(er)
