Dear Toshiya, Thank you for taking the time to write so much. It's really helpful.
I already know about how callbacks in languages like JS and Python work and I am also familiar with how function pointers can be used to implement callbacks in languages like C. Your explanation made it even more clear. The collaboration by callback functions is: When FreeType finds SVG-OT, and > requested glyph is available as SVG, FreeType tries to extract SVG data > from the > font file (this could be done within FreeType). In next, FreeType tries to > invoke the callback function to pass the extracted SVG data. The callback > function should render the SVG data, and return the rendered result to > FreeType. > If external renderer returns PNG image data, FreeType can take the rendered > result as if it were PNG image data loaded from sbix table. Yet I've not > decided > about the cache subsystem. I think I understood this part pretty well. Basically, FreeType will be passed in some structure with function pointers. It'll rely on these functions for rendering SVGs. However, the internal logic won't really care where these functions come from. It'll only expect the functions to conform to an interface. Each renderer, let's give it the name 'SVG Rendering Module" for now, will have it's own structure that can be passed in. FreeType won't really care which one it is. Thus, we can swap "SVG Rendering Modules" whenever we want to without making any changes in the internal logic of FreeType. I guess this is something in principle very similar to Dependency Inversion <https://en.wikipedia.org/wiki/Dependency_inversion_principle>. I guess I have got most of it correct but please correct me wherever I have got it wrong. > Maybe, somebody wonders "so, the interface to be decided would be very > simple, the required feature would be only giving SVG data and taking PNG data". It > could be too simplified. In my understanding, most of existing > self-standing SVG > renderer is not designed to be "staying" as something like "SVG renderer > daemon". On the other hand, they might be designed to be initialized in > every > SVG document. I think SVG renderers in web browsers might be different, but > anyway, in the font driver, the renderer is expected to be "staying". So, > it is > needed to be the APIs to initialize & destroy the renderer itself. > So this part, I have understood some but have missed some too. I think I have understood what you meant by "staying" and "not staying". By "not staying" you are referring to a system that is stateless. For example, a system that exposes a function you can just call while passing in your "SVG Document" in the form of a "string" say, and it'll return a set of pixels back. That will be called "not staying". Since it doesn't stay. On the other hand, a "staying" system will be where you're given, say, some structure. You initialize it, maybe pass in some configuration and stuff, the object stays in memory. You can use it to perform renderings. Multiple times. Once you're done you can destroy it. This is what you meant by "staying" I guess? Please correct me if I got it wrong.. When you say "font driver", do you mean the "driver type object in FreeType" or in general font drivers? In the last sentence, you're saying that the it will be the job of APIs to initialize and destroy the "SVG Rendering part"? By APIs here I guess you mean the "collaboration via callbacks" mechanism? Now provided that have understood correctly whatever I just rephrased, I am still unable to understand the overall meaning of the paragraph. In particular, I am having trouble seeing the connection between the "simplicity" part in the beginning of the paragraph and the "staying" and "not staying" parts that follow. I am sorry for writing so much. I just want to make sure I understand this stuff properly so things can be easier when the actual coding starts. -Moazin
_______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
