Add TCPDF-min

I'm not sure who has the authority to allow exceptions to the download size.

Is there any way you could convince the developers to maintain a lightweight package without unnecessary files? (For example, the 'examples' folder seems extraneous, and the images and fonts folders are pretty large).

The print module supports the following PDF libraries:

- TCPDF: 11.6 MB - LGPLv3 - http://downloads.sourceforge.net/project/tcpdf/tcpdf_5_9_184.zip
- dompdf: 6.3MB - LGPLv3 - http://dompdf.googlecode.com/files/dompdf_0-6-0_beta3.tar.gz (already whitelisted)
- mPDF: 12.5MB - GPLv2 - http://mpdf1.com/repos/MPDF54.zip
- wkhtmltopdf: 10.7MB - LGPLv3 - http://wkhtmltopdf.googlecode.com/files/wkhtmltopdf-0.11.0_rc1-static-am...

There's no way that we can ask so many maintainers to create a Drupal-only-small version of these, just to satisfy an arbitrary limit that we imposed ourselves..

TCPDF is also used by:

- http://drupal.org/project/views_pdf
- http://drupal.org/project/webform2pdf

Postponing until new issue #1782540: Consider raising library size limit is resolved.

For the record, I no longer need TCPDF for CiviCRM #1588192: Please Whitelist this CiviCRM repo minimized to be < 10MB by removing libraries that can be shared from sites/all/libraries.

The CiviCRM team was able to include TCPDF in a minimized version for the download and still get entire CiviCRM including that actually functional parts of TCPDF < 10MB. If TCPDF is minimized and added to Drupal's whitelist, I would make the request to remove it from the minimized version of CiviCRM.

Sorry, but I don't agree w/ @jcnventura about it being impossible or even difficult to request minimized versions.

A -min download should really be part of every projects packaging. Every project I've asked has done it. We are talking about 3 posts and some follow up. If someone actually went through the trouble of asking and the answer was no for a legitimate reason, then we could revisit changing the 10MB limit or granting an exception. In most cases, these PDF packages are a small amount of code and are only over the 10MB limit because they include images in their sample/examples. The samples/examples aren't really something that should be included anyway. While you could delete the samples/examples with a patch in your profile, is it really less work to write a patch than to make the request for a minimized version?

The process I used w/ CiviCRM worked well:

1. I created my own minimized mirror of CiviCRM on GitHub
2. I asked to have that whitelisted
3. I use the whitelisted fork in my profile
4. Used the working profile to explain why we need a minimized download to the CiviCRM team

It took less than 30 days from first request to having every new release of CiviCRM minimized.

If not 10MB, where are you going to draw the line? The fact that third party packaging is even an option is amazing. I'd hate to see it become a burden to maintain because someone pushed the limits to save themselves some time communicating with the maintainers of another project.

Please keep in mind I'm a bit jaded on this topic as I was once told I'd have my CVS account suspended if I committed even 5K of third party, GPL code while other developers at well known shops openly violated that policy with no repercussions. Turned out, holding the line on third party code was the right decision in the long run, but the experience of having policies that only apply to some D.O. users left a bad taste in my mouth.

@kreynen: one of them (wkhtmltopdf) is impossible to reduce in size any further. It's a static binary containing the compiled program for use in Linux systems together with all required libraries. If you're lucky and your server distribution provides wkhtmltopdf already installed, or you can go to the trouble of compiling from source, the binary will be a lot smaller (source code is only 95kb). However, most users are not that savvy, and understandably the maintainers don't want to create a package for every n versions of Linux out there.

You're right in that TCPDF and mPDF contain some megabytes of examples and in fonts. The examples could be easily removed, without impacting functionality - removing fonts could be done, but would impact normal usage. I could contact the package maintainers and ask them to separate their examples into a separate package - that would remove about 300Kb from TCPDF and about 2.9Mb from mPDF. However, development of mPDF is currently in hiatus (maybe a reason not to whitelist it after all).

Because of the need to raise the limit for wkhtmltopdf, and the minimal saving in TCPDF, I see no reason to waste Nicola's time with such a request that would only cause delay on his TCPDF release process (and he releases often, so this could turn annoying).

Setting back the status.

Do we really want to allow binaries as part of stuff that is distributed from d.o? Seems a bit over the top and something that should be done by other means.

I agree. The whitelist request is only for the precompiled binary for 64bit AMD processors. Why not include the i386, Windows exe, and OSX dmg too?

As far as TCPDF, I don't think a compelling case for an exception is Nicola's time is more valuable and TCPDF releases more often than @lobo/CiviCRM. For CiviCRM, @lobo added drupal_sk_php5.sh to the packaging scripts they run with each release...

http://svn.civicrm.org/civicrm/trunk/distmaker/dists/

