Re: [ft-devel] color framework
On Wed, Dec 19, 2018 at 10:35 AM Behdad Esfahbod wrote: > > On Wed, Dec 19, 2018 at 9:08 AM Alexei Podtelezhnikov > wrote: >> >> On Wed, Dec 19, 2018 at 5:43 AM Alexei Podtelezhnikov >> wrote: >> > > Alexei, I think we miscommunicate. >> > >> > I struggle to get your attention to FT_Glyph_To_Bitmap. >> >> I just discovered that, while ignoring the FT_Glyph abstraction in the >> current implementation, we also disregard FreeType caching system, see >> FTC_ImageCache_Lookup. This is just lovely but please continue your >> arguments against fire-walling FT_Render_Glyph from accessing FT_Face. > > > I don't understand what you mean; if you're being sarcastic or not. But > FreeType caching system does not solve any problem for the systems I know. > It's at best useful only for small clients for single-threaded use. If I suggested removing FT_Glyph and FreeType caching, that would be sarcastic. I just demonstrating how poorly the current implementation is thought out. It is a hack, nowhere near an integrated solution. I am also offering a path forward by implementing a dedicated BGRA renderer which would accept merged outlines tagged with color and/or layer index. We can discuss how to call the renderer without any references to FT_Face. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] color framework
On Wed, Dec 19, 2018 at 9:08 AM Alexei Podtelezhnikov wrote: > On Wed, Dec 19, 2018 at 5:43 AM Alexei Podtelezhnikov > wrote: > > > Alexei, I think we miscommunicate. > > > > I struggle to get your attention to FT_Glyph_To_Bitmap. > > I just discovered that, while ignoring the FT_Glyph abstraction in the > current implementation, we also disregard FreeType caching system, see > FTC_ImageCache_Lookup. This is just lovely but please continue your > arguments against fire-walling FT_Render_Glyph from accessing FT_Face. > I don't understand what you mean; if you're being sarcastic or not. But FreeType caching system does not solve any problem for the systems I know. It's at best useful only for small clients for single-threaded use. -- behdad http://behdad.org/ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] color framework
On Wed, Dec 19, 2018 at 5:43 AM Alexei Podtelezhnikov wrote: > > Alexei, I think we miscommunicate. > > I struggle to get your attention to FT_Glyph_To_Bitmap. I just discovered that, while ignoring the FT_Glyph abstraction in the current implementation, we also disregard FreeType caching system, see FTC_ImageCache_Lookup. This is just lovely but please continue your arguments against fire-walling FT_Render_Glyph from accessing FT_Face. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] color framework
On Tue, Dec 18, 2018 at 5:35 AM Werner LEMBERG wrote: > > >> FreeType is about to make a major leap into color rendering. > > > > Is it? Color rendering was the news before variable-fonts were > > news. So 2013. The world has moved on. > > You completely misunderstood. Alexei talks about FreeType, not about > the latest font news. > FreeType has been rendering color fonts on over a billion devices since 2015 or so. I still think the whatever FreeType is adding now is minor in comparison to that. At any rate, doesn't matter. > >> It is possible to make it right while keeping rendering separate. > >> The current solution is way to specific to COLR/CPAL. What if CFF > >> comes up with something different? I agree that current FT_Color > >> is too simple. We can add an index field there to indicate layers > >> explicitly or even reference gradient colors of SVG fonts. > > > > You cannot take just outline and gradients out of SVG and shove it > > into a model you design now. It's either SVG, or plain outlines. > > Don't try representing SVG in some other form unless you are > > volunteering to do it all. > > We won't do SVG. However, having a good representation of contours > with color layers is quite useful. > > > I actually found the FT_Renderer abstraction useful to let > > toolkits / applications install an SVG renderer on an FT_Library to > > render SVG color fonts. I like to see that as a possibility. > > Let's see whether someone is interested in this. What about making > > Add SVG support > > a GSoC project? :-) > > >> > Not really. It's not like glyphslot and face can be used > >> > separately. > >> > >> That's, in fact, the biggest problem with FreeType API: that one > >> cannot use FT_Face from multiple threads at the same time, because > >> all uses of it use the embedded glyphslot. > >> > >> Full circle: is FT_Glyph or rather FT_OutlineGlyph, extracted and > >> detached by FT_Get_Glyph, of any use? It is stripped down to bare > >> bones though. > > `FT_Glyph' is not, but Alexei wants to improve `FT_OutlineGlyph'. > > > It would be so much easier for FreeType clients, specially toolkits > > and frameworks, if FT_Face, FT_Size, and FT_GlyphSlot were all > > separate. Ie. one FT_Face could be used with multiple FT_Size's > > simultaneously, and multiple FT_Face/FT_Size pairs could be used to > > load glyphs into different FT_GlyphSlot's simultaneously. > > > > That is, for example, similar to how hb_face_t, hb_font_t, and > > hb_buffer_t are modeled. FreeType goes most of the way there, but > > alas, ties one FT_GlyphSlot and one FT_Size into the FT_Face, making > > it totally unusable for any sophisticated sharing scenario. If you > > can fix *that*, I'd be indebted to you eternally! > > AFAICS, this can't be fixed. The only solution I see is to define a > new API. > Obviously. What's wrong with defining new API? -- behdad http://behdad.org/ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] color framework
On Wed, Dec 19, 2018 at 5:43 AM Alexei Podtelezhnikov wrote: > FT_Render_Glyph used to be democratic. The renderers were chosen based > on the match between the glyph format and the rendering mode. The only > way to keep it this way is either FT_RENDER_MODE_BGRA or > FT_GLYPH_FORMAT_LAYERED. FORMAT_LAYERED was how I have had originally imagined this implemented (and started even). However, that still makes the GlyphSlot require Face to render, right? Not that I think that's wrong... The reason I like the current implementation in master is this: FORMAT_LAYERED itself is not enough. We would need a new flag to signal loading layers, since without that new flag, we should just load the requested glyph id. NO_RECURSE cannot be used for this, since that is already used to handle composite glyphs, which the glyph in question might be. > You know that I tried both. We are > introducing new way or rendering (for FreeType) I do not see a problem > with being open and transparent about it. > -- behdad http://behdad.org/ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] color framework
Hi Werner, > FT_LOAD_COLOR will *never* set > FT_LOAD_RENDER. How do you come to this impression? We are only > talking about the effect of FT_LOAD_COLOR on the rendering of > color-layered glyphs. Wonderful! > Alexei, I think we miscommunicate. I struggle to get your attention to FT_Glyph_To_Bitmap. > Actually, the current FreeType code *does* separate loading and > rendering. If you say > > FT_Load_Glyph(... | FT_LOAD_COLOR); > FT_Render_Glyph(... FT_RENDER_MODE_NORMAL); > > you get grayscale rendering of the normal outline. You must rather > say > > FT_Load_Glyph(... | FT_LOAD_COLOR); > FT_Render_Glyph(..., FT_RENDER_MODE_NORMAL | FT_LOAD_COLOR); > > to get a default blending of the color layers. Please do not oversimplify. FT_LOAD_COLOR is not passed but rather dug up from face->internal. Again. let's get rid of this hack for the sake of FT_Glyph abstraction. Perhaps, the *detached* FT_Glyph abstraction is useful for threading. > I think this is more user-friendly than introducing > FT_RENDER_MODE_BGRA. In other words, the presence of a `color' array > in the glyph slot makes the renderer select colour output. FT_Render_Glyph used to be democratic. The renderers were chosen based on the match between the glyph format and the rendering mode. That was wonderful and agnostic. You suggest a different logic for BGRA mode. What is somebody wants to plug in an alternative (say PNG) renderer? Oops, we are going to make it hard for you. FT_Render_Glyph used to be democratic. The renderers were chosen based on the match between the glyph format and the rendering mode. The only way to keep it this way is either FT_RENDER_MODE_BGRA or FT_GLYPH_FORMAT_LAYERED. You know that I tried both. We are introducing new way or rendering (for FreeType) I do not see a problem with being open and transparent about it. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] color framework
>> FT_LOAD_COLOR should trigger a standard case with some default >> blending; for finer color and blending control separate functions >> should be provided to allow direct layer access. > > Which [of] is these flags is spurious? > FT_LOAD_COLOR | FT_LOAD_RENDER | FT_LOAD_TARGET_BGRA > > I am ok with assuming FT_LOAD_TARGET_BGRA if FT_LOAD_COLOR is set. > FT_LOAD_RENDER should be explicit! It is absolutely crazy to > enforce slow rendering unless explicitly asked for. FT_LOAD_COLOR > should just merge all outlines/layers/contours and tag them with > COLOR, of course. I am just warning. FT_LOAD_COLOR does not imply > FT_LOAD_RENDER yet. Keep it this way. Alexei, I think we miscommunicate. FT_LOAD_COLOR will *never* set FT_LOAD_RENDER. How do you come to this impression? We are only talking about the effect of FT_LOAD_COLOR on the rendering of color-layered glyphs. Actually, the current FreeType code *does* separate loading and rendering. If you say FT_Load_Glyph(... | FT_LOAD_COLOR); FT_Render_Glyph(... FT_RENDER_MODE_NORMAL); you get grayscale rendering of the normal outline. You must rather say FT_Load_Glyph(... | FT_LOAD_COLOR); FT_Render_Glyph(..., FT_RENDER_MODE_NORMAL | FT_LOAD_COLOR); to get a default blending of the color layers. I consider this hacky. The main reason is that currently FT_LOAD_COLOR makes FT_Load_Glyph load *both* the normal outline and the colored-layered data. It would be better if this flag makes the function load only a contours array with glyph color information so that FT_Render_Glyph(..., FT_RENDER_MODE_NORMAL) automatically produces a BGRA bitmap. The definition of FT_RENDER_MODE_NORMAL should be then changed to Default render mode; it corresponds to 8-bit anti-aliased bitmaps for normal outlines (FT_PIXEL_MODE_GRAY) and color bitmaps for color-layered glyphs (FT_PIXEL_MODE_BGRA). I think this is more user-friendly than introducing FT_RENDER_MODE_BGRA. In other words, the presence of a `color' array in the glyph slot makes the renderer select colour output. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] color framework
> > FT_LOAD_COLOR used to be a loading flag only. > > This depends on what you exactly mean with `loading' and > `rendering'... Naturally, the rendering is FT_Render_Glyph, which takes render_mode. Because FT_Glyph's are rendered with dummy FT_Face, we cannot and must not use FT_LOAD_COLOR or even use FT_Face there. This is a critical point even from threading perspective: the rendering is so slow that we should not hang FT_Face waiting. We have to agree on this. > > The choice is between a hack and a proper implementation. > > We need both, as I've tried to implement in `master': FT_LOAD_COLOR > should trigger a standard case with some default blending; for finer > color and blending control separate functions should be provided to > allow direct layer access. Which is these flags is spurious? FT_LOAD_COLOR | FT_LOAD_RENDER | FT_LOAD_TARGET_BGRA I am ok with assuming FT_LOAD_TAGET_BGRA if FT_LOAD_COLOR is set. FT_LOAD_RENDER should be explicit! It is absolutely crazy to enforce slow rendering unless explicitly asked for. FT_LOAD_COLOR should just merge all outlines/layers/contours and tag them with COLOR, of course. I am just warning. FT_LOAD_COLOR does not imply FT_LOAD_RENDER yet. Keep it this way. Do we need the iterator once the layer outlines are merged and tagged with color? I do not see any purpose, frankly. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] color framework
>> Let's see whether someone is interested in this. What about making >> >> Add SVG support >> >> a GSoC project? :-) > > Ooohhh that's an extremely interesting and tempting thing; I wish I > could participate again (or had more time in general) :D The former is possible AFAIK, the latter is your very own problem :-) In general, the idea is as follows. * Evaluate the freely available SVG libraries which would fit the job best. * Define FreeType API functions and hooks for transferring data from the font's `SVG' table to the external library. * Ditto for transferring the resulting (bitmap) output back into FreeType. Anything else? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] color framework
> Let's see whether someone is interested in this. What about making > > Add SVG support > > a GSoC project? :-) Ooohhh that's an extremely interesting and tempting thing; I wish I could participate again (or had more time in general) :D ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] color framework
>> FreeType is about to make a major leap into color rendering. > > Is it? Color rendering was the news before variable-fonts were > news. So 2013. The world has moved on. You completely misunderstood. Alexei talks about FreeType, not about the latest font news. >> It is possible to make it right while keeping rendering separate. >> The current solution is way to specific to COLR/CPAL. What if CFF >> comes up with something different? I agree that current FT_Color >> is too simple. We can add an index field there to indicate layers >> explicitly or even reference gradient colors of SVG fonts. > > You cannot take just outline and gradients out of SVG and shove it > into a model you design now. It's either SVG, or plain outlines. > Don't try representing SVG in some other form unless you are > volunteering to do it all. We won't do SVG. However, having a good representation of contours with color layers is quite useful. > I actually found the FT_Renderer abstraction useful to let > toolkits / applications install an SVG renderer on an FT_Library to > render SVG color fonts. I like to see that as a possibility. Let's see whether someone is interested in this. What about making Add SVG support a GSoC project? :-) >> > Not really. It's not like glyphslot and face can be used >> > separately. >> >> That's, in fact, the biggest problem with FreeType API: that one >> cannot use FT_Face from multiple threads at the same time, because >> all uses of it use the embedded glyphslot. >> >> Full circle: is FT_Glyph or rather FT_OutlineGlyph, extracted and >> detached by FT_Get_Glyph, of any use? It is stripped down to bare >> bones though. `FT_Glyph' is not, but Alexei wants to improve `FT_OutlineGlyph'. > It would be so much easier for FreeType clients, specially toolkits > and frameworks, if FT_Face, FT_Size, and FT_GlyphSlot were all > separate. Ie. one FT_Face could be used with multiple FT_Size's > simultaneously, and multiple FT_Face/FT_Size pairs could be used to > load glyphs into different FT_GlyphSlot's simultaneously. > > That is, for example, similar to how hb_face_t, hb_font_t, and > hb_buffer_t are modeled. FreeType goes most of the way there, but > alas, ties one FT_GlyphSlot and one FT_Size into the FT_Face, making > it totally unusable for any sophisticated sharing scenario. If you > can fix *that*, I'd be indebted to you eternally! AFAICS, this can't be fixed. The only solution I see is to define a new API. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] color framework
>>> > As long as adding FT_LOAD_COLOR will get COLR/CPAL glyphs >>> > rendered into the bitmap, cairo/Chrome will work fine and I have >>> > no problem with that. >> >> FT_LOAD_COLOR has been FreeType public API since 2013. > > FT_LOAD_COLOR used to be a loading flag only. This depends on what you exactly mean with `loading' and `rendering'... IMHO, your assumption is not correct: Assuming that the default rendering mode of FreeType is always grayscale rendering (FT_RENDER_MODE_NORMAL), this principle was already violated with the introduction of FT_LOAD_COLOR for color bitmaps since you actually get color bitmaps! Theoretically, grayscale bitmaps should have been returned by default. For Joe User it is thus obvious that FT_LOAD_COLOR automatically gives coloured outline glyphs even for FT_RENDER_MODE_NORMAL. > The choice is between a hack and a proper implementation. We need both, as I've tried to implement in `master': FT_LOAD_COLOR should trigger a standard case with some default blending; for finer color and blending control separate functions should be provided to allow direct layer access. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] color framework
> All I'm asking is, if FT_LOAD_COLOR is passed to FT_Load_Glyph() then color > bitmap be rendered. How it trickles down the abstractions and machinery > into render, you can change. You object to explicit spelling FT_LOAD_COLOR | FT_LOAD_TARGET_BGRA | FT_LOAD_RENDER. Otherwise, you understand the issue. I think the explicit language makes code clearer. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] color framework
On Sat, Dec 15, 2018 at 11:10 PM Alexei Podtelezhnikov wrote: > > FreeType is about to make a major leap into color rendering. Is it? Color rendering was the news before variable-fonts were news. So 2013. The world has moved on. > It is > possible to make it right while keeping rendering separate. The > current solution is way to specific to COLR/CPAL. What if CFF comes up > with something different? I agree that current FT_Color is too simple. > We can add an index field there to indicate layers explicitly or even > reference gradient colors of SVG fonts. > You cannot take just outline and gradients out of SVG and shove it into a model you design now. It's either SVG, or plain outlines. Don't try representing SVG in some other form unless you are volunteering to do it all. I actually found the FT_Renderer abstraction useful to let toolkits / applications install an SVG renderer on an FT_Library to render SVG color fonts. I like to see that as a possibility. > >> The choice is between a hack and a proper implementation. > > > > Not really. It's not like glyphslot and face can be used separately. > That's, in fact, the biggest problem with FreeType API: that one cannot use > FT_Face from multiple threads at the same time, because all uses of it use > the embedded glyphslot. > > Full circle: is FT_Glyph or rather FT_OutlineGlyph, extracted and > detached by FT_Get_Glyph, of any use? It is stripped down to bare > bones though. > > Thank you for your understanding of my position. Really. > I think you misunderstood my intentions upthread. When I asked what's wrong with current color framework, I really meant it. And when I said as long as cairo and Chrome work I don't care, I also meant it :). All I'm asking is, if FT_LOAD_COLOR is passed to FT_Load_Glyph() then color bitmap be rendered. How it trickles down the abstractions and machinery into render, you can change. Since I brought up FT_Face vs FT_GlyphSlot issue, let me put it in writing: It would be so much easier for FreeType clients, specially toolkits and frameworks, if FT_Face, FT_Size, and FT_GlyphSlot were all separate. Ie. one FT_Face could be used with multiple FT_Size's simultaneously, and multiple FT_Face/FT_Size pairs could be used to load glyphs into different FT_GlyphSlot's simultaneously. That is, for example, similar to how hb_face_t, hb_font_t, and hb_buffer_t are modeled. FreeType goes most of the way there, but alas, ties one FT_GlyphSlot and one FT_Size into the FT_Face, making it totally unusable for any sophisticated sharing scenario. If you can fix *that*, I'd be indebted to you eternally! Cheers, b -- behdad http://behdad.org/ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] color framework
On Sat, Dec 15, 2018 at 2:55 PM Behdad Esfahbod wrote: >> It is wrong to use >> FT_LOAD_COLOR in FT_Render_Glyph. There is a way to properly pass all >> necessary information.to that function. > > I understand your desire to encode all info into FT_Outline; but given how > much glyphslot is tied to face, I don't think it's a big deal to require face > and load layers at render time. Exactly. Besides FT_GlyphSlot, there is FT_Glyph completely detached from FT_Face. Those are rendered with FT_Glyph_To_Bitmap, which calls FT_Render_Glyph_Internal with dummy FT_Face and unaware of FT_LOAD_COLOR. This works because FT_Render_Glyph does not (did not) use to dig though FT_Face. Indeed the rendering used to be completely separate from loading. FreeType is about to make a major leap into color rendering. It is possible to make it right while keeping rendering separate. The current solution is way to specific to COLR/CPAL. What if CFF comes up with something different? I agree that current FT_Color is too simple. We can add an index field there to indicate layers explicitly or even reference gradient colors of SVG fonts. >> The choice is between a hack and a proper implementation. > > Not really. It's not like glyphslot and face can be used separately. > That's, in fact, the biggest problem with FreeType API: that one cannot use > FT_Face from multiple threads at the same time, because all uses of it use > the embedded glyphslot. Full circle: is FT_Glyph or rather FT_OutlineGlyph, extracted and detached by FT_Get_Glyph, of any use? It is stripped down to bare bones though. Thank you for your understanding of my position. Really. Alexei ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] color framework
On Fri, Dec 14, 2018 at 8:25 AM Alexei Podtelezhnikov wrote: > >> > As long as adding FT_LOAD_COLOR will get COLR/CPAL glyphs rendered > into the bitmap, cairo/Chrome will work fine and I have no problem with > that. > > > >> You started to use unreleased features. > > > > FT_LOAD_COLOR has been FreeType public API since 2013. > > FT_LOAD_COLOR used to be a loading flag only. And cairo only uses it that way. > It is wrong to use > FT_LOAD_COLOR in FT_Render_Glyph. There is a way to properly pass all > necessary information.to that function. > I understand your desire to encode all info into FT_Outline; but given how much glyphslot is tied to face, I don't think it's a big deal to require face and load layers at render time. > The choice is between a hack and a proper implementation. > Not really. It's not like glyphslot and face can be used separately. That's, in fact, the biggest problem with FreeType API: that one cannot use FT_Face from multiple threads at the same time, because all uses of it use the embedded glyphslot. > Which is it, Werner? > -- behdad http://behdad.org/ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] color framework
>> > As long as adding FT_LOAD_COLOR will get COLR/CPAL glyphs rendered into >> > the bitmap, cairo/Chrome will work fine and I have no problem with that. > >> You started to use unreleased features. > > FT_LOAD_COLOR has been FreeType public API since 2013. FT_LOAD_COLOR used to be a loading flag only. It is wrong to use FT_LOAD_COLOR in FT_Render_Glyph. There is a way to properly pass all necessary information.to that function. The choice is between a hack and a proper implementation. Which is it, Werner? ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] color framework
On Thu, Dec 13, 2018 at 12:28 PM Alexei Podtelezhnikov wrote: > > As long as adding FT_LOAD_COLOR will get COLR/CPAL glyphs rendered into > the bitmap, cairo/Chrome will work fine and I have no problem with that. > > This is just unfair. FreeType is not paid by or owned by Google. Did I imply that it is? > You started to use unreleased features. FT_LOAD_COLOR has been FreeType public API since 2013. > Also Google did not contribute that code. It actually did :). > This is wrong to pose such demands! > No. It's perfectly natural to ask that new color formats continue working with existing color API. > > That said, my hunch is that the proposed change breaks glyphs with > consecutive overlapping layers of same color, as the proposed change will > render them in same go, mixing their winding numbers. > > That is substantive. This would only create a problem if the layers > follow opposite convention: one fills to the left, one fills to the > right, i.e. it will break broken glyphs. > Those glyphs are not broken according to any standard. > > Also, I was specifically referring to Alexei's work, which from where I > seat, often looks like "optimize math in X", "optimize math in Y", many > times without testing the code involved. > > Again I am not paid by Google. That's irrelevant. It's good software engineering practice to test code you change. > to follow some arbitrary rules. Testing software is not some arbitrary rule. :) > But thank you for testing. > > > I should not be called obnoxious for demanding that code that is changed > be tested. Or rather, code that is not tested not be changed. > > Stop rolling with git head then. > It's not about me rolling with git head or not. FreeType is used on over a billion devices. If I don't run git head and don't report bugs, they just come back later when they are rolled to many more people. You might not care. Fortunately you are not FreeType maintainer. Werner knows better. -- behdad http://behdad.org/ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] color framework
>> ??? What do we break? COLR/CPAL support will be *new* in 2.10.0, >> it wasn't present in the 2.9.x series. We don't plan to drop the >> FT_PIXEL_MODE_RGBA mode that you've added for CBDT/CBLC/sbix >> support. > > As long as adding FT_LOAD_COLOR will get COLR/CPAL glyphs rendered > into the bitmap, cairo/Chrome will work fine and I have no problem > with that. This will work. What Alexei is working on is a better representation of coloured contours in FreeType. To maintain backwards compatibility we can't add a `color' field to `FT_Outline'; instead, we have to add work-arounds... > That said, my hunch is that the proposed change breaks glyphs with > consecutive overlapping layers of same color, as the proposed change > will render them in same go, mixing their winding numbers. No, this won't happen. Layers will still be rendered one after another. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] color framework
> As long as adding FT_LOAD_COLOR will get COLR/CPAL glyphs rendered into the > bitmap, cairo/Chrome will work fine and I have no problem with that. This is just unfair. FreeType is not paid by or owned by Google. You started to use unreleased features. Also Google did not contribute that code. This is wrong to pose such demands! > That said, my hunch is that the proposed change breaks glyphs with > consecutive overlapping layers of same color, as the proposed change will > render them in same go, mixing their winding numbers. That is substantive. This would only create a problem if the layers follow opposite convention: one fills to the left, one fills to the right, i.e. it will break broken glyphs. > Also, I was specifically referring to Alexei's work, which from where I seat, > often looks like "optimize math in X", "optimize math in Y", many times > without testing the code involved. Again I am not paid by Google. to follow some arbitrary rules. But thank you for testing. > I should not be called obnoxious for demanding that code that is changed be > tested. Or rather, code that is not tested not be changed. Stop rolling with git head then. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] color framework
On Thu, Dec 13, 2018 at 11:55 AM Werner LEMBERG wrote: > > >> > As long as you don't break cairo and Chrome, I don't care what > >> > you do. > > > > [...] and annoyed that you change things without caring about > > breaking things. > > ??? What do we break? COLR/CPAL support will be *new* in 2.10.0, it > wasn't present in the 2.9.x series. We don't plan to drop the > FT_PIXEL_MODE_RGBA mode that you've added for CBDT/CBLC/sbix support. > As long as adding FT_LOAD_COLOR will get COLR/CPAL glyphs rendered into the bitmap, cairo/Chrome will work fine and I have no problem with that. That said, my hunch is that the proposed change breaks glyphs with consecutive overlapping layers of same color, as the proposed change will render them in same go, mixing their winding numbers. Also, I was specifically referring to Alexei's work, which from where I seat, often looks like "optimize math in X", "optimize math in Y", many times without testing the code involved. I should not be called obnoxious for demanding that code that is changed be tested. Or rather, code that is not tested not be changed. Proper response to a bug report, even a single-line one, should be "thank you". I should also not be attacked when I ask that changes not break existing clients. b > >Werner > -- behdad http://behdad.org/ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] color framework
>> > As long as you don't break cairo and Chrome, I don't care what >> > you do. > > [...] and annoyed that you change things without caring about > breaking things. ??? What do we break? COLR/CPAL support will be *new* in 2.10.0, it wasn't present in the 2.9.x series. We don't plan to drop the FT_PIXEL_MODE_RGBA mode that you've added for CBDT/CBLC/sbix support. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] color framework
On Thu, Dec 13, 2018 at 10:27 AM Alexei Podtelezhnikov wrote: > On Thu, Dec 13, 2018 at 10:23 AM Behdad Esfahbod > wrote: > > > > As long as you don't break cairo and Chrome, I don't care what you do. > > > > That is not how it works. Please help up to make FreeType better. > > I hate to say it, but somebody should, you have been quite obnoxious > recently. You one sentence bug reports without any demonstration are > arrogant too. Come down to Earth, man! > There's just not enough time for me to do more. How hard is that to see? I'm not trying to be hard. Just, overwhelmed, and annoyed that you change things without caring about breaking things. I have to make sure the entire stack works. And have done that for over ten years. It has worn me out. So I handed out most responsibility to others and have only kept HarfBuzz around. I care enough, and have time to, comment and bug report. But don't have time to debug everything or get into long arguments. b ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] color framework
On Thu, Dec 13, 2018 at 10:23 AM Behdad Esfahbod wrote: > > As long as you don't break cairo and Chrome, I don't care what you do. > That is not how it works. Please help up to make FreeType better. I hate to say it, but somebody should, you have been quite obnoxious recently. You one sentence bug reports without any demonstration are arrogant too. Come down to Earth, man! ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] color framework
As long as you don't break cairo and Chrome, I don't care what you do. On Thu, Dec 13, 2018 at 10:04 AM Alexei Podtelezhnikov wrote: > >> Once the TrueType loader learns to combine > >> all layers into a single outline and fill color information, it is > >> good to go. Just load and render those with FT_RENDER_MODE_BGRA. > > > > What was wrong with the existing code / model? > > > > C'mon guys! Admit that the current implementation has tons of flaws. > > The render is not supposed to know anything about the layer indexes or > any other stuff from FT_Face or TT_Face. It is supposed to be > *separate*, receive only outline data and color and render the bitmap. > That is the essential proposal. It so happens that in order to > implement this we need to provide direct access to all outlines and > color data in FT_GlyphSlot. Luckily it is possible without breaking > anything. It is a good thing!!! > > Sure, FT_LayerIterator and FT_Get_Color_Glyph_Layer becomes > unnecessary and we can get rid of it.. Those who need layer indexes > should get them though FT_LOAD_NO_RECURSE. The palette color index can > be appended to FT_SubGlyphRec too. The renderer is not supposed to > know the palette indexes because it comes from TT_Face. It is a good > thing to keep the render agnostic!!! > > Yes, I would not want 2.10 to come out with the flawed color support. > > Best regards, > Alexei > -- behdad http://behdad.org/ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] color framework
>> Once the TrueType loader learns to combine >> all layers into a single outline and fill color information, it is >> good to go. Just load and render those with FT_RENDER_MODE_BGRA. > > What was wrong with the existing code / model? > C'mon guys! Admit that the current implementation has tons of flaws. The render is not supposed to know anything about the layer indexes or any other stuff from FT_Face or TT_Face. It is supposed to be *separate*, receive only outline data and color and render the bitmap. That is the essential proposal. It so happens that in order to implement this we need to provide direct access to all outlines and color data in FT_GlyphSlot. Luckily it is possible without breaking anything. It is a good thing!!! Sure, FT_LayerIterator and FT_Get_Color_Glyph_Layer becomes unnecessary and we can get rid of it.. Those who need layer indexes should get them though FT_LOAD_NO_RECURSE. The palette color index can be appended to FT_SubGlyphRec too. The renderer is not supposed to know the palette indexes because it comes from TT_Face. It is a good thing to keep the render agnostic!!! Yes, I would not want 2.10 to come out with the flawed color support. Best regards, Alexei ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] color framework
>> Just load and render those with FT_RENDER_MODE_BGRA. > > What was wrong with the existing code / model? The current implementation relies on FT_LOAD_COLOR and is contrary to FreeType design. Even ft2demos do not support it, besides ftview, which is forced to copy the the entire rendering code. The rendering code itself is a very special case in FT_Render_Glyph. It is a hack by definition. FreeType is designed with modular renderers. It only works in FT_Render_Glyph. FT_Glyph_To_Bitmap doesnot work. The entire FT_Glyph infrastructure is side-tracked. It is just better to maintain FreeType design principles: from FT_LOAD_TAGET_BGRA to FT_RENDER_MODE_BGRA to FT_PIXEL_MODE_BGRA. This is how FreeType is supposed to work, I think. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] color framework
On Tue, Dec 11, 2018 at 11:49 PM Alexei Podtelezhnikov wrote: > Hi all, > > I have just pushed out a new branch called color. This is a framework > and renderer for color glyphs, which Werner and I discussed offline. > The basic idea is to supplement outlines with color information for > each contour so that consecutive contours of the same color can be > rendered as layers. A new FT_RENDER_MODE_BGRA is introduced to render > color glyphs if the color information is provided. A small > demonstration is implemented in ftstring (use color branch again). > > The color array pointer takes place of the reseved "other" pointer in > FT_GlyphSlot. So this in binary compatible. FT_OutlineGlyphRec, > however, acquired a new field, this can, but very unlikely, break > binary compatibility. > > The main motivation is a straightforward and familiar interface for > rendering CPAL/COLR fonts. Once the TrueType loader learns to combine > all layers into a single outline and fill color information, it is > good to go. Just load and render those with FT_RENDER_MODE_BGRA. > What was wrong with the existing code / model? > Regards, > Alexei > ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
