Re: Unified draft of SVG-in-OT

Text layout should absolutely *not* change when switching from CFF/TT renderings to SVG renderings (static or animated) in the same font. See the "Glyph semantics and metrics" section of the proposal. There is only *one* set of layout metrics for glyphs in the font.

> 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 (from the hmtx table) is a starting point, and then OT layout glyph positioning (GPOS and kern table) is done. This is a simplified explanation, of course, but ink glyph bboxes are not used.

(InDesign I believe used to use ink glyph bboxes for a particular kind of Japanese spacing mode years ago, but there is disagreement on whether ink bboxes were needed for that mode. In any case, CoolType simply renders glyphs to obtain their ink bboxes if clients such as InDesign wants them.)

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

The OT spec's concept of underline position places it relative to the baseline. But a particular graphics model may define its concept of underline differently.

> Today – this is all well defined for OT

Again, note that OT has no concept of glyph bboxes for CFF OT fonts.

I think most if not all of these concerns should be resolved if we clearly separate the concepts of ink glyph bboxes and layout metrics (advance widths, etc).

Sairus


From: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>
Date: Friday, July 26, 2013 9:05 AM
To: Sairus Patel <sppatel@adobe.com<mailto:sppatel@adobe.com>>, Robert O'Callahan <robert@ocallahan.org<mailto:robert@ocallahan.org>>
Cc: Nikos Andronikos <nikos.andronikos@cisra.canon.com.au<mailto:nikos.andronikos@cisra.canon.com.au>>, "public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>" <public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>>
Subject: Re: Unified draft of SVG-in-OT

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?

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

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?

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<mailto:sppatel@adobe.com>>
Date: Friday, July 26, 2013 11:38 AM
To: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>, "robert@ocallahan.org<mailto:robert@ocallahan.org>" <robert@ocallahan.org<mailto:robert@ocallahan.org>>
Cc: Nikos Andronikos <nikos.andronikos@cisra.canon.com.au<mailto:nikos.andronikos@cisra.canon.com.au>>, "public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>" <public-svgopentype@w3.org<mailto: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<mailto:lrosenth@adobe.com>>
Date: Friday, July 26, 2013 8:24 AM
To: Robert O'Callahan <robert@ocallahan.org<mailto:robert@ocallahan.org>>
Cc: Nikos Andronikos <nikos.andronikos@cisra.canon.com.au<mailto:nikos.andronikos@cisra.canon.com.au>>, "public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>" <public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>>
Subject: Re: Unified draft of SVG-in-OT
Resent-From: "public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>" <public-svgopentype@w3.org<mailto: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<mailto:robert@ocallahan.org>>
Reply-To: "robert@ocallahan.org<mailto:robert@ocallahan.org>" <robert@ocallahan.org<mailto:robert@ocallahan.org>>
Date: Friday, July 26, 2013 11:22 AM
To: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>
Cc: Nikos Andronikos <nikos.andronikos@cisra.canon.com.au<mailto:nikos.andronikos@cisra.canon.com.au>>, "public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>" <public-svgopentype@w3.org<mailto: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<mailto: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