PDF Parser Coming Soon

Just so you guys know, I have managed to hack together the ability to generate a PDF from a MODx page.

At present, my solution involves a custom clone of the parser which passes pages (with a template) to HTML2FPDF (if there isn’t already a cached pdf). A custom .htaccess directs all .pdf file requests to a clone of index.php which loads this parser.

This solution therefore doesn’t touch the existing files (except .htaccess).

In the MODx manager, a TV is added which will be a dropdown of all templates - the idea is that a dedicated PDF template is written.

I had originally hoped to have this as a plugin, but this was not possible because the places where a plugin can be added in are inconsistent - as an example, the modified parser saves out docid_10.pdfCache.php files instead of docid_10.pageCache.php- in some places this filename is a string that I can change at the plugin point and in some places the string is hardwired into the load/save command.

HTML2FPDF isn’t perfect - in particular, it is unhappy with nested divs - but it is free and it works for my purpose.

One thing to stress again about this solution is that 10.html and 10.pdf both work. The purpose is to create PDF versions of existing information pages - indeed, I was sponsored to do this by a forum member (some of those funds will find its way to the MODx, HTML2FPDF and FPDF projects). It will of course be possible to create PDF-specific documents - possibly combining multiple page content into one document - by just not letting people know that 10.html exists.

It will be bundled with a snippet that produces a PDF link of the current document. (ie if called on 10.html, would produce a 10.pdf link, and if called within the PDF generator wouldn’t display anything).

I’m sure that better solutions are possible, but this is working in a test environment. I expect it to be released soon to ...In Development. (And yes, there will be a new version every time the parser changes).

I’d like to know a few things:
1) Am I OK saving to cache/docid_10.pdfCache.php - does this clash with any plans?
2) The parser is a clone of the 0.9.2.1 parser, not the recursive parser. What do I call this? "0.9.2.1 parser" or "Non-recursive parser" or what? (bearing in mind this is likely to be released before the recursive parser..)
3) Does anyone have any objections to my method?
4) Are there any planned improvements that would be beneficial to this solution?
5) What other features would you like bundled in?

Sounds great Paul!

I don’t think it should clash with anything as long as the parsers remain separate.

From a plugin standpoint I think it’s possible to just grab the rendered content then use the plugin code to save docid_10.pdfCache.php. If you don’t want the modx parser to save docid_10.pageCache.php then set the document[’cacheable’] setting to 0.

Interesting. I’d not thought of stopping it from saving the cache in another way.

However, saving wasn’t the problem (I was going to save in a subdirectory, because I could change the $basepath at the plugin point) - the main thing I can’t do in a plugin is *load* a different cached page, because there is neither a plugin point nor a $basepath variable at the right point.

In fact, it might be worth checking the checkCache function of the official parser:

the save path stuff uses:

and the load/check is:


Does this mean that an unusual base_path would result in cache pages being saved but never found?

Hmmm,

I I understand your question correctly, once the base_path is set (fixed) then it should work for both saving and opening the cache file.

What I am saying is that the "load cached file" routine *doesn’t* use base_path OR $basepath.
I’m not sure if there’s ever a time in which the relative path from index.php is going to be different to what the basepath should be, but if there was such a time the cached file wouldn’t be found.

Any news on this front ?

I have a 0.9.2.1 system that works.

I’m just finishing off a module that associates PDF templates with normal templates, then I’m going to get a 0.9.5 system rolling. As this revolves around a duplicate of the parser (because the plugin facilities are insufficient) the first public release will be post 0.9.5.

Ok that makes sense, thanks for the update !