Hi Werner, Sorry for the late reply.
> > 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.