All it would take for TCPDF to be within the 10MB limit is to move the images into the examples directory, change the ">image references in example php files, and move the examples to their own branch and download.

While Nick is making a lot of commits, he rarely updates the examples. I don't really see making the examples a separate download as a huge request. Nick could say no, but no one has even asked.

My bad, I only use one version of the binary, that I forgot about i386, Windows and OSX. Just FYI the print module does include a 'drush pdf-download' command that downloads and installs these libraries automatically. All of them: TCPDF, mPDF, wkhtmltopdf and dompdf - sourceforge is really nice and there's a /latest URL that points to the latest TCPDF release - the others are hardcoded.

That potentially leaves only TCPDF still suitable for being whitelisted (until mPDF is actively supported again). I've requested a smaller version in the TCPDF forums (https://sourceforge.net/tracker/?func=detail&aid=3567341&group_id=128076...).

However, my calculations still indicate that effort would be mostly moot. Removing the images and the examples would leave about 400K of breathing space before TCPDF goes back over the 10Mb limit.. All it takes is the inclusion of another font to break it again. Or not even then depending on how that 10Mb limit is defined - 10*2^20 or 10^7 - as it's already about 100k above the latter case.

Well, I asked the TCPDF maintainer to reduce his package size.

Three months later, he said "No". See http://sourceforge.net/p/tcpdf/feature-requests/261/

So, seeing that Nicola is not interested in wasting his time, shall we raise the limit?

João

He didn't actually say no. What the library's maintainer actually said was..

The TCPDF distribution file is at the minimum size to get started (including examples). If you need to update frequently, please use the GIT repository instead.

This makes me think Nicola really didn't understand the request, but instead of responding to him 6 MONTHS AGO you came back to Drupal to repeat your request for an easy fix for you where the only cost is someone else's time. I personally think it would be ridiculous to increase the whitelist quota to include examples of a PDF library that when minimized for use in a project like CiviCRM includes only 43 items and is < 2.5MB uncompressed. The full download is more than 19MB uncompressed with 369 items. So only ~10% of the files included in that .zip are actually needed for an implementation.

I responded to the Sourceforge thread. I hadn't looked at Sourceforge for years and was surprised at how flexible it is now. Creating releases is very scriptable and it wouldn't take very long(< 1 hr) to script the creation of both a full and minimized version of TCPDF.

All libraries should include a package that is the minimum requirement for implementation. Increasing the quota every time we run into a library packaged w/ examples will not only result in bloat, but increase potential security issues since included example files with php and js files can also be exploited.

If a library maintain is truly against providing a minimized package for project implementations without the demos and documentation they provide new users, then the next step would be to start maintaining a fork on GitHub that removes the unnecessary files and request a whitelist of that. If no one is willing to invest the small amount of time it would take to pull and package upstream changes for a library, that should be an indicator of a library being of little value.

There might be a good reason to increase the quota to >10MB, but this is not it.

@kreynen: It seems he listened to you. As to the "6 MONTHS AGO" part, well I do Drupal as a hobby. Sometimes I go away for 6 months.

I think your prior experience with Sourceforge (I have none), and your last paragraph there must have made some difference to Nicola, as my request ("One possibility is to create a -min version of TCPDF, maintaining the existing version in parallel") was met with the "Please use GIT" reply that you quoted.

From what I see in http://sourceforge.net/projects/tcpdf/files/, there is now a -min version of TCPDF that is a whopping 446Kb in size. I guess you can also start to use that one in CiviCRM.

Can the TCPDF min version be whitelisted? The download URL for the latest version is:

http://downloads.sourceforge.net/project/tcpdf/tcpdf_min_6_0_020.zip

So I think the following whitelist rule would work:

^http://downloads\.sourceforge\.net/project/tcpdf/tcpdf_min_.+$

Seconding it as RTBC, as the request was created by pwolanin, as per the whitelist rules.

Removing the RBTC status. This issue was sidetracked by the fact that this library was too big. We've recently updated the list of licenses that can be whitelisted (https://drupal.org/node/1475972#whitelist-licenses). LGPLv3 cannot be whitelisted until something like #1449452: Give installation profiles/distributions GPLv3+ license as option for packaged downloads moves forward. Maybe this make @pwolanin's a convert about giving distributions the option to license as GPLv3...

https://groups.drupal.org/node/211698#comment-699423

I'm opposed to the effort and confusion a license change would necessitate unless you have clear evidence that this is something other than a theoretical concern at this point.

#1782540: Consider raising library size limit is resolved and it was decided not to raise the 10 Mbyte size limit.
This library is too big, and after being "Postponed" for six years, it is time to close.

There is also issues with the license, but that is a secondary consideration.