W3C home > Mailing lists > Public > public-css-archive@w3.org > February 2018

Re: [csswg-drafts] [css-fonts-4] font-presentation doesn't have a great name (rename to font-variant-emoji)

From: DeeDeeG via GitHub <sysbot+gh@w3.org>
Date: Wed, 07 Feb 2018 21:09:08 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-363911362-1518037747-sysbot+gh@w3.org>
There seems to be a lot of, um "un-clarity" about what these values would do.

I can guess/infer what these would mean from a present-day implemetation standpoint, by looking at current color font support in browsers.

(To summarize, I think browsers might use black/white only OpenType tables when implementing the `font-variant-emoji: text` value, and prefer using tables that can display multiple colors when implementing `font-variant-emoji: graphic`)


Given that browsers tend to support the TrueType spec, and/or OpenType spec <sup>[[1]](https://caniuse.com/#feat=ttf)</sup>, which is a superset of TrueType,  everything below here in this comment is in the context of the [OpenType spec.](https://www.microsoft.com/en-us/Typography/OpenTypeSpecification.aspx)
- glyphs can be defined in a "fill"/"not-fill" binaristic way.
  - This can be an exclusively vector (curve) data format, as in these OpenType font tables: [`glyf`](https://www.microsoft.com/typography/otspec/glyf.htm), [`CFF`](https://www.microsoft.com/typography/otspec/cff.htm) or [`CFF2`](https://www.microsoft.com/typography/otspec/cff2.htm) and potentially [`SVG`](https://www.microsoft.com/typography/otspec/svg.htm).
  - Or this can be in a (binaristic "fill"/"not-fill") bitmap format, as in the [`EBDT`](https://www.microsoft.com/typography/otspec/ebdt.htm) table.
    - `EBDT` can also support full grayscale bitmaps, apparently. (not just "fill"/"not-fill" per pixel in the bitmap, but a multi-bit "fill intensity" per pixel in the bitmap.)
  - I would expect these tables to correspond to a "text" or "monochrome" or "plain" value for this draft CSS property.
    - Sticky point for implementors?: `SVG` table is able to host binaristic fill/not-fill outlines, OR multicolor glyphs. So, it is the only one of these tables that is not always single-color.
- glyphs can be defined in a few different potentially-multicolor formats.
  - [`COLR`](https://www.microsoft.com/typography/otspec/colr.htm) + [`CPAL`](https://www.microsoft.com/typography/otspec/cpal.htm) as in Segoe UI Emoji, and EmojiOne Mozilla which is bundled with Firefox
    - Outline layers+ color pallet (one color per outline, stack them -> potentially-multicolor composed glyph)
  - [`CBDT`](https://www.microsoft.com/typography/otspec/cbdt.htm)
    - Color bitmap data in one size (width x height) of bitmap per glyph
  - [`SBIX`](https://www.microsoft.com/typography/otspec/sbix.htm)
    - Color bitmap data, potentially multiple sizes (width x height) per glyph
  - [`SVG`](https://www.microsoft.com/typography/otspec/svg.htm) again
    - Complex image format, one "SVG file" per glyph. Edge decided to support only some features of SVG spec within fonts for their browser implementation. Mozilla seems to try to support the whole SVG spec.
  - I would expect these to correspond with "graphic", "image", or "fancy" or what-have-you in this draft CSS property.

GitHub Notification of comment by DeeDeeG
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1092#issuecomment-363911362 using your GitHub account
Received on Wednesday, 7 February 2018 21:10:21 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:24 UTC