> 1. `FT_LOAD_NO_SCALE`: For CFF/TTF outlines, this flag loads the
> outlines, but in font units, if you directly render it by
> `FT_Render_Glyph`, the render functions just assume that the
> points are in 26.6 point format, which isn't the case and thus
> you get a very small rendering (of size ~15 I think).
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.
> I'm not sure what to do with this flag when it comes to OT-SVG
> glyphs. For OT-SVG glyphs, I don't really have any outline data,
> I just store a transformation matrix with scale information that
> takes care of the sizing. If we leave the matrix to identity,
> it'll render to whatever the viewBox is set to in the SVG
> document, which is sometimes 1000x1000 or 128x128, or it could be
> anything really. Another option is to set a transform such that
> if you directly render the glyph it'd be at the same scale at an
> equivalent TTF/CFF glyph which was loaded via FT_LOAD_NO_SCALE.
> I'm completely clueless about which one to go about. Any
> thoughts on this?
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.
I guess deciding on which approach to go with also depends on the question
I ask above, are there any APIs to help a user scale to the device space from
font unit outlines other than setting up a transform manually? Because if there is,
I'd like to make that interface stay consistent with OT-SVG glyphs.
As far as I can see, the `units_per_EM` can be different for an SVG document
and a corresponding TTF/CFF glyph. 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.
2. If I program such that FT_LOAD_NO_SCALE sets up a scale transform such
that the SVG document is scaled to match the corresponding TTF/CFF coordinate
system (in just the scale), and then someone renders it directly, it'd end up being
rendered at 1000/1000. (Assuming the numbers 1000 and 128 above) While on
the other hand, rendering a TTF/CFF outline that was loaded with
`FT_LOAD_NO_SCALE` would just render at a size of ~15/~15 as (1000 >> 6 = 15)
The behavior isn't in harmony.
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.
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. 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.
> 2. `FT_LOAD_MONOCHROME` and other LCD modes: So this flag
> `FT_LOAD_MONOCHROME` and other `FT_RENDER_MODE_XXX` flags are
> there and I don't think it makes sense to keep these for OT-SVG
> glyphs. The very reason why there is OT-SVG is that people want
> colored fonts. I'm not sure if the LCD modes make any sense?
> Maybe I can return errors from the rendering module if these
> modes are requested in `FT_Render_Glyph`?
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, 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. For example,
if you look at Adobe's Trajan Color, it has gradients to give it a metallic feel in the
colored version but they mimic it in the b/w version with some lines. Also, FreeType's
renderers can't deal with SVG data, so we'd have to do the translation to b/w by
relying on the rendering library, that's an additional burden on the SVG library + graphics
library.
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. The user can then load a TTF/CFF outline and render it with that mode. Or we
can do it all ourselves behind the scenes but that can be very messy to do.