Re: Unified draft of SVG-in-OT

On Fri, Jul 26, 2013 at 12:05 PM, Leonard Rosenthol <lrosenth@adobe.com>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?
>

Advance width, but then applies GPOS on it.



> My layout engine needs to position an underline – does it use the
> baseline, the ink box, other?
>

Neither.  The font's underline position.



> 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.  The ink of the glyph does NOT affect text layout whatsoever.  I think
you are confusing things.

b


> 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
>
> From: Sairus Patel <sppatel@adobe.com>
> Date: Friday, July 26, 2013 11:38 AM
> To: Leonard Rosenthol <lrosenth@adobe.com>, "robert@ocallahan.org" <
> robert@ocallahan.org>
>
> Cc: Nikos Andronikos <nikos.andronikos@cisra.canon.com.au>, "
> public-svgopentype@w3.org" <public-svgopentype@w3.org>
> Subject: Re: Unified draft of SVG-in-OT
>
> CFF OpenType doesn't specify glyph bounding boxes (by bounding boxes I
> mean ink bounds, not advance width and other layout metrics). I don't think
> we should burden the SVG OpenType fonts with declaring bounding boxes for
> either static or animated renderings.
>
> As Rob said, the SVG renderer can compute the ink bboxes, and if that goes
> beyond the bounds of what the host application wants or is comfortable
> with, the host application can do the clipping to whatever the bounds it
> deems as appropriate.
>
> In the various font engines I work on, we tend to ignore any bounding
> boxes declared in the font since many are incorrectly set.
>
> Sairus
>
> From: Leonard Rosenthol <lrosenth@adobe.com>
> Date: Friday, July 26, 2013 8:24 AM
> To: Robert O'Callahan <robert@ocallahan.org>
> Cc: Nikos Andronikos <nikos.andronikos@cisra.canon.com.au>, "
> 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 8:27 AM
>
> Because you need to define the behavior up front and ensure that it's
> consistent. You can't have it being clipped in one case and not in another
> – that would produce inconsistent renderings  of the same glyph.
>
> I am trying to ensure that these extensions to OT are usable in
> non-web-based environments.   This is one of those places where it is
> important to set "boundaries" on what could potentially be done in order to
> guarantee that usage.
>
> Leonard
>
> From: Robert O'Callahan <robert@ocallahan.org>
> Reply-To: "robert@ocallahan.org" <robert@ocallahan.org>
> Date: Friday, July 26, 2013 11:22 AM
> To: Leonard Rosenthol <lrosenth@adobe.com>
> Cc: Nikos Andronikos <nikos.andronikos@cisra.canon.com.au>, "
> public-svgopentype@w3.org" <public-svgopentype@w3.org>
> Subject: Re: Unified draft of SVG-in-OT
>
> On Sat, Jul 27, 2013 at 3:18 AM, Leonard Rosenthol <lrosenth@adobe.com>wrote:
>
>> So you're suggesting that it's OK for a single glyph to be able to draw
>> ANYWHERE on the page/canvas?!?!    Sorry, but that's "crazy talk" (<grin/>).
>>
>> I recall a conversation with a colleague 25 years ago where we had a
>> similar argument.
>>
>> Bottom line: "It's my window and you can't draw on it".
>>
>
> If the caller wants to clip glyph drawing to a particular rectangle, I
> assume they can do so using whatever 2D drawing API they use.
>
> I don't really understand this conversation.
>
> Rob
> --
> Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
> le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
> stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
> 'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
> waanndt  wyeonut  thoo mken.o w  *
> *
>