Re: Unified draft of SVG-in-OT

Thanks for this example of AnchorFormat2, Jonathan.

When I said "Text layout should absolutely *not* change when switching
from CFF/TT renderings to SVG renderings (static or animated) in the same
font" I should have qualified that I was talking about layout done in
"pure" design space units.

Any hinting- or ppem-specific layout (whether for AnchorFormat2 or for
advance widths, as some applications do) may indeed not translate
precisely if you change the screen you view it on, much less change the
glyph outline technology.

Best,
Sairus


-----Original Message-----
From: Jonathan Kew <jfkthame@googlemail.com>
Date: Friday, July 26, 2013 9:26 AM
To: "public-svgopentype@w3.org" <public-svgopentype@w3.org>
Subject: Re: Unified draft of SVG-in-OT
Resent-From: "public-svgopentype@w3.org" <public-svgopentype@w3.org>
Resent-Date: Friday, July 26, 2013 9:27 AM

>On 26/7/13 17:05, Leonard Rosenthol wrote:
>> So I have a glyph with a defined height and width, yes?
>>
>> My layout engine needs to position the next glyph in the run.  Does it
>> use the advance width or the ink box width?
>
>The advance width. That's always been the case, regardless of the glyph
>outline technology. The ink box has no bearing on layout (except,
>perhaps, if a layout engine is attempting to do some kind of "automatic
>kerning" or such like -- but in that case, it would need to examine the
>actual shape of the glyph's ink, not just its bounding box).
>
>In general, a layout engine can place glyphs purely using the 'hmtx'
>table (plus 'kern' and 'GPOS', if present); it doesn't need to look at
>the actual glyphs in the 'glyf' or 'CFF ' table at all.
>
>(An exception would be if there are GPOS anchor points using
>AnchorFormat2, referring to specific points on the hinted outline.
>That's not going to work for SVG glyphs -- positioning would just have
>to be based on the unhinted design coordinates.)
>
>>
>> My layout engine needs to position an underline ­ does it use the
>> baseline, the ink box, other?
>
>The underline position as specified in the 'post' table. Or some other
>heuristic, if you prefer -- but surely not the ink box of each glyph.
>Would you expect the underline under "flip-flop" to dip down under the
>"p" glyphs, and rise up for the hyphen? Nor the maximal ink box of the
>font as a whole -- or else the underline for Zapfino would be WAY down
>there.
>
>Again, the ink box is irrelevant to layout. Its only (potential) value
>is to help a renderer optimize its painting operations.
>
>>
>> Today ­ this is all well defined for OT (and other font types) so that
>> layout engines can produce the same result from the same font.   Also,
>> what happens when you take the same content and render it in an
>> SVG-glyph-aware renderer and one that only does the standard glyphs?
>>   Does my layout shift?
>
>No (modulo the potential AnchorFormat2 hinting issue). Layout depends on
>the glyph advances, the line metrics, any GPOS adjustments, etc., but is
>independent of the glyph outlines.
>
>>
>> It is important that we define the behavior of these new glyph types
>> with all the detail that we have for the current types of glyphs.
>>
>> Leonard
>>
>
>

Received on Friday, 26 July 2013 17:06:13 UTC