from what I can see, DFwiki and the certificate module both use fpdf - it would be trivial to remove fpdf from certificate module as it uses both anyway, not sure on dfwiki or other contrib modules.

it should be really trivial to remove FPDF too shouldn't it? - I don't even think there's a core wrapper for FPDF - just one for TCPDF

1) Warn and advise everywhere about that library being dropped in XX days (to give people time to upgrade to tcpdf / embed fpdf into their solutions). Also, perhaps we could use this wrapper: CONTRIB-622
2) Have one doubt about why tcpdf won't be exposed to the same (security) problems than fpdf when it seems to be based on it.
3) Also, there is one problem about the full size of current tcpdf library (fonts). See MDL-16802

Ciao

Perhaps now we are breaking things for third party modules in 2.0 it would be a good time to audit the current libraries to find any other unused ones?

1) it's used by the popular certificate module and I think some other 3rd party modules (Book?)
2) the portfolio API in Moodle 2.0 will need it

It could probably use some trimming down (fonts), but we do need to have one.

I'm unsure of the relationship between fpdf and tcpdf ... if we can lose fpdf and keep tcpdf working then my +1 for that!

AFAIK tcpdf is the successor of fpdf as the API is almost identical. Upgrading products ti use tcpdf instead of fpdf is not hard task. Plus, tcpdf has UTF8 support. Without UTF8 support, fpdf is useless for non-English Moodle users.

Regarding fonts - we can customize tcpdf a bit to load fonts from moodledata (pretty easy configuration change) and offer them as an optional pack at download.moodle.org. Then we can ship the core tcpdf with just one default font - I propose Deja Vu for its well known UTF8 support.

There are some small issues with tcpdf configuration left - eg. cache paths and thier URLs / that should be reviwed from the security point of view.

I am offering myself as a maintainer of tcpdf lib in the core.

Which looks like it was added with this bug: MDL-5855

I left fpdf in there to be used with langs that will work with it, e.g. english and other langs that don't use characters. I believe it works with most symbols (accents, etc.) too because of the added utf8_decode. Why? Because tcpdf embeds the entire font into the pdf, making for very large files (can be several megs depending on the size of any images used). This is why only one font is used in the unicode certificate types. This can be a problem especially if users are saving the certificate files in the course files and may have limited space, and could be a problem with some email programs if the certificate is mailed.

Tcpdf was added to be used by langs than won't work with fpdf, e.g. langs with characters. Those two unicode certificate types use only the Freesans and Freesans Bold fonts. I do know that some chinese languages need to create a new font for it to work using the make font utility. I have no idea what the "dejavu" fonts are--I didn't put those in there. Last I looked, there was no way to get around this, but there may be? I believe that Joomla switched from fpdf to tcpdf with 1.5. I might be worth taking a look at how they are using it.

I added the "protection" script to the fpdf lib, the tcpdf code already includes a protection script, so that isn't a problem.

And yes, tcpdf was built upon fpdf to use utf8 and is maintained by someone else--it is not really a successor.

Bottom line – if you switch over exclusively to tcpdf, certificates using more than one font (which I think can make for a very nice certificate) and large images could conceivably be up to 5 or 6 megs in size (if I remember, those with just one font were about 3 megs). So, if this is a problem for users, perhaps fpdf should still be an option (addon, etc.).

Hope this helps.