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
<address@hidden<mailto:address@hidden>> 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
>