Re: Some questions about the OT-SVG implementation

[Werner LEMBERG]

>> 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