Re: Some questions about the OT-SVG implementation

Hi Werner,

Thank you for your response to the last email.

I'm dealing with the glyph metrics in the following manner:

The SVG standard requires fonts to have the advances in the hmtx and vmtx tables, which are to be used from there and the bearings are to be manually calculated from the glyph bounding box. What I've done is that I get the values from the tables at the CFF/TTF layer while loading the document and leave the rest of the calculation of the bearings (and also the vertical advance height calculation if it wasn't found in the table) to be done by the preset hook on the renderer side. That presetting hook is called later from FT_Load_Glyph automatically and thus the metrics will be filled in.

Horizontal Bearing X and Y are pretty straightforward, they are simply the horizontal and vertical distances from the origin to the left side and topside of the glyph bounding box.

The vertical advance I calculate as (height * 1.2). 1.2 is a chosen value, it simply looks good with a little bit of extra spacing. The vertical top side bearing I calculate by simply centering the glyph between the current origin and the next origin. So, (advance - height)/2.0. The vertical left side bearing I calculate by doing (horiBearingX - (horiAdvance/2.0)). These formulas come from FreeType the code on TrueType side. The corresponding metrics calculations in CFF seem weird, while they also provide okayish layout, the origins you can clearly see being on top of other glyphs. I attach a picture to illustrate this. The red dots show origin points.

These formulas give good renderings for vertical layouts, few screenshots are attached of the font Gilbert, PlayBox, TrajanColor and ColorTube.

What's your opinion on the formulas and code organization (advances on CFF/TTF side while actual bearings on the hooks side, the bearings do need the bounding box which is calculated in the preset hook, hence it made sense to do it this way).

Thanks,

Moazin

On Sun, Nov 7, 2021 at 10:31 PM Werner LEMBERG <wl@gnu.org> wrote:

>> Correct. `FT_LOAD_NO_SCALE` is not intended to be directly used
>> for rendering, since rendering always needs a transformation to the
>> output device space.
>
> So when it comes to the TTF/CFF outlines, what would the user do to
> scale the glyph to the device space if it was loaded initially with
> the NO_SCALE flag? Is there an API function do to that? I mean one
> can do the math and set up a transform manually, I'm just wondering
> if there's an existing API function to help with that.

There is no API function for that – and there weren't any requests for
such an API in the past, IIRC. For Joe User, unscaled outlines have
not much use.

>> Harmonizing with other formats is a good idea IMHO. What about
>> scaling the SVG data to the `units_per_EM` value for this
>> particular case?
>
> Umm, not sure what you mean exactly here. Could you please
> elaborate on what you mean by harmonizing and secondly how the
> scaling would make that happen.

If you have a font that contains an SVG document for glyph A but not
for glyph B, FreeType functions related to rendering should 'fit' so
that no further special treatment of A or B is necessary.

> As far as I can see, the `units_per_EM` can be different for an SVG
> document and a corresponding TTF/CFF glyph.

OK.

> Say it can be 1000 for TTF/CFF while it is 128 in the SVG document.
> Here are a few scenarios:
>
> 1. Say I program such that FT_LOAD_NO_SCALE sets up an identity
> matrix with the SVG document. In that case, if someone directly
> renders that document, it'll render at the size `x_ppem`/`y_ppem`
> of 128/128.

Oh, FT_LOAD_NO_SCALE should be handled differently, namely 'no
scale' :-) The primary target of this flag is *not* rendering. Users
are expected to do scaling/processing/whatever by themselves.

> 3. In order to harmonize it, you'd have to set up a scale transform
> that downscales the SVG document to mimic the 26.6 format thing.
> So in this case it'd be a scale transform from 128x128 ->
> ~15/~15.

Exactly.

> I think our priority can be to keep the interfaces consistent but
> rendering directly after loading with `FT_LOAD_NO_SCALE` is not a
> legal behavior right? A user is not supposed to do that.

Yes. However, I wouldn't talk about 'valid' (please don't say 'legal'
in this context); `FT_LOAD_NO_SCALE` simply serves a different
purpose.

> Maybe we can list all API functions that can operate on glyphs and
> use that as a guide to make sure that our interfaces remain
> consistent across different font formats.

Patches welcome!

>> My point of view is that if you have a font, and you ask for a
>> given glyph, regardless of the rendering mode, FreeType should
>> produce something. So if the font in question only has SVG data
>> for a given glyph, it should be rendered even in monochrome or LCD.
>>
>> It shouldn't be too difficult to implement that, I think: the SVG
>> interface returns an outline, which gets then handled by one of
>> FreeType's rasterizers, right?
>
> Since a CFF/TTF glyph must exist for every OT-SVG glyph that exists,
> [...]

Ah, my mistake, I forgot the details of the OpenType specification. I
thought that it would be valid to have an SFNT that contains SVG stuff
only. Since this isn't allowed, everything is simpler.

> if a user demands a b/w rendering, it really shouldn't be a b/w
> white version of the colored glyph, instead the original CFF/TTF
> glyph should be used, I think.

Yes, of course.

> If the user loads with FT_LOAD_COLOR, the SVG glyph got loaded and
> then renders with FT_RENDER_MODE_MONO or one of the LCD modes, maybe
> we can create a new error and return that mentioning that this
> rendering mode is not supported for OT-SVG glyphs.

Sounds sensible.

Werner

From:	Moazin K
Subject:	Re: Some questions about the OT-SVG implementation
Date:	Mon, 15 Nov 2021 20:39:41 -0800