Proposal: Bitmap strikes

[ctrlcctrlv]

I have a large request. I will split it into parts.

This is a proposal for the representation of bitmap strikes in UFO in a way that creates little to no disruption.

This proposal expands and supersedes this comment of mine: #104 (comment)

Changes to the core spec

• Add clarification: <image> tag is for proofing images only without public.bitmapStrikes reference.
  • This is the behavior everywhere already, it future proofs it to avoid problems like.
• <image> color is demoted to optional. (Only AFAICT MFEK supports it fully, and I'd like to drop my support. It's not a good idea, sorry.) <image> color is explicitly ignored by public.bitmapStrikes.

Addition: lib.plist

Addition: public.bitmapStrikes

• dict
  • keys:
    • number_of_strikes: int
      • If a .glif has more <image> defined than this, then the excess are overflow/proofing-only. If this number is e.g. 2, then the first image in a .glif is strike one, second strike two. Third proofing.
    • strikes: array<dict>
      • keys:
        • size: int
        • useGlifMetrics: bool (if null true, if false, use png metrics where possible in output format)
        • useFontinfoMetrics: bool or BDF metrics array
        • pixelformat: enum (monochrome, grayscale, 256quantized, 256websafe, subpixel, fullcolor)
          • Important: This overrides PNG setting and is required as users not savvy enough to assure PNG pixfmt matches!
          • If subpixel then pixelformatSubpixelLayout field mandatory with another to-be-defined layout enum. I don't care to support this, people work it out if they want.
        • tryStoreApng: bool (if null false. if true will always use sbix for OTF)
        • feaBitmap: bool (if null true. meaning — compiler: please try hard to apply shaping to bitmap glyphs, even use experimental tables!)
        • overdrawOutlines: bool (if null false)
        • strikeAnchorMarks: bool (if null true — position marks as on outlines)