Thanks for advice, you are right about being polite, I'll write to Chris shortly.

Can you sum up in one sentence...

No new functions yet; but smaller final pdf file size because of modern compression; some bugs fixed (no doubt, some added); faster on opening and parsing (and writing), sometimes significantly; somewhat less of a RAM hog.

Long version:

The CAM/PDF.pm contains 133 subroutines; 77 entries are enumerated in API section of the POD (though some of them use wildcards to designate several), and there are 104 methods further described in detail, some marked strictly internal. Plus there are several supporting modules in distribution with quite a few of their own subs. My module, close to 100% complete, has 37 subroutines. Most of them are replacement of originals, either complete re-write or just touched, and some are internal helper subs. No new functions for the end user, actually, at this stage. Added behaviour is triggered using options passed to constructor. Or better let's start with this: I'm planning it to be backward compatible. Whenever someone does:

use CAM::PDF;
my $pdf = CAM::PDF->new( $fn_or_stdin_or_pdf, @other_args );
# ... things happen with $pdf

[download]

they substitute for my module name and their code works as previously. New features are opt-in, with documented exception. On the external, one such feature is ability to save to 1.5+ version with compressed cross-reference stream and object streams -- thus, smaller file size. No CPAN module can do that, to my knowledge. (Rather, PDF::API2 can append xref stream on incremental update; but it can only update, not save "cleanly" and optimize; file size can only grow. Plus, it's funny to see a screenful or two of your code in "alien" environment, because the patch was written by yours truly.) Slightly less external option is "no slurping on open", but it only matters for really huge input with high resolution images. Typical office or business pdf file size is dwarfed by what CAM::PDF consumes itself. Speaking of which, I changed some of its internal accounting and procedures to improve performance.

In reply to Re^2: Choosing namespace/name for (my first) CPAN module which is a sub-class of a well-known distribution by Anonymous Monk
in thread Choosing namespace/name for (my first) CPAN module which is a sub-class of a well-known distribution by Anonymous Monk

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.