Hi Toshiya, First of all sorry for responding a bit late. I have been trying to get SVG Native Viewer compiled and running with its Skia port. Turns out, Skia made some significant changes to their codebase recently and SVG Native Viewer hasn't been updated to take care of those changes. I didn't know this earlier and spent something like 8 hours trying to get it it to compile.
You don't need to apologize, Toshiya. I am really grateful that you're trying to explain it to me. Yes, you just cleared the whole thing to me now. I understand "staying" and "non-staying" now. I can also relate it to Werner's SVG Global and Local initialization. Basically, Werner just explained to me how we will be plugging modules in. Everything is clear and in perspective now. The terminology of "staying/non-staying" is totally fine to me. Thank you, Moazin On Fri, May 10, 2019 at 9:30 PM suzuki toshiya <mpsuz...@hiroshima-u.ac.jp> wrote: > Dear Moazin, > > On 2019/05/09 21:13, Moazin Khatri wrote: > > Thank you for taking the time to write so much. It's really helpful. > > My pleasure! > > > 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://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FDependency_inversion_principle&data=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C22fb6c0b75874555b00f08d6d477ba01%7Cc40454ddb2634926868d8e12640d3750%7C1%7C0%7C636930008017004019&sdata=kvUjwp6M8%2Fl0ORlQ%2FjmnUGGC0QXYLbVipU22LqZM3Q8%3D&reserved=0>. > I guess I have got most of it correct but please correct me wherever I have > got it wrong. > Correct, you've understood me perfectly. > > >> 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 apologize I made you confused. > > > 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.. > > OK, please let me try explain in another way. > > librsvg has 2 ways to obtain raster image from SVG data. > > One is: make a RsvgHandle object from SVG data, > and pass it to rsvg_handle_get_pixbuf(). > > Another is: make a RsvgHandle object from SVG data, > and create a cairo context, pass it to rsvg_handle_render_cairo(). > > (some people may think the 2nd way must be popular, > because there is a frequent rumor "rsvg renders SVG > by cairo", and rsvg-convert use it too. But if you > check rsvg-cairo.h, you would find using 2nd way out > of librsvg source tree would be warned as "deprecated"). > > In the 1st way, no data is shared between the rendering > of glyph A and glyph B. In my wording, there is nothing > "staying". The objects are only alive during the rendering. > > How about in the 2nd way? Of course, RsvgHandle objects > cannot be shared. But, how about cairo context? To render > glyph A and B, should we create 2 cairo surface, 2 > cairo contexts? Maybe it is not so stupid to hope that > we create single cairo surface and 2 cairo contexts, > or, reuse single cairo surface, single cairo context, > by flushing the content in cairo context before (or after) > rendering a glyph. > > In this case (single cairo surface), I want to call "cairo > surface is staying" from one rendering to next rendering. > > Can we reuse cairo surface or cairo context endlessly? > I'm not sure. For example, if I pass cairo recording > surface, it would record everything - I'm unsure it can > record all glyph rendering during a few months. I'm unsure > whether we can estimate the buffer used by the recording > of the past operation, but I think it could be expected > that FT asks for recreation of the cairo surface or cairo > context which has been used for a long time. > > In this case, "cairo surface" or "cairo context" could be > "staying". If you check SVG Native Viewer, you would find > that there are 2 distinctive objects, one is document and > another is renderer. So similar idea could arise (can we > reuse single Skia canvas? if we can, can we reuse forever?). > > I think, Werner's "global SVG initialization" is corresponding > to "staying" data preparation, "local SVG initialization" > is corresponding "not staying" data preparation. > > Could I explain unclear part in above? The later part > would be explained in next post. > > I must note that "stay" "non-stay" are just my temporal > word, you don't have to use them if you think it's misleading. > I can switch to different terminologies, if you have some > preference. > > Regards, > mpsuzuki > > > 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
