No support for vector graphics

[hankivy]

Graphics methods are not supported. See the methods in PDF::API2::Content in CPAN.

1. Design - Offer changes to documentation to show your design for the commands in the text file.
   • Checkpoint with the owner.
2. Create text files for testing graphics methods. 2A. Include multiple successful uses, that test a wide range of simple figures, a variety of options, with graphics in colors. 2B. Include multiple examples of bad uses, that demonstrate syntax checking, error messages, and out of limit values. A bad use should not result in not processing the rest of the file. 2C. Include text that explains the expected results.
   • Checkpoint once with the owner.
3. Add code to support the graphics methods.
   • Checkpoint once with the owner.
4. Test, debug, and correct until the text file and the code are good.
5. Repeat steps 2, 3, and 4 for more examples, with added variety and complexity.
6. Checkpoint and release with the owner.

[PhilterPaper]

General graphics (line and fill) are a major undertaking to add your own. You might be better off just giving access to current page dimensions and position, and the $text and $grfx objects, and let the end-user do as they please. Of course, this means leaving the environment of the text markup file and allowing access into Perl. Otherwise, you will need to provide wrappers for lots of calls. Utilities such as horizontal and vertical rules might be good to provide.

I am working on a new image format support for SVG, which might be easier for your users to make use of. They could provide SVG code as a text block, and you could wrap some boilerplate around it and pass it on to the SVG image routine (which could also accept an external file, like other image formats). Still, it is a programming language that your users would have to be careful to use properly.