Dear Moazin, On 2019/05/11 20:05, Moazin Khatri wrote:
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.
Oh, I apologize that I've not finished any documents how to build & test SVG Native Viewer. I've asked a few questions to Dirk and got his answers (I'm sure my questions must be almost same with you), but not summarized the informations as a step-by-step guide for others. I'm sorry for that my laziness made you spend your times. # however, yet I have no experience to build it on Windows. # only Linux and macOS... When I finish drafting of first revision, I hope you can review it and find some overlooked pitholes. Regards, mpsuzuki
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<mailto: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<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%7C340795f709f34a249fba08d6d6009c16%7Cc40454ddb2634926868d8e12640d3750%7C1%7C0%7C636931695437500792&sdata=gn8LmDwXyT5Dp9FwsKKEFYw0f1n%2BGDSmIy8iUroIJpA%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