PhilterPaper
commented
3 years ago I've gotten part way through a second, enhanced release, and ran into a problem. It seems that invoking SVG::Parser in two slightly different ways may be causing SAX usage in one and Expat in the other, resulting in the SVG hash being structured a bit differently between the two. I have posted a question about that as RT 138495. If I don't get an answer soon, I will try changing the decoding assumptions to use the new architecture, and see if it's consistent.
At this point, my intent is to create a library to support PDF::Builder's incorporation of SVG images, as scalable vector-based PDF graphics. Working on the assumption that the decoding of an SVG (file or string) will be non-trivial code, I'm keeping it as a separate project (SVG::Reader). I hope that it will prove useful to others as a base for using SVG in other Perl applications.
The structure (so far) is to return the SVG as a list (array) of elementary operations, along with the data and settings that apply to each operation. The exact layout is yet to be determined, and may change over time as PDF::Builder's use of SVG::Reader evolves (there's nothing there yet). Primarily, it has to be of a useful form for PDF::Builder, as that's the main objective. So, be careful about locking down your use of SVG::Reader for your own projects, as it may change (especially, early in its development). Please let me know if you are using SVG::Reader and how you would like to see it take shape, but I can guarantee nothing at this point.
If it does turn out that SVG::Reader turns out to be more trivial than I thought it would be, I may not consider it useful to keep it as a separate project (either on GitHub or as a CPAN package), and may end up folding the code into PDF::Builder. If a number of other projects start using it, and it would create a hardship for them if I fold the code into PDF::Builder, I will consider keeping it separate. In any case, I'll give you plenty of advance warning if SVG::Reader is going to disappear as a separate package. The code will still be freely available with PDF::Builder, but would be extra work for you to extract it and keep it up to date.
Right now, it looks like I'll be using SVG::Parser to do the basic SVG XML parsing, Image::SVG::Path to decode the
<d>path tag, and Image::SVG::Transform to decode the transform attribute. I'm open to suggestions if you know of a much better way to handle this. SVG::Reader will return at least one array (probably more, for the data used by the tags). I intend to parse and return everything that I can in an SVG, and will document anything that gets left behind. PDF::Builder will use only part of the SVG capability for static image generation, and ignore the rest (audio, animation, etc.), so be aware that not all aspects of SVG will end up being thoroughly tested! If there are some aspects of SVG that won't map fairly cleanly to PDF, I may omit those (although they should still be in SVG::Reader's output).I don't want to discourage anyone from giving SVG::Reader a try for a project, out of fear that it will vanish abruptly (or change radically), but I do want to give fair warning that it's a possibility. If you decide to use it, please let me know, so I can take that into consideration when deciding whether to change something already released, or even to fold the code into PDF::Builder. If I don't hear from anyone, I'll assume that no one is using SVG::Reader, and I'll go ahead and do as I please!
Please post in ticket "SVG::Reader use in other projects" (#2) to tell me that you're using it elsewhere (so I'm aware of it), and post requests for changes and feature enhancements in "Other users' requests" (#3). Thank you!