Re: Chromatic fonts - implementation roundup [via SVG glyphs for OpenType Community Group]

Hi folks,

The tool used to create LapisLegit and EmojiOne has been fixed:
https://github.com/eosrei/scfbuild/issues/7

LapisLegit shows correctly in Edge now: https://pixelambacht.nl/lapislegit/

-Roel

On Wed, Aug 17, 2016 at 3:54 AM, Cameron McCormack <cam@mcc.id.au> wrote:
> Hi Sairus,
>
> On Wed, Aug 17, 2016, at 05:43 AM, Sairus Patel wrote:
>> I’d also heard of a Firefox bug in which unitsPerEm is assumed to be
>> 1000.
>>
>> Could Jonathan, Cameron, or someone else at Mozilla please confirm that
>> this is still a known limitation of Firefox’s OT-SVG impl?
>
> Firefox should honour the unitsPerEm in the head table to determine how
> to scale glyphs when rendering:
>
> http://searchfox.org/mozilla-central/rev/03b3c20a6ec60435feb995a2a23c5926188c85a1/gfx/thebes/gfxFont.cpp#2186-2193
>
> But I notice that we do use 1000x1000 as the size of the "window" when
> setting up the SVG document:
>
> http://searchfox.org/mozilla-central/rev/03b3c20a6ec60435feb995a2a23c5926188c85a1/gfx/thebes/gfxSVGGlyphs.cpp#134-153
>
> This can affect how percentage values in the SVG content are resolved if
> the root <svg> element does not specify a width="" and height="".   For
> example, assume you have a font with unitsPerEm = 2048:
>
>   <svg xmlns="http://www.w3.org/2000/svg">
>     <g id="glyph0">
>       <rect width="100%" height="128"/>
>     </g>
>   </svg>
>
> will define glyph 0 with a rectangle that is 1000 units wide, regardless
> of what the unitsPerEm value is, but the height of the rectangle will
> still take up 2048 / 128 = 16th of the height of the em square.
>
> (This is just from code inspection; I didn't test.)
>
> This is something that should be clarified in the specification.  Do you
> know what other implementations do for percentage values like this?  Are
> they resolved against a window size derived from the unitsPerEm?
>
> Thanks,
>
> Cameron
>

Received on Monday, 22 August 2016 18:30:43 UTC