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 _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
