Re: [ft-devel] libsvgtiny (Re: [ft] Three GSoC projects for FreeType)

[suzuki toshiya]

Dear Moazin,

Thank you for prompt response.

Moazin Khatri wrote:
> You're quite right that my original proposal for this idea was quite 
> different. The idea was to use some external well known and well tested SVG 
> Renderer to render SVG documents and writing the necessary glue code to make 
> this happen. More of it can be found in the proposal.
> 
> Writing a new renderer myself sounds something very different than my 
> original plan. I am not saying it's not doable at all, but given my lack of 
> expertise in the area of renderers, its hard to say whether I'll be able to 
> complete it within the GSoC period. However, if somebody volunteers to 
> collaborate with me on this during the period of GSoC, I'd very much love to 
> do that. The volunteer could focus more on the new renderer and I could focus 
> on making it work with FreeType. This would also be something quite similar 
> to my original proposal. :-)

Thank you, I'm happy to confirm that I'm not misunderstanding :-)

> In one of your recent emails in the list you say and I quote:
>> At present, I don't suggest to link SVG renderer to libfreetype directly.
>> For sbix color font support, libpng is directly linked to libfreetype,
>> but I suggest to make libfreetype + SVG renderer collaborate by a callback
>> system.

> Can you please clarify what do you mean exactly by collaboration via a 
> callback system? With the little knowledge of Software Architecture that I 
> have, my guess is you're trying to say that instead of making FreeType 
> directly dependent on one particular SVG Renderer, we should instead create 
> an abstraction in between so the users of FreeType can plug in any SVG 
> Renderer they like as long as they make it conform to the interface. This 
> would be similar to how Adobe's SVG Native Viewer 
> <https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fadobe%2Fsvg-native-viewer&data=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C3cf33d63de7348c0bd4d08d6d425950c%7Cc40454ddb2634926868d8e12640d3750%7C1%7C0%7C636929655210327541&sdata=aiehJTzVcTV%2FB503Qfk5rJfhgTKz%2BKB6JdOt%2FS1b1rs%3D&reserved=0>
>   relies on a rendering port to render stuff, and the users can plug in any 
> renderer they like as long as they write the glue code necessary. Which 
> you've also done with your Cairo 
based rendering port. I know how abstractions like these can be written in C++ 
via the use of Virtual Functions. But I am not sure how collaboration by 
callbacks work or even if it's the same idea. I apologize in advance if I have 
got some bit, or all of it wrong. Please explain if you can. It'd be also great 
if you can point me to any articles, documents, books or videos that explain 
this technique or codebases that implement this type of a "collaboration by 
callback functions" technique.

OK, please let me explain what *I* think now.

For first, I briefly introduce about the callback functions. If you think you
already understand the term "callback function", please skip this section

<section-about-callback-function-itself>
usually, in programming language C, we call the function to be used directly.
but some libraries, the author of the libraries can fix the frontend interface,
but want the clients to choose or develop their own backend. In such case, the
clients pass the function pointers to the library; the library invokes the
received function pointers when some process by backend is needed.
If you have experienced JavaScript, please remember about the eventlistener.
JavaScript programming language itself does define the appropriate behaviour
what JS should do when "click" event happens. JS provides the interface to set
the eventlistner, and the client sets it. When some event happens, JS invokes
the eventlistener function which the client has set already. However, the client
is not free about the design of the function to use as an eventlistener, JS
defines the interface (e.g. the first argument is the event object, what "this"
object is in the eventlistener, etc).
</section-about-callback-function-itself>

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.

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.

If my email is unclear, please ask me again. My English is quite poor, there
would be so many rooms to be improved in my explanation.

Regards,
mpsuzuki


Moazin Khatri wrote:
> Dear Toshiya,
> 
> You're quite right that my original proposal for this idea was quite 
> different. The idea was to use some external well known and well tested SVG 
> Renderer to render SVG documents and writing the necessary glue code to make 
> this happen. More of it can be found in the proposal.
> 
> Writing a new renderer myself sounds something very different than my 
> original plan. I am not saying it's not doable at all, but given my lack of 
> expertise in the area of renderers, its hard to say whether I'll be able to 
> complete it within the GSoC period. However, if somebody volunteers to 
> collaborate with me on this during the period of GSoC, I'd very much love to 
> do that. The volunteer could focus more on the new renderer and I could focus 
> on making it work with FreeType. This would also be something quite similar 
> to my original proposal. :-)
> 
> In one of your recent emails in the list you say and I quote:
> At present, I don't suggest to link SVG renderer to libfreetype directly.
> For sbix color font support, libpng is directly linked to libfreetype,
> but I suggest to make libfreetype + SVG renderer collaborate by a callback
> system.
> Can you please clarify what do you mean exactly by collaboration via a 
> callback system? With the little knowledge of Software Architecture that I 
> have, my guess is you're trying to say that instead of making FreeType 
> directly dependent on one particular SVG Renderer, we should instead create 
> an abstraction in between so the users of FreeType can plug in any SVG 
> Renderer they like as long as they make it conform to the interface. This 
> would be similar to how Adobe's SVG Native Viewer 
> <https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fadobe%2Fsvg-native-viewer&data=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C3cf33d63de7348c0bd4d08d6d425950c%7Cc40454ddb2634926868d8e12640d3750%7C1%7C0%7C636929655210327541&sdata=aiehJTzVcTV%2FB503Qfk5rJfhgTKz%2BKB6JdOt%2FS1b1rs%3D&reserved=0>
>   relies on a rendering port to render stuff, and the users can plug in any 
> renderer they like as long as they write the glue code necessary. Which 
> you've also done with your Cairo 
based rendering port. I know how abstractions like these can be written in C++ 
via the use of Virtual Functions. But I am not sure how collaboration by 
callbacks work or even if it's the same idea. I apologize in advance if I have 
got some bit, or all of it wrong. Please explain if you can. It'd be also great 
if you can point me to any articles, documents, books or videos that explain 
this technique or codebases that implement this type of a "collaboration by 
callback functions" technique.
> 
> Thanks,
> 
> Moazin
> 
> On Thu, May 9, 2019 at 5:54 AM suzuki toshiya 
> <address@hidden<mailto:address@hidden>> wrote:
> Dear Moazin, Alexei,
> 
> In my understanding, Sylvain's idea is much different from
> the draft schedule of GSoC project of Moazin: I think Moazin
> was going to combine some well-known & tested existing SVG
> renderer, not going to write yet another SVG renderer.
> Doing it might require big change of the schedule and task
> list in GSoC.
> 
> I welcome if there's any volunteer to work in this direction
> (if Sylvain would do, that's very helpful for Moazin), but
> I don't recommend Moazin to do it.
> 
> Moazin, how do you think about? Alexei, do you think whether
> it could be achieved (as a subside task) within GSoC 2019
> period?
> 
> Regards,
> mpsuzuki
> 
> Alexei Podtelezhnikov wrote:
>> That said, I am wondering if the expressive power of freetype internal vector
>> code could satisfy the requirements of the font svg rendering. Because that
>> would reduce the external dependency to some xml parser, then some internal
>> freetype code would "translate" this font svg directly into internal freetype
>> vector code.
>>
>> FreeType historically was a colorless rasterizer and only returned a pixel 
>> coverage map, which could then be colored and blended by a client 
>> application. As of the last version, FreeType can now add color according to 
>> CPAL/COLR tables, where each layer is blended with a monocolor. To support 
>> SVG, tt is a matter of implementing color gradients, which is not that hard. 
>> Some work needs to be done to implement data structures for complex colors 
>> and properly isolate the blending code into a dedicated blender-rasterizer.
>>
>