Post without Account — your post will be reviewed, and if appropriate, posted under Anonymous. You can also use this link to report any problems registering or logging in.

CTS 14 - Handling SVG?

  • 10 Replies
  • 1871 Views
*

Offline Phil

  • Global Moderator
  • Hero Member
  • *****
  • 823
    • View Profile
CTS 14 - Handling SVG?
« July 08, 2018, 12:57:44 PM »
PDF::Builder currently handles several image formats (GIF, JPEG, PNG, TIFF, etc.), any of which can be dynamically produced (on the fly) for a web page. Another increasingly popular format is SVG (Scalable Vector Graphics), which can be easily produced on the fly, and displayed by a browser. Would it be worthwhile to handle SVG graphics in the same manner as other graphics? The basic SVG commands are fairly simple to parse into PDF drawing commands, but SVG can also embed images within its codes, adding a layer of complication. The alternative could be to use an external utility to convert SVG content into an already-supported image format, but this would require that the user install some external program(s). Another choice could be to add hooks to permit invoking a user-supplied command line utility to convert SVG (or an arbitrary image format) into a supported image format.

Something like an existing file with SVG or image content (and SVG possibly embedded yet another image file) could either be read in or processed externally, while in-line SVG command text might be directly parsed by image_svg(). This could also pull in image files. Anyway, there are many combinations and possibilities for SVG support, that could be direct support (convert to PDF primitives) plus embedded images, or that SVG is externally converted to a supported image format. A program wishing to output PDF might also dynamically generate SVG for document graphics, in lieu of using PDF primitives directly, such as generating content suitable for browser (HTML) or PDF output.
« Last Edit: May 12, 2019, 07:51:25 PM by Phil »

*

Offline Phil

  • Global Moderator
  • Hero Member
  • *****
  • 823
    • View Profile
Re: CTS 14 - Handling SVG?
« Reply #1: November 03, 2018, 05:35:37 PM »
Just a note, prompted by wkHTMLtoPDF problem with SVG being rasterized. SVG input should preferably not be rasterized, but should be transformed into PDF graphics primitives. The idea is that such graphics should cleanly scale to all sizes.

I need to investigate whether PDF graphics are a subset or superset of SVG graphics, and whether there is anything in SVG that would be a problem to translate to PDF graphics.
« Last Edit: May 12, 2019, 07:52:06 PM by Phil »

*

Offline Phil

  • Global Moderator
  • Hero Member
  • *****
  • 823
    • View Profile
Re: CTS 14 - Handling SVG?
« Reply #2: December 06, 2018, 11:00:09 PM »
I just spent a number of hours digging through SVG, and it's huge — almost as big as PDF itself! Unless I can find a prewritten Perl library to parse arbitrary SVG code, it may just be too large a task to try to support all of SVG. SVG is supposed to be formatted as XML, so an XML-processing library may at least be able to do the task of parsing (and syntax checking) the SVG, leaving me to traverse the DOM and implement (at least) selected parts of it (outputting PDF graphics, text, and image primitives). The worst case would be to hand-code a parser for a small subset of SVG, to take care of the most common things. The challenge here is to later extend it (without breaking something) when someone says they desperately need the transparent bleems function… could I please tack that on?

There's stuff that PDF may not implement (many of the filters), and all the interactive stuff (e.g., <a> links) and animation- and sound-related things can probably be safely omitted. I think it would be sufficient to end up with a static "image" just like GIF, JPEG, PNG, TIFF, etc. The W3Schools SVG tutorial covers enough of SVG that supporting that much could be enough to get a useful product. On the other hand, the official W3C definition is a staggering amount of work.
« Last Edit: May 12, 2019, 07:52:29 PM by Phil »

*

Offline Phil

  • Global Moderator
  • Hero Member
  • *****
  • 823
    • View Profile
Re: CTS 14 - Handling SVG?
« Reply #3: December 30, 2020, 06:59:25 PM »
See CTS 10 for thoughts on using SVG instead of extending "regular" calls with relative coordinate versions.

*

Offline Phil

  • Global Moderator
  • Hero Member
  • *****
  • 823
    • View Profile
Re: CTS 14 - Handling SVG?
« Reply #4: March 01, 2021, 02:24:50 PM »
Pages 510-511 of the PDF 1.7 spec show a SlideShow with embedded SVG file. It seems to imply that it's possible that a PDF Reader can handle SVG natively. Be sure to look at that before putting any more effort into parsing an SVG and reproducing using PDF graphics and text primitives.

Add: possible false alarm. This PDF "slideshow" is the only place SVG is mentioned, and it is starting to sound like a "slideshow" is using external utilities to display various formats, including SVG (possibly using a browser, as JavaScript is mentioned). It looks like the SVG file is merely carried along (embedded) to hand over to the browser, but I will check to make sure.
« Last Edit: March 05, 2021, 07:34:05 PM by Phil »

*

Offline Phil

  • Global Moderator
  • Hero Member
  • *****
  • 823
    • View Profile
Re: CTS 14 - Handling SVG?
« Reply #5: March 17, 2021, 09:54:54 AM »
@sciurius has requested SVG vector support on PDF::API2 (RT 134780). I'm not going to get SVG out in PDF::Builder 3.022 (out probably within a week or two), but since there's interest, maybe that will get me moving faster on SVG support (already partly implemented). I need to get a bit further along before I put it on GitHub, but if anyone has interest in joining in, I can get it out a bit earlier.

*

Offline Phil

  • Global Moderator
  • Hero Member
  • *****
  • 823
    • View Profile
Re: CTS 14 - Handling SVG?
« Reply #6: May 17, 2021, 04:44:47 PM »
 PhilterPaper commented on Mar 17

Depending on how big the SVG code ends up being, I'm considering packaging it as its own CPAN module. It would in turn call three other packages (overall XML parser SVG::Parser, "path" decode Image::SVG::Path, and "transform" decode Image::SVG::Transform) and return an array of standardized, low level graphics and text calls, including all the applicable attributes at each call. The PDF SVG support would then output these primitives as PDF graphics and text calls. The new package would not be exclusively for PDF, but could be used in a wide range of applications.

I'm still fairly early in the design and writing process, so this architecture could change considerably. I'd like to get feedback on what others think of the idea. I don't know if I can support 100% of the SVG spec, but I will try to get in all of the SVG into the returned array, and on the PDF side handle most of the non-interactive static visual content. PDF may have to output a single object rather than outputting to graphics and text objects, so that items are rendered in the desired order. The input to the SVG package would be either a file path or a string of SVG code (so you could create an image on the fly).

*

Offline Phil

  • Global Moderator
  • Hero Member
  • *****
  • 823
    • View Profile
Re: CTS 14 - Handling SVG?
« Reply #7: May 17, 2021, 04:45:40 PM »
My current prototype/experiment uses SVG::Parser, but that's not cast in stone. I've seen a number of SVG-parsing packages floating around that use all sorts of XML parsers, and I'm open at this point to changing over if you can give some good arguments to do so. I do want to avoid prereq'ing a huge number of other packages, as some of these modules do. I also want to have something very portable that doesn't require a (for example) Python or R installation, things which don't come with a Windows box. Keep it fairly lightweight.

Whether or not I offer a Perl-based SVG parser as a separate module (described previously), internally it will use that structure to break down the SVG into a list of primitives and associated data and settings/CSS. That will be fed to something that generates the matching PDF primitives for output. If anyone has seen Perl-based support SVG parsers that largely or entirely handle this already, I'd appreciate hearing about them!

*

Offline Phil

  • Global Moderator
  • Hero Member
  • *****
  • 823
    • View Profile
Re: CTS 14 - Handling SVG?
« Reply #8: May 17, 2021, 04:47:08 PM »
Mon May 17 16:38:22 2021 PMPERRY@cpan.org - Correspondence added (to RT 134780)

On Sun Mar 21 17:12:23 2021, JV wrote:

Quote
Quote
See /issues/89 for my work on this subject.
Great to hear there's already work being done on this.

I expect to fairly soon (mid June?) be able to devote some serious time to this. Please read and start giving your thoughts on the GitHub issue (89) listed above. It would be nice to have input from people who have dived into SVG processing and are willing to share their experiences, while I'm still early in the architecting of this thing. Thanks!

*

Offline Phil

  • Global Moderator
  • Hero Member
  • *****
  • 823
    • View Profile
Re: CTS 14 - Handling SVG?
« Reply #9: June 21, 2021, 09:50:26 AM »
I finally found my preliminary development work on SVG conversion (I thought I had lost it when a PDF::Builder install overwrote the files, but I did turn out to have it on backups!). Release 0.001 is on GitHub under PhilterPaper/Perl-SVG-Reader. There will not be a CPAN release until 1.000 is ready (along with PDF::Builder SVG image support, using SVG::Reader).

At this point, I am assuming that I will keep this code in that repository, and release a CPAN package at release 1.000. However, if it turns out that the code is lightweight and trivial enough, and no one is trying to use it for their own projects, I may choose to fold it into PDF::Builder. I don't know at this point -- I want to wait to find out how big a project this is.

This first commit is very basic, and only starts the process. I still have a lot more work to do on it, but want people to see its progress. If I can spare time from other projects, I will work on it at a fairly steady pace. I hope by the end of July (or mid August) to have it largely "there". At some point, I need to write the code in PDF::Builder that actually makes use of this SVG::Reader. This package will not be released until it appears to be usable for PDF::Builder's SVG image support.

Issues involving PDF::Builder's SVG support should be opened under this repository, but issues involving the new library should be under Perl-SVG-Reader. I look forward to comments and suggestions (and even code) from others!

*

Offline Phil

  • Global Moderator
  • Hero Member
  • *****
  • 823
    • View Profile
Re: CTS 14 - Handling SVG?
« Reply #10: August 12, 2021, 11:43:48 AM »
sciurius commented on Jun 24

Good job!

Phil commented on August 12

I ran into a mess with SVG::Parser, in which it seems to randomly pick which library (Expat or SAX) it uses, based on exactly how it's invoked, resulting in somewhat differently structured hashes. I think I can work through finding which one is produced, and properly digesting its data, but it's still a nuisance. My query to SVG::Parser's ticket system (https://rt.cpan.org/Public/Bug/Display.html?id=138495) is still unanswered, so I'm becoming concerned that this product is unsupported. Does anyone have a suggestion on a better parser to use for SVG, possibly a more generic XML parser? It should produce something similar to SVG::Parser, and be supported!