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