Re: [ft-devel] An analysis of Librsvg

[suzuki toshiya]

Dear Vincent,

Vincent Torri wrote:
>> * the supported elements
>> I think the elements supported by this loader are defined by
>> TAG_DEF macro, thus, <use>, <circle>, <ellipse>, <path>, <polygon>,
>> <rect>, <polyline>, <line>, and, <defs>, <g>, <svg>, <switch>
>> are supported. Am I understanding correctly?
> 
> yes

Good!

>> * input: xml support
>> If I can spot the location of the SVG document parser, it seems
>> that the parsing of SVG is helped by XML parsed in
>> src/lib/eina/eina_simple_xml_parser.c
> 
> yes, it's a simple SAX-like parser

I see!!

>> * output: efl_gfx
>> If I can spot the location of the SVG document parser, the
>> rendering of parsed SVG is done by _efl_gfx_path_XXX() in
>> src/lib/efl/interfaces/efl_gfx_path.c
>>
>> There is a comment "code adapted from enesim which was adapted
>> from moonlight sources". Are they based on FreeType2?
> 
> here I have to ask. I'm not involved in the development of that part.
> I'll ask the maintainers

Thank you for taking care! My impression is, Enlightenment has their
own graphic framework which is very rich-featured, and, I'm wondering
whether we can extract the minimum part to have something like "svg2png".

At present, most SVG renderers are using Cairo, Skia, Qt or other
rich graphic framework. If we are focused to the simple raster
output instead of scalable graphic devices, there is a possibility
to reduce the codesize - maybe Cairo + pixmap could be already too
much. However, I don't think this is exciting item for most people,
and nobody is trying to write such.

Regards,
mpsuzuki